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:
- Responsive design is not (just) a design or development problem;
- The client participation process is broken;
- 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.
Design Testing and Device Testing
I find testing my designs on real smartphones and tablets while I’m working to be incredibly useful. This means that I have access to several devices. But how can we afford to buy all of the devices we need? This year, Stephanie Rieger wrote about the range of devices we should use. She included iPhones, iPads, Kindle Fire and three different versions of Android. But I think her advice could be misleading.
Do we really need to own a myriad of smartphones and tablets or do we need just a few to develop an affinity for them? Image: opensourceway.
It’s important to remember that there is a big distinction between two types of testing: design testing and device testing.
Designers need use only a subset of devices, because what matters most is that we develop an affinity for how our designs work on any type of device when we hold it our hands. To be clear, how a menu feels when used on a smartphone is a very different issue from whether it technically works on a particular make or model of smartphone. That’s why designers don’t necessarily need to buy a myriad of smartphones and tablets, just those they need to develop an affinity for.
Responsive Design Requires Rethinking
Businesses (agencies, companies, customers) now need to refactor many aspects of their businesses to allow for better responsiveness. Our clients now need to restructure their buying process. For example, at my agency, Stuff and Nonsense, I still get prospective clients asking us only for static design visuals. They assume we work in Adobe Photoshop, Fireworks or the like and that we deliver static visuals, because that’s what designers have provided them with for well over a decade. That’s why, while many of our clients don’t often expect responsive templates as a deliverable, they love it when they find out that that’s what we deliver.
Design and development teams need to reorganize. It’s a fact that purely visual designers have the most to learn.
Those Photoshop or Fireworks static visuals I spoke about are no longer equipped to provide what we need from them in a responsive context. As I’ve said before, it’s like bringing a knife to a gunfight. More on that in just a minute.
The Client Participation Process Is Broken
I know that most people know me from my writing and speaking about CSS, and some people might not know that I make my living by designing for clients. In the last year, I’ve worked on projects with STV, where I’m part-time the design lead; the Hillsborough Independent Panel, whose report into the tragic deaths of 96 Liverpool fans in 1989 I designed the website for; and the ISO, the International Organisation for Standards.
Every designer should want to make the best work possible, feel proud about that work and make their clients happy. Unfortunately, the ways that designers and developers and our clients have communicated in the past has so often lead to frustration, unhappiness and, most importantly, work that failed to meet everyone’s expectations.
For a designer, sharing regular feedback with clients and involving them in every step of the design process might sound like a risky proposition, but it is necessary and beneficial to the design process — when done properly. Image: opensourceway.
Think of the traditional media that we used to communicate our designs: static wireframes and visuals (comps) that we made using drawing tools such as Photoshop or Fireworks, many of which pre-date the Web. These visuals are like bringing a knife to a gunfight. Think about the aspects of design that a static medium cannot communicate and all of the possibilities for misunderstanding that this creates. Static visuals cannot do any of the following:
- Display Web fonts or browser font rendering;
- Demonstrate different browsers’ CSS capabilities;
- (Easily) demonstrate percentage-based layouts;
- (Easily) demonstrate animations, transitions and pseudo-classes (states).
When I say “easily,” I mean not without hours of tedious repetition that we could otherwise spend being creative.
This isn’t to say that designing in a browser is always better. Unlike Stephen Hay, I use Fireworks to design atmosphere (typography, color and texture) and to develop fine design details, an extra layer of polish, after all of the sketching and interactive prototypes are done.
Design Atmosphere
What do I mean by “atmosphere”?
Many people continue to mix layout with other aspects of design. How often has a client said to you, “I don’t like the design” when they really meant, “The sidebar should be on the left, not the right”? That’s why we need a new word for what’s left when we remove layout from a design. I call what’s left “atmosphere” because atmosphere is often about something that you feel but can’t explain, like the atmosphere in a room after two people have been arguing, or like the atmosphere at a great concert or football game.
Worse than being inefficient, static visuals set the wrong expectations in the minds of our clients. I wrote about this very thing back in 2009.
Aside: Why are most websites fixed and centred at 960 pixels? Could it be because a designer showed their client a 960-pixel-wide static visual and asked them to sign off on it? That’s what developers have been told to build. That’s why, in the past, we’ve spent hours hacking HTML, CSS and JavaScript to make rounded corners display in old versions of IE. We sold rounded corners to our clients through those visuals. It’s our own stupid fault. No one else’s.
Even small "snapshots" of the design, such as these from Dribbble, can communicate atmosphere — the visual direction, style and overall feeling — of the new website. Images: Fluid Type, Fig. 49 by Trent Walton.
Work in Photoshop and Fireworks, by all means (I do). Make static visuals as rich and as detailed as you want them to be. Just don’t set the wrong expectations by showing them to your clients as examples of how their website might look across browsers and devices or by using them as sign-off artefacts. The same goes for screenshots of Web pages. Set the right expectations by demonstrating interactive designs made using HTML, CSS and JavaScript.
How To Call Your Client An Idiot, To Their Face, Without Getting Fired, And Then Have Them Thank You For It
One thing I’ve learned over the years is that clients love to feel involved in the design process. Sometimes, though, they make suggestions only so that they feel they have put their stamp on the project. I know that occasionally designers think that such requests aren’t necessary and that sometimes they’re stupid. Don’t worry. You are allowed to say that to clients (more about that later), but better still, avoid the issue entirely. Here’s how…
Don’t email pictures of websites to your clients and then ask for their “thoughts.” Are you mad?! In the same vein, don’t simply upload static visuals to Basecamp and expect constructive feedback without providing some direction on how to receive them.
Don’t wait until after weeks of work before having a “big reveal.” Down this road lies frustration and resentment. Instead, keep clients involved at every step, all the way through the design process, and not only at those traditional sign-off points. That’s why for the last few years I’ve tried hard to physically work alongside my clients as often as possible. When that’s not an option, I set up shared Dropbox folders so that the client can check in on my progress as I work. We even keep a Skype window continually open.
Set up the proper environment to receive structured feedback, and then ban all unstructured feedback you might receive by telephone or email. Insist that your feedback sessions be face to face when possible, and then limit their scope to aspects of the design. For example, ask for answers to specific questions about typeface choices and typography.
At my design agency, I help facilitate structured feedback by organizing feedback workshops with our clients. More on those now.
Please remember: you are the designer. You are the person who has been hired to solve a problem that the client either couldn’t or doesn’t have the time to solve themselves. Your solution to that problem is worth a lot to their business, so never underestimate your role, skills and influence in the design process.
With that in mind, remember that you can set rules about receiving the constructive, structured feedback that’s so important to helping you make a great design.
Rule 1
As mentioned, don’t ask for unstructured feedback out of context. Emailing or uploading static visuals just doesn’t cut the mustard anymore. You must control the discussion, so take the time to explain your designs and the thinking behind the decisions you’ve made. I’ve found that, because of this approach, my clients enjoy learning about what goes into making a design and are far less likely to request unnecessary changes simply to put their mark on the project.
Rule 2
Take control of the environment in which you present your designs. Host feedback workshops or design “crits,” and use them to get to know your clients better and to develop a deeper relationship with them. Make these workshops face to face when possible, and set time and scope limits, even if you hold them over Skype. These workshops work best when everyone is encouraged to be honest and to let their ideas out in the open. That’s why, although it may seem a little old fashioned, it’s important for someone to keep a written record of what everyone has said.
Make it clear to your client that only the people who show up to a workshop may have an opinion about the design. This must include even the CEO, who sometimes makes “helpful” suggestions 24 hours before launch (or when you want to get paid).
Rule 3
Remind everyone to leave their feelings at the door, because in a design crit only the work matters. Personal feelings don’t matter; so, inside the crit, frame the conversation so that your clients can openly express their opinions. Encourage them to speak their minds, to be brutally honest if they need to be and to scribble across your notes and sketches to get their point across. By the same token, you’re free to disagree with any suggestions they make. Be free to say the suggestions won’t work, and suggest better alternatives. This shouldn’t be about ego, only about the integrity of the work.
If you feel they aren’t listening, you’re free to call them an idiot, too, if you must. Say it to their face, and don’t worry about getting getting fired — if you’ve established a good enough relationship with them, they’ll thank you for it, too, because they’ll know you have their interests at heart and are passionate about doing your best for them and their business.
(al)