Encouraging Better Client Participation In Responsive Design Projects

This original article by Andy Clarke is well worth a read …
Last week at the fabulous Smashing Conference in Freiburg, I gave a new talk, one I’d written just a few hours prior. I chose not to use slides, but instead to speak about three things that I’m incredibly enthusiastic about:

  1. Responsive design is not (just) a design or development problem;
  2. The client participation process is broken;
  3. How to call your client an idiot, to their face.

Here are the (slightly expanded) notes that I made before my talk.

Responsive Design Is Not (Just) A Design Or Development Problem

In all the excitement about responsive Web design over the last few years, someone forgot to tell our bosses and clients, so we’ve been treating responsive design like it’s a design or an implementation problem, whereas in fact it’s as much an issue for business. In fact, it’s an issue for everyone involved: designers, developers, content specialists, the people who commission websites and those who structure the teams who make the websites.

The Traditional Workflow

Here’s a common, if grossly over-simplified, project workflow:

  • Plan,
  • Design,
  • Develop,
  • Deploy.

Into planning, you might roll up content audits, requirements, user issues, wireframes and the like. (Aside: Perhaps it’s because I’ve had too many bad experiences with too many bad UX specialists, but I’ve a problem with any part of the process that limits our potential for great design. This includes wireframes — typically desktop-only wireframes — that are produced and often signed off by a client long before they arrive in the design studio. Nothing is wrong with UX per se, only when it’s prescriptive and not part of a flexible, iterative design process.)

Design is where you’ll find a myriad of creative activities, including graphic and layout design and more. Here, static design visuals — you might call them comps — have been the traditional currency of the visual designer. They’re what designers use to experiment with creative ideas, then exchange with clients for sign-off, and subsequently deliver to front-end engineers as blueprints for building.

Development is likely the responsibility of front-end engineers. I know from experience that engineers often work separately from designers and might have only limited interaction with them.

As for deployment, I know I’m making light of this, but it’s black magic and I simply don’t understand it.

This waterfall-style process is similar to the old-fashioned pre-press workflow that I remember when I worked in pre-digital photography. It took up to seven people to take a transparency from a camera to a color proof. Each person’s work was an opportunity for sign-off, but more importantly it was an opportunity for billing. The same is mostly true of our Web design processes today.

Compare that to what I’ve cheekily been calling a “post-PC responsive workflow”:

  • Plan,
  • Combined and iterative design and development,
  • Deploy.

In this agile-style iterative process, everyone works more closely together, designing, developing, testing, redesigning and refining.

Follow the link for the rest of the article http://www.smashingmagazine.com/2012/09/28/better-client-participation-in-responsive-design-projects/


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s