Workflows In A Responsive World: From Waterfall To Agile

Responsive design brings a new approach and philosophy to creating and building websites. Many are finding their old workflows less than ideal for responsive projects.

I’ve seen this in myself and I’ve read through the changing workflows of other designers. There are some common threads in the trouble spots of the old workflows and in where the process needs to change.

Things seem to be moving from a mostly sequential and structured waterfall process to an iterative and incremental agile process.

Waterfall

Old Workflows

If you think about the workflow you’ve used prior to any responsive design, it probably follows this basic pattern.

  • Plan — information gathering, research, content collection
  • Design — sketches, wireframes, moodboards, Photoshop (Fireworks) comp
  • Develop — html/css/js templates, page creation, additional functionality
  • Deploy — test and launch

Each of the above might come with a sign off from the client before moving onto next phase. Often your fee structure is tied to different stages in the process. A couple of problems arise in the design phase though.

First static image comps can’t show the dynamic nature of a responsive site. Second it doesn’t make sense to try to create a new comp for every different page type at different sizes. It’s simply too much to realistically do for most budgets.

There needs to be a better way.

Lapin Agile in Montmartre

New Workflows

My own process has been changing for the last year or so as I’ve moved toward responsive design. It’s hardly perfect and it’s still evolving. I’ll get to the details in a bit. The main change is less time on design comps and moving to the browser sooner.

I’m giving just enough early deliverables to clients so I know it’s safe to begin developing the site. Then I’m iterating more with the client to refine the eventual design. It’s worked better with some clients than others, though I think the core idea is the correct one. It’s more my implementation that needs to improve.

Here are some other designers discussing their new workflows.

If you check the links above you’ll notice there’s variety in each workflow, but I think a few commonalities come through. The biggest is that moving everything to the browser sooner is better than later.

Collage of browser logos

Designing In The Browser

There seems to be mixed opinions on designing the browser. Some designers like it. Others find it restrictive. I suspect their opinion has more to do with the tools they’re most comfortable using and less with those tools being better or worse.

I’m in the former group. probably because my entry into web design was as a front end coder. Working with code is natural to me and I find it easy to explore and create by manipulating html and css.

However I don’t know if that means I design in the browser. I think it’s more a case of refining a design in the browser and incorporating working web pages sooner in an iterative process that unites design and development.

For example when sending deliverables to clients:

  • Instead of a static wireframe build one as an html page
  • Instead of a mood board image create online style tiles
  • Instead of a static design comps create html and css prototypes

Knock yourself out designing as you always have, but as soon as possible push your design to a browser and having what’s in the browser be the deliverable.

The creative aspects of design should remain as unique and individual as they always have. Design where you want to design and where you feel it works best for you, but understand that certain aspects of the process now make more sense in the browser.

Cover for the design reference book Changing Classrooms

My Changing Process

With the above in mind I want to set out where I think my workflow is heading.

Planning — As I’ve always done I’ll continue to begin by collecting as much information as I can. I’ll talk to clients and ask questions. I’ll research the client’s industry. With the client I’ll work out the goals and requirements of the project and set constraints.

With the above in mind I’ll work out a design concept, begin making typographic and layout decisions, think though the color scheme and general atmosphere and work out the information architecture.

The main difference is where in the past most of my notes would go into .txt and .rtf documents, I expect to place these notes into html documents so they can be viewed in the browser. Instead of hex values and typeface names in a document, I want to see color swatches and live fonts in a browser.

Sketching — Somewhere during planning I begin to sketch out ideas, mainly for layout and I see this continuing. As the sketches evolve I’ll begin developing wireframes, likely in Keynote, and as soon as possible begin building simple html and css templates of my wireframes.

The difference will be that where in the past I worked up high fidelity Keynote wireframes to send to clients, I’ll keep these wireframes rougher and focused on the layout. I won’t send these to clients. Instead I’ll send them…

Detail from the book cover for Process: 50 Product Designs from Concept to Manufacture

Style Tiles — I’ll take the html wireframes and fill them in with the html notes on type and color and texture. This will be the first deliverable I send to clients. Initially these style tiles could start as a PSD file, but as soon as possible I’d like them to be html pages.

Ideally over the course of a couple or three rounds of style tiles and feedback we’ll have settled on the type, color, etc. as well as the basic layout. Together we’ll iterate until we have html and css templates for representative pages.

The idea is to work an iterative process with the client until the style tiles evolve into the boilerplate for the finished site.

Development — From here I’ll start building out the site itself. I’ll add pages, flesh out the navigation, add functionality. All the time the client will be able to check progress and offer feedback.

Deployment — At some point the site will be ready to test and then deploy. Other than the need to now test across devices in addition to browsers, this should remain pretty similar to how it’s done now.

You might have noticed the heading design doesn’t appear in the above description of my future responsive design workflow. That’s because design is happening through every phase above. It’s just not happening over a few sittings in Photoshop, which has never been my ideal place to create anyway.

The key change is the deliverables sent to clients. Moving them from static image comps to online style tiles and html wireframes that can become the boilerplate for the finished site. Again it’s not so much that I’ll be designing in the browser as I’ll be showing the design in the browser and refining in the browser.

Summary

The new philosophy and approach that comes with responsive design is forcing a change in workflow on us. It doesn’t change everything, but it does lead to several important differences from the way things have been done.

Early deliverables make more sense to show in the browser than as a static images. A single image simply can’t communicate the dynamic nature of a responsive site and the amount of images we’d need to communicate that dynamism isn’t realistic to create under most budgets. Better to show a live working page of some kind.

There also needs to be a closer relationship between design and development as each side is iterated over a single design/development process. Create a rough design that suggests a development path and let each side inform the other.

Web design is changing and like it or not that includes your workflow. The workflows we’ve been using for years are a legacy workflow from print. It’s time they adapt to the web. Like your responsive sites you should adapt now or find yourself left behind.

Download a free sample from my book, Design Fundamentals.

8 comments

  1. Do you think this method of designing/developing will result in less “creative” websites? I’m personally finding it difficult to get started on a workflow like this even though I know static mockups aren’t doing a good job of showing responsiveness.

    • I don’t, though I do understand the concern. I just don’t think it’s our tools or processes that determine our creativity.

      The new processes will be different and we’ll have to adjust. Some people probably won’t be able to, but at the same time there will be others who find themselves more creative with the newer processes.

      Creative people will find ways to be creative regardless of what tools are in front of them or what restrictions there are in using those tools. The end product they create will likely be different, though no less creative.

      With your own process don’t try to forces yourself to change everything wholesale. Make small changes here and there and slowly adapt your existing process to something more in line with the new ones. You’re still going to be creating some kind of mockup to represent certain stages of the responsive design and there’s no reason you can’t use the same tools and processes you use now to create them.

      You’ll have to adapt things to the new reality that things will change in your design once it gets pushed to the browser so you’ll want to allow more room for iteration at that stage.

      Things will be different. We’ll need to adjust. That doesn’t mean we’ll end up any less creative than we are now.

      • This a nice article in concept. In reality, as a digital/interactive Art director for multiple platforms (tablet apps, phone apps, conference booth displays, web), the ability of the client to visualize is the deciding factor. I simply cannot move beyond static PS layouts since the client cannot visualize the comp without them. Wireframes are seldom usefeful to the client – they just want to see how it is going to look. They cannot make the conceptual leap. Working in the browser is not an option for the large projects I am on. Dev is much separate from design. Its part of the workflow of large Agencies. Your system may work fine for smaller projects with more compliant clients but not for most major fortune 1000 clients.

        • I’m not sure clients need to see PS comps. I think it’s more that’s what we’ve always delivered and to be honest there have always been problems with that deliverable.

          Why does a client need to see a full comp in order to make a decision about the possible colors used on the site. Why do they need to see the full comp to make type decisions.

          At some point they obviously need to see more color and type swatches, but why do we have to deliver that as a .psd file? Why not a working web page?

          I disagree that clients can’t make the conceptual leap. I think we expect they can’t and so deliver things to them that doesn’t help them make that leap. Given the opportunity and with help from us, I think clients can conceptualize more than we sometimes think.

        • Albert,

          I have to agree with Steven on this. I work for a MAJOR media company in the Fortune 200 and recently we have been very successful in showing functional pages to clients, their agencies and sales people. You do have to explain a bit more to them but they end up loving it because they see how everything works and looks. One client has already agreed to sponsor something else with use based simply on how well this worked.

          • I haven’t shown a typical comp in about a year. I’ll sketch and create some visuals for myself, but the first thing I’ve been showing clients is a working html/css page.

            The page will start out rough. I’ve just been trying to show enough to draw some feedback from the client and get conversation going. Then I’m taking their feedback and using it to shape my original rough page(s) till we get to a finished design.

            I still have some things to work out in the process, but it’s been working well so far.

Leave a Reply

Your email address will not be published.

css.php