When you step into the room with a client, you are a visitor from the future. You, web professional, spend your days immersed in the new paradigms of the multi-device web. Yet even for you, the constant change and adjustments that come with living on the internet can feel overwhelming. So how do you think your clients feel?
The web is fluid and mercurial. Our processes for working with it—and our clients—need to reflect that. It’s time for us to shed the vestigial mindsets we’ve inherited from the advertising world—the closed communications and drama of the “big reveal”—and build new systems based on honesty, inclusion, and genuine communication. We can bring our clients into the process right away, letting them see all the flaws and bumps along the way. Through this relationship they will become true partners—rather than confused, anxious bystanders—as we learn to better navigate this strange, evolving digital universe together.
Perspective is everything#section2
When your clients first think of a website, the mental image they conjure is likely that of a web browser as rendered on a desktop computer. This is completely understandable—after all, the majority of their website experiences occur while sitting at desks, fiddling with the things sitting atop those desks.
From where we’re sitting, however, we see the web as comprised of many more devices. Until recently, it’s been convenient to think of those devices as belonging to definable buckets like “smartphones,” “tablets,” and “laptops.” But as more and more varied devices have entered the market, those buckets have multiplied and overflowed, giving way to an amorphous continuum of display sizes, resolutions, browsers, operating systems, conventions, and interface possibilities.
This has required an overhaul in our thinking. Rather than websites being a series of perfect constructions rendered on each screen in exacting detail, web designers have started thinking in terms of systems. Flexibility has become a more valuable currency than specificity.
If your clients have ever been part of a traditional design project before, this is not what they’re expecting to encounter in your meetings. So how do we begin bridging this gap? How do we help our clients start seeing the internet through our magic design goggles? For heaven’s sake, how do we talk about this stuff?
How do I explain this internet?#section3
There are three big components to acclimating the uninitiated, which I think of as the three S’s: statistics, stories, and specifics.
Statistics are great because they can quickly make a point about the urgency of a matter. For instance, when speaking with clients about the importance of mobile markets, I often refer to this statistic:
42 percent of smartphone owners between the ages of 18 and 29 consider their phone as their primary way of accessing the internet (from Pew Internet).
Client: What? 42 percent? That’s berserk! We had no idea mobile was so important! Now what do we do?
That’s the power of statistics. They don’t give a lot of context or provide any kind of holistic understanding of a problem, but they do turn heads and introduce a need. A hard-hitting stat is a terrific way to begin a conversation like this.
Stats sure can make a point, but humans are social and emotional creatures. To make ideas memorable and help them stick in one’s craw, it can be helpful to reach for a personal story that exemplifies the issue, making it more tangible. Comme ça:
I have a three-year-old son. And as you may or may not be aware, three-year-olds left to their own devices are incredibly adept at finding new ways to injure themselves. That means that when I’m at home and I need to look up something on the internet, I can’t just run upstairs to the attic to use my desktop computer. But I do have another computer (my iPhone), handily located in my pocket. Now, I’m on the couch at home—I’m not what one would typically describe as a “mobile user,” but I am on the most mobile device there is, and I expect the same quality of user experience and access to information as I would on my desktop. When I’m at home—my phone is my computer.
See how that worked? Now my statistic supports a narrative. My story has characters, a setting, and an (admittedly simple) plot. It’s more engaging than a PowerPoint slide with convincing stats on its own, and now my clients are more likely to incorporate this idea into their view of the internet. When they begin to think of “mobile users,” hopefully the image of Matt Griffin on the couch absorbed in his iPhone while being manically circled by a pajama-clad toddler will enter their brains, along with our old friends Guy in Line at Grocery Store and Woman Waiting at Bus Stop. Paradigm: shifted!
Show, don’t tell#section4
“But wait,” you say, “there was a third S!”
Excellent, you are a very astute reader and have passed the first test. Let’s talk specifics. Specifically, which specifics? Glad you asked!
If what you’re used to is a tiny, multi-column site on your iPhone, and pinch-and-zoom is standard procedure, you may look at your first responsive site and wonder where everything is. Where’s the navigation? Where’s the sidebar? Where’s all the stuff?
I find that a useful exercise is to simply pull up a responsive site on my phone and hand it around the room, while I resize the same site on the projector or TV that I’m using for the presentation. Clients can see that the main navigation collapses into a hamburger icon. The sidebar moves down below the main page content.
Watching this interaction on the big screen while they reproduce it on a handheld device helps everyone to make that connection between the mobile and desktop experiences. They can see that the content isn’t disparate, just recontextualized.
Demoing a few sites like this in the kick-off meeting (particularly well-known brands like Starbucks and Paravel’s Microsoft homepage) helps to reinforce that responsive design is a growing standard that users likely expect to see on your client’s website as well. After all, if some of the world’s most established consumer brands have already taken the plunge, it will feel a whole lot safer for your clients.
Delivering the deliverables#section5
Helping your client be more aware of responsive conventions will provide the context necessary for them to give you better feedback on your design work. But first, you need to show them which deliverables they’ll be reviewing, and let them know what sort of feedback will be useful for each one.
For responsive designs, we’re finding that smaller, more focused deliverables coupled with frequent client feedback get us on the right track more efficiently.
Get it in writing#section6
We start every project with a short, written specification that includes project goals, feature descriptions, site information architecture, a site map, and a branding profile. For a recent project Bearded worked on with the Andy Warhol Museum in Pittsburgh, we kept everything in a text document on Basecamp, where it was editable (and version-controlled) by everyone on the project. That helped us update it quickly, without misleading, out-of-date versions floating around. Version control also made sure that we had a record of any changing decisions, should they come into question later.
The specification document spells out the goals and strategies for the project. It’s the victory list and the game plan.1
Getting an early version of this document into your clients’ hands is essential. Make sure each and every stakeholder knows how important this is, and has read it and given their thoughts or concerns before you continue. I suggest a message like this:
Participating in the writing of the specification document now means your ideas will be incorporated into the final product. Please make sure anyone that needs to weigh in later reviews this document. Let them know: if the outcome of this project is important to you, we need your feedback on the spec doc by next Friday!
Often these suggested edits spark new conversations about what’s important to accomplish on the project. If someone’s idea for a feature or approach sounds off-base to you, ask why they think it’s crucial. How does it relate to the project goals? If it doesn’t, do you need to revise the goals, or does this stakeholder just need to be reminded of the big picture?
Once these key plans are in place (and everyone on the team is finished making edits), we have what we need to start getting visual.
Frame your wires#section7
To define page layout accurately and efficiently for responsive design, the browser is the place to be. For the Warhol Museum, we built this responsive wireframe. It came out of our front-end starter kit, Stubble, and took about two and a half hours to put together. It’s not pretty, and that’s the idea. No one’s going to mistake this for a website design. But they will understand that these are the first steps toward defining information hierarchy and layout.
When we show our clients wireframes, we ask them for content-oriented feedback:
Are we missing any important chunks? How about the relative importance of the chunks that are there? Does this seem like the raw information this page needs?
At this stage we’re trying to make sure we have all the stuff we need on the page before we start designing it. But just because we’re still working out the page content, doesn’t mean we can’t also dabble in aesthetics.
When lo-fi is the best -fi#section8
Wireframes are great at being wireframes, but they don’t do squat for look and feel. Somewhere between a style prototype and a traditional page mockup, a lo-fi mockup embodies web design pragmatism—efficiently conveying the overall tone. We quickly assembled this lo-fi, static mockup as a companion piece to the Warhol wireframe.
With these lo-fi mockups I tell our clients to ignore the details for now, and give us feedback on the broad strokes:
We all know this isn’t a website yet. But is it going in the right direction? If it’s not even close, why? Is it too casual? Too professional? Not on-brand? If it does feel “in the ballpark,” great. We’ll keep moving in this direction, knowing you’re on board.
Make your feedback a loop#section9
The granularity of your client’s feedback should match the level of detail of the deliverable they’re looking at. So lo-fi visuals get lo-fi feedback and sign-off. Let’s look at a common reaction:
Client: Hmm. The mockup feels a little stuffier than I thought it would.
Me: In the spec doc we said we wanted it to be both sophisticated and playful. Maybe this isn’t playful enough? Should we try to dial back the stuffiness and get a little more weird?
Client: That sounds about right. What are you thinking?
Me: I’m not exactly sure what that looks like yet, but I do think the interactions we create later will be a chance to have more fun. Why don’t we see what we can do now—maybe revising the color scheme to be more energetic—then see what we can do to liven things up once we get in the browser. Sound good?
Client: Yep! Let’s do it.
You should adjust things until the group agrees that we’re “close enough,” but don’t sweat the details. It’s not the place for it. When you feel that twinge in the back of your mind that says, “We’re getting nit-picky,” that’s when it’s time to say:
We’ve got ourselves a solid foundation, is it OK to move on now?
Moving on, of course, means more detail. Less metaphor, more reality. That’s right, you guessed it: it’s time for some HTML/CSS mockups!
Conversations, not revelations#section10
In-browser comps are the full-on deal. Honest-to-goodness hi-fidelity interactive mockups using semantic, reusable HTML and CSS (as discussed in my previous article, Responsive Comping). After approving the wireframes and lo-fi comp, our client saw this mockup for the Warhol project.
Not only is it responsive, but it’s a significant evolution of the aesthetic presented in the earlier lo-fi mockup. It’s taken the spirit of the static mockup and the organization of the wireframe that everyone agreed on, and added a new level of refinement, detail, and polish—all right there in the code.
Any client feedback now will likely be pretty minor. Why? They’ve been participating in the whole process, guiding it to this point. They knew what to expect and weren’t surprised by what you presented. It’s the polar opposite of the “big reveal.” No drama—just a natural evolution toward an effective design solution.
Remember: each client request for a revision is actually a request for a conversation. My default response to any change is, “Why?” Help your client focus on the “why,” and remind them that figuring out the “how” is your responsibility. Focusing on “why” helps you address the root cause, rather than a possibly incidental symptom.
Now we can begin#section11
Taking the extra time to help our clients understand the challenges we face and the role they’ll play in our process makes them easier to communicate and work with. It will help build their confidence in you, strengthen your rapport, and bring them more fully into your team for this and future projects.
It’s true that your new clients may not yet know and love this squishy internet the way you do. But enthusiasm is infectious. Help your clients see the internet for what it is (magic design goggles optional), and all your client interactions will benefit.
This. This is the way I want to work with clients. No surprises, no squirreling away to design land, and actionable feedback. Working with them to execute awesome. Fantastic article, Matt.
Thanks, Chatman! It took a while to come to these conclusions, but it definitely feels right now that we’re in it. Glad you agree!
I really dig where the lo-fi, static mockup comes into play because instead of doing the full homepage design and some interior pages in Photoshop, you can just design a sliver of the site as long as the main idea gets across. Then code the whole site and make changes there. Well played.
Thanks, Chris! It’s been working well for us.
Enlightening post. One of the realities we’re finding with so many different desktop display settings out there is that some of what we used to be able to address with static comps is being further fleshed out in development we’ve handed the site over to the client for QA. On responsive, that’s been the expectation we set from the get go – show some wireframes, do a design comp, know that there will be at least a couple revision rounds once the template is built. I love the idea of doing a lo-fi static mock up. That would make the process clearer for the client and smoother for us all.
That sounds about right, Ben, thanks!
It’s fantastic post Matt. Thank you for sharing your alchemy. I love the idea that a bit of psychology is involved in the whole process.
When client takes part in every stadium of the project, he or she is much more aware of consequences of his/her previous decisions.
But I must also admit that lately I became tired of over-explaining every detail to every new client.
Every project puts me in the situation that I have to use my design, programming AND teaching skills.
Can you imagine asking a guy that repairs your car that you want to be involved in the process of fixing it and you also want to hear explanation of every step he takes?
That’s why we all need posts like this, Matt. Every project is different but the process of making it should once be defined precisely.
Thanks, Bart! The thing about that analogy is that the car guy doesn’t necessarily need you to explain the ins-and-outs of what your car is. He’s the car expert, and he’s going to fix it. Come back at 5:00, bro.
Websites are different animals, though. We may be world experts in how websites are designed and built, but we begin each project utterly ignorant about most clients’ organizational and user needs.
Which is part of what makes our industry so collaborative and eternally interesting. Clients need us to help them understand the web and their website’s place there; we need them to help us understand what’s going to happen on those websites, and ultimately what those sites are for. It’s a vital and challenging collaboration, every time. Best to embrace it!
Or in the words of Brad Hamilton: http://www.youtube.com/watch?feature=player_detailpage&v=k2NaHBVVYzY&t=57
Awesome article. I came through your website by tumblr. I am using tumblr first time. Your article is like those published in expensive “cars” and “automobile” magzines. Even better than them.
I have bookmarked your website and stored this article to read (offline) later, again.
Love this! Definitely a direction I’ve been evolving towards, and I never enjoyed the process of wireframing, seems like an unnecessary step in the current web design process. Great article!
Excellent article, Matt. I’ve been putting a lot of this approach in effect for a while now, because it’s easier for clients to get what we’re doing for their brand when we convey things in a language that means something to them: Stats, real-world examples, how process and decisions impact timelines and budgets, etc. Not to mention, I found that clients thought of me (or the agency) as more of a valued leader when involving them earlier and more often. Long ago, teammates pelted me with rocks and garbage for blasphemous invitations to the client to join us in our creative inner sanctum. Thanks for the affirmation that the times they are a changin’, yo.
Yes, invite them in right away! They tend not to bite, in my experience.
Hi Matt, great article, and perfect timing for me. I work in small web studio and we’re looking at re-thinking our processes. I’d be interested to hear your thoughts on this process, but on a smaller budget. Or do you have a cut off point for this kind of workflow?
Hi Matt, very good article, and pretty much the way we’re trying to work from ~1 year.
(You cannot simply showcase a responsive design in Photoshop or, at least, it’s hugely better for us to work on real markup to avoid subsequent responsive somersaults.)
We found it perfect for small projects but when it comes to medium sized projects where many different page layouts are involved, starting the development process with a couple of HTML/CSS prototypes implies that other pages (not yet sketched) may require extra development work in the revision loop, when you’re already in the CMS/framework of your choice.
On the other side, providing *all* the page mockups in HTML/CSS has proved to require developing some backend logic to hold menus/basic automation/multinguage/etc, and that development effort seems to be wasted at the end.
What’s your approach when many page layouts are involved?
As far as concern of multi device web, there is a term called responsive web design. Creative Website Designing And Development Companies use this technique while there are still many in this arena who even don’t know about this term. Responsive web design is a technique in which a website is being developed in such a manner that it automatically adjusts its dimensions according to the device it is being browsed on.
Chris,
The Warhol project used s an example here was actually about the smallest budget we’ll ever do ($10k). Our usual low-end cut-off is around $30k. But I think this process works well for smaller budgets, you just have to adjust project scope accordingly.
For instance, this project was a simple 1-page static HTML site. There was no back-end functionality at all. We also had to be careful to keep all of our meeting and design hours within the specified range, and let the client know when we were approaching our limits.
Macaroni Bros,
Funny enough, this is a section that we cut from the article! So here’s a little outake / B-side for you :
“Now the Warhol site is very small in scale. So what can we do when we don’t need to design a handful of page layouts, but rather dozens or hundreds? What budget can sustain that number of detailed in-browser mock-ups?
Style guides are not new. But style guides for the web are still relatively in their infancy. As an industry, web design has yet to really tap their full potential. Take this style guide for Flat UI, for example. This guide aims not to show finished page layouts. Instead it provides a clear definition of all the moving parts on the site, and some examples of how these elements might be assembled – addressing the interests of what Brad Frost has started calling Atomic Design.
With a few example in-browser mockups to show page layouts, and a comprehensive style guide, the design and styling of large scale sites could be seriously streamlined.”
Nice article! This is a good way to outline a project. “Get It In Writing” and the last paragraph of “Conversations, Not Revelations” will save hours of work and headaches.
Matt, what a valuable article and something I hope to see more of in the design community. We’ve been in the process of trying to eliminate the “big reveal” and showing a client prototype seems to be the best way to make sure they truly understand how you intend to move forward.
Do you ever have instances where the client is hung up on the low-fi mockup and prefers to see something closer to the designed final version? Particularly if they are used to print or if they have designed a website using the conventional big reveal process in the past.
“I find that a useful exercise is to simply pull up a responsive site on my phone and hand it around the room, while I resize the same site on the projector or TV that I’m using for the presentation.”
Fantastic stuff. Totally agree with the “Show, don’t tell” philosophy. I struggled with explaining RWD to clients initially. For some reason resizing the browser wasn’t enough for them to grasp it was a “device” thing – not just a “size” thing. So I put together something I thought would help them “get it”. http://www.jamus.co.uk/demos/rwd-demonstrations/
Yes yes yes. Thank you.
In a similar vein is Stephen Hay’s “Responsive Design Workflow”, well worth a look.
Thanks for sharing Matt!
We’re trying to make our CMS setup as flexible as possible, in order to handle the revision loop on the *real* website.
Not always easy, but could be a promising way to work.
As most people pointed out, people with very broad skills (css, js, backend coding) is becoming a must.
I truly spend time educating my clients..Also, this is were the importance of great blog articles come into play also..This way you can direct your client to the article that there questions are based on, and you really don’t have to repeat your self over and over again..A visual show and tell works great, this kills 2 birds with one stone…
I truly spend time educating my clients..Also, this is were the importance of great blog articles come into play also..This way you can direct your client to the article that there questions are based on, and you really don’t have to repeat your self over and over again..A visual show and tell works great, this kills 2 birds with one stone…
I absolutely love this article, Matt! I’m all for transparency and this really does a great job of debunking the myth that the client shouldn’t be involved throughout the process. I do have a question for you, though. Being a recent college grad with a skill set that ranges from graphic design to startup development to web analytics and development. How would you suggest I go about breaking into the UX/UI scene specifically without having that specific of a project in my portfolio? (I have done plenty of work in the segmented parts of UX/UI design, but not an entire project? Thanks!
I have found that simplifying terminology and dumbing things down for clients whilst judging their level of awareness works then educating them in the explaining each aspect in the correct terminology afterwards works well and helps it stick.
Thanks, Jeff!
Heidi,
None of our clients have yet balked at the idea of seeing the designs *before* the budget’s all gone. 🙂
They seem to (rightly) really enjoy getting to give feedback early, while there’s still a reasonable chance to change direction. As long as they know this is low-fi stuff, and they’ll be getting the hi-fi experience later on, it seems to be a non-issue.
That’s pretty neat, Jamie! In my experience, though, nothing beats a real device in their hands. If nothing else, every client should have a smart phone in their pocket. Just make sure you’ve spent time with device testing before you go that route! 🙂
Jake,
Stephen Hay is a gentleman and a scholar. Thanks for sharing, here’s the link to a video of his talk, for those who are interested:
Brad,
Wait, there’s a scene? 😉
Best way in my opinion is to learn by doing, and reach out to the community for help. Go to meet-ups, talk to people, etc. It’s amazing how open and willing to help everyone is in our community.
Here’s some related advice from a blog post from a while back: http://blog.bearded.com/post/18437972041/the-medium-is-the-message
Hope that helps!
I like the idea of including the client in the design process. I think it would save a lot of time and effort for both parties, and it would help to avoid the problem of being too possessive over ‘your’ designs. It’s hard for it not to feel like a personal insult sometimes if you put a lot of effort into something and the client doesn’t like it. If the clients are involved in design choices from the start that could be avoided.
any advice for employing this wisdom (that i actually think is pretty awesome) in a corporate context? i.e., any practical tips for utilizing this kind of approach for in-house builds for company developers?
The client must have some control over the project, but when he starts to act like he knows better than the designer, things start to get irritating.
While it’s true that if the client is involved in the design from the beginning, he might be satisfied with the product (hey, it has some of his ideas), but if the client will distribute it to users and the feedback will be negative, guess who will be the one to blame? 🙂
Ahhh… both funny and wonderful!
Funny, because I was a mainframe programmer for 20 years – mostly Assembler + some 4GLs – and it was a rare programmer who actually even considered listening to the user community when building a new application. It was always “We know what you need, code it up, hand it over, and then wonder why they didn’t like it” 😉
And the sad part was that I ALWAYS involved my users from step 1 in a project, just like this article recommends – and my fellow ITers thought I was strange because of it.
That’s the “funny” part – the “wonderful” part is that the current generation seems to be getting it (YAAAAAY MATT!!) – and it’s even more important today, with complexities like Responsive Design now being a major part of any reality-aware web developer’s work.
Excellent article! 🙂
Im definitely for the involvement of clients throughout the design process, always happy to take on advice from the client and show him/her throughout the development of the site. Otherwise we may as well just design our own website.
Thanks Matt for sharing your thoughts. I always practice to educate clients about latest web techs & trends. Involving them through out the design process initially may look hard but it will make them love their website and also it improves the chance of referring our company to their circle.
Gobi
Adorn Consultants
It is great article!
Thank you for sharing.
ネットビジネスde副収入
As a business owner i know the importance of Responsive site so i have developed my site from Creative Web Agency and they did a very good job.
I have worked on my site with my team of developers and make it responsive. You can check emarc.co.uk site.
this is nice articles for client relationship. really i am appreciate your articles. in web designing client relation ship is the better option to retain the client. how to retain your client do responsive web designing as well as do high quality SEO Services.