What is web design?

What is the best way for designers to present mock-ups or specs for responsive web design?

• Designers or design teams working on fixed-width websites have constraints that make it relatively simple to mock up designs on a canvas in Photoshop (or Fireworks, etc.). However, responsive web design poses a unique problem when it comes to design: How to deliver design specs. Do you deliver a different spec/mock-up for each breakpoint? Do you simply deliver the mobile spec? Full-width spec? Does the work of designers increase or decrease with responsive design? Just curious to hear what practices folks are using out there - particularly where teams (and skill-sets) are separated by 'design' and 'development.'

• Answer:

  With responsive web design and ever more complex websites, the traditional "Big Reveal" approach to project delivery does not work any more. 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. 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 builing 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 You've been working with HTML,CSS and Javascript this whole time so the frontend is almost complete. Now it is time to finish off the rest of the frontend and the backend development. 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. 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.