With responsive web design and ever more complex websites, the traditional "Big Reveal" approach to project delivery does not work any more.
Our new design and development process is modern and extremely efficient. It will take designers and developers will take some time to adapt, but we strongly believe that this is the future of the web design process."Old-Growth Forest" by Nicholas T, on Flickr
The Traditional Process, a Scenario:
Presenting a client with a set of at least four to six wireframes for every page or template of a site is incredibly time consuming. In addition to the extra time involved in creating each of these mockups/wireframes, you have two more problems. First, you add a large amount of communication overhead and potential confusion over which wireframe is for which device, (why this has to be moved there, etc). Second, you invite clients that do not understand the process to start suggesting a large amount of changes early on in the process.
There is a risk of putting a client into a position of perceived choice paralysis. For example, let's say you show the client a set of home page wireframes in which there is a 4 column area about key features of their product. The client looks at the 4 column layout on the desktop wireframe, and then see's how this is made into a 2 column layout on landscape tablets and a single column on smartphones in portrait mode. The client then decides they like the 2 column layout best and that it should be two columns on every device. In addition they decide that the logo looks better bigger like it is on the desktop version, and that the iPhone landscape view is the best overall and the rest of the wireframes should be adjusted like it, except for the 2 column section described earlier.
Now you have an entire set of wireframes to adjust for every page template of the site. As you try to find a way to solve this problem and get to the design stage as soon as possible. Time to development suddenly looks like it is a month away.
You might say, "This isn't too big of a problem though right? We can explain to the client how it would need to work, and show that certain sections need to be the way they are. Couldn't this be at least partially solved by educating the client in the first place?"
Now we are getting somewhere.
Our new process needs to be agile. Processes need to overlap, the client needs to be more involved throughout, and they need to be educated even more than before.
Our New Process:
Step 1: Educate
Educate the client about responsive design. Explain what needs to happen, why and how your team can design an optimal solution to help clients reach their goals through each version of the site. Especially if a consumer's priorities on a desktop are different on a mobile version of the site.
Step 2: Prototype
Start building a functional prototype. From this point on, the client will see their project evolve every step of the way. Building a functional prototype shows clients how their new site works first, instead of the "big reveal" where we wait until development is complete for the client to finally try out the site and realize while they like some areas, there are a couple parts that they did not expect to function in the way they do, even though your team tried to describe it early on in the process.
Step 3: Design
Add fidelity to the design as the prototype nears completion. Now the client has a basic idea of how their site works and how it responds to different screen sizes. Another team member might have a separate branch of the repository where they have already begun fleshing out the design. Now the aesthetics of the site start to take shape. If choosing to keep the client completely involved through this part, set a date when a meeting can be held to review the design and explain to the client that the design will be ready for feedback by that point. This way you avoid changes being suggested before the design is finished.
Step 4: Develop
Step 5: Test
As development is wrapping up, testing begins. A log of issues are tracked and shared with the client. If the client notices anything else they can mention it at this point.
Step 6: Launch
Testing is complete, and now we are ready to launch the site.
Steps 1 through 5 all overlap at least partially and for some steps entirely. This process makes building a custom responsive site faster and more efficient. It also reduces potential conflict and misunderstanding with a client as well as time spent on additional changes and revisions.
Why is this Process Better?
Because this new process is so much faster, you don't have to charge the client as much. With the typical big reveal process, unless you charge around three times your normal rate when the website is responsive, you will be likely making less for your time. At first, the idea of all of your projects being three times as large sounds great, but unless you are simultaneously adjusting your client base to cater to larger businesses, clients that were in your current price range will no longer be able to afford you. Yes, a responsive website should cost more, and yes, a client will be happy to pay a little extra for it. That might be around 30% extra though, not triple the price.
This concept could be elaborated further, but that is the general idea. This is a new process. It will become refined and better understood over time, so that it does not seem so esoteric to designers who are used to the "big reveal" concept.
Finally, yes, this new process requires that designers can work with HTML. I used to believe that a designer would not need to know how to convert their PSDs to HTML, as long as they understood the limitations and abilities of code. It was easier to find a great designer and a great frontend developer than someone who was great at both. Today, and moving forward, sticking with that process would simply be inefficient.
Endnote: Designers, what do you think? Are you already using a process like this for responsive web design? Let us know your thoughts in the comments!