Workflows In A Responsive World: From Waterfall To Agile

Posted: 13 Aug 2012 05:30 AM PDT

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.

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.

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.

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…

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.

The post Workflows In A Responsive World: From Waterfall To Agile appeared first on Vanseo Design.