Looking for “Trouble”

I know a colleague who keeps a “wall of shame” for emails he gets from clients—moments of confusion on their end that (for better or worse) are also funny. The thing is, we know how to answer these questions because we’ve heard them all before: Why does this look different when I print it? How do people know to scroll? To a certain extent, making light of the usual “hard questions” is a way of blowing off steam—but it’s an attitude poisonous for an agency.

So, why do we disregard these humans that we interact with daily? Why do we condescend?

I think it’s because we’re “experts.”

As director of user experience at a digital agency, I’m prey to a particular kind of cognitive dissonance: I’m paid for my opinion; therefore, it should be right. After all, I’m hired as a specialist and therefore “prized” for my particular knowledge. Clients expect me to be right, which leads me to expect it, too. And that makes it difficult to hear anything that says otherwise.

As consultants, we tend to perceive feedback from a client as feedback on our turf—a non-designer giving direction on a design or a non-tech trying to speak tech. As humans, we tend to ignore information that challenges our beliefs.

This deafness to clients is akin to deafness to users, and equally detrimental. With users, traffic goes down as they abandon the site. With clients, the relationship becomes strained, acrimonious, and ultimately can endanger your livelihood. We wouldn’t dream of ignoring evidence from users, but we so readily turn a deaf ear to clients who interject, who dare to disrupt our rightness.

When a client hires us, they should come away with more than a website. They should gain a better understanding of how websites are designed, how they work, and what makes them succeed. We are the ones equipped to create this hospitable environment. For every touchpoint our clients have with us, we could be asking the same questions that we do of our users:

• How do clients interact with our products, e.g., a wireframe, design, or staging site?
• What knowledge do they have when they arrive, and what level must we help them reach?
• What are the common stumbling blocks on the way there?

Thinking back to our wall of shame, suddenly those cries of frustration from clients we’ve branded “difficult” are no longer so funny. Those are now kinks to change in our process; culture problems to address head-on; and product features that need an overhaul. In other words: from user experience, client experience. It means embracing “the uncomfortable luxury of changing your mind.”

I now go out of my way to look for these moments of client confusion, searching my inbox and Basecamp threads for words like “confused,” “can’t,” and “trouble.”

These examples are just a few pleas and complaints I’ve found along the way, plus the changes my agency has made as a result. It’s helped us revamp our workflow, team, and culture to enhance the “Blenderbox client experience.”

Make deliverables easy to find#section2

This one was easy. When we asked our clients about the problem—always the first step—we learned that they had trouble finding recent files when they saved deliverables locally. We were naming our files inconsistently, and (surprise!) that inconsistency was coming back at us in the form of confused clients.

I’ve seen this at every company I’ve been a part of, and it only gets worse outside the office; if you don’t believe me, go home tonight and look at your personal Documents folder. If I can’t keep my own filenames straight, how could we expect 20 of us to do it in unison? Clearly, we needed some rules.

Our first step was to bring uniformity to our naming structure. We had a tendency to start with the client’s name‚ which is of little use to them. Now, all deliverables at Blenderbox use this style:

Blenderbox.ClientName.DocName.filetype

The other point of confusion was over which file was “final.” In the digital world, the label “final” is usually wishful thinking. Instead, the best bet is to append the date in the filename. (We found that more reliable than using the “last edited” date in a file’s metadata, which can be changed inadvertently when printing or opening a file.) Write dates in YMD format, so they sort chronologically.

Next came version control—or do we call that rounds, or sprints? Unfortunately, there’s no single answer for this, as it depends on whether a contract stipulates a fixed number of rounds or a more iterative process. We gave ourselves some variations to use, as necessary:

• Blenderbox.ClientName.DocName.Round#.filetype

• Blenderbox.ClientName.DocName.YYYYMMDD.filetype

• Blenderbox.ClientName.DocName.Consolidated.YYYYMMDD.filetype

When a number of rounds is stipulated, the round number is appended. For Agile or other iterative projects, we use only the date. And when compiling months of iterative work (usually for documentation), we call it “Consolidated.” That’s as close to final as we can promise, and of course, that gets a date stamp as well.

Show how details become the big picture#section3

Here, the client cut-and-pasted from our design to create their own. Why? It’s not because they were feeling creative. They had a variety of content and they wanted to know that every page on their site was accommodated by the design. Of course, we had already planned for every page, but we needed to better explain how websites work.

Websites are not magic, nor are they rocket science. We can teach clients at least the basics of how they work. When we step back and take the time to explain what we do, they better understand our role and the value we bring to their business, which results in happier clients and more work for us down the road.

Prompted by this particular client, we incorporated an explanation of reusable templates and modules right into our wireframes. On page one, we describe how they work and introduce an icon for each template. These icons then appear on every wireframe, telling the client which template is assigned to the page shown.

Since implementing this technique, we’ve seen our clients start talking more like us—that is, using the language of how websites work. With improved communication, better ideas come out of both sides. They also give feedback that is usable and precise, which makes for more efficient projects, and our clients feel like they’ve learned something.

Compromise on comfort zone #section4

This is my favorite quote, and we hear this message over and over; clients want to print our deliverables. They want to hold them, pass them around, and write on them, and no iPad is going to take that away from them. Paper and pen are fun.

It’s a frustrating trend to lay out work on 11″×17″ paper, which is massive, beautiful, and only useful for designers and landscape artists. Who has a printer that size? Certainly not the nonprofits, educators, and cultural institutions we work with. So, we set about making our wireframes printable, and made for trusty 8.5″×11″.

This was tougher than expected because popular Omnigraffle stencils such as Konigi tend to be large-format, which is a common complaint. (Other programs, like Axure, also face this problem.)

Since no existing stencils would do, we made our own set (which you can download on our site).

We also fixed a flaw with common wireframe design that was confusing our clients: the notes. Go do an image search for “annotated wireframes.” Does anyone want to play “find the number on the right”?

Can you imagine assembling furniture this way? In our new layout, the notes point directly to what they mean. The screen is also smaller, deemphasizing distracting Latin text while giving primacy to the annotation. As a result, we find that our clients are more likely to read the notes themselves, which saves time we’d spend explaining functionality in meetings.

Figure out the format#section5

Here, a client was struggling (and rightly so) with a large set of designs that showed some small differences in navigation over multiple screens. By the end of the design phase, we often rack up a dozen or more screens to illustrate minor differences between templates, on-states, rollovers, different lengths of text, and the other variations that we try to plan for as designers. We also illustrate complex, multistep interactions by presenting a series of screens—somewhat like a flip book. Regardless of whether you present designs as flat files or prototypes, there are usually a few ways to enhance clarity.

If your designs are flat (that is, just image files) compile them into a PDF. This sounds obvious, but JPG designs require clients to scroll in their browser, and it’s easy to get lost that way. Because PDFs are paginated, it’s easier for clients to track their location and return to specific points. As a bonus, using the left and right arrows to flick through pages will keep repeated elements like the header visually in place. Another reason to use PDFs: some file types are less common than you’d think. For example, one government client of ours couldn’t even open PNG files on their work machine.

More and more, we’re using prototypes as our default for presenting designs. There is an astounding number of prototyping tools today (and choosing one is a separate article), but we’ve found that prototypes are best for explaining microinteractions, like how a mobile nav works. Even if you don’t have the time or need to demonstrate interactions, putting your designs in a prototype ensures that clients will view them right in their browser, and at the proper zoom level.

Make time to celebrate#section6

Clients shouldn’t be the “forgotten user.” We create great products for them by focusing on their end users—while forgetting that clients experience us twice over, meaning their user experience with the product and their user experience with us. Writing off a flustered client as out of touch means we’re disregarding our role as designers who think about real people. When these biases surface, they reveal things that we could be doing better. It’s shortsighted to think our roles make us infallible experts.

Searching client communications for keywords like “trouble” and other forms of subtle distress can help us identify moments of confusion that passed us by. It forces us to address problems that we didn’t know existed (or didn’t want to see). At Blenderbox, the results have been good for everyone. Our clients are more confident, receptive, and better educated, which empowers them to provide sharp, insightful feedback—which in turn helps our team design and build more efficiently. They’re happier, too, which has helped us gain their trust and earn more work and referrals.

We’re getting so desensitized to the word, but we all understand that there’s value in empathy. And, like any other ideal, we forget to practice it in the bustle of daily work. Because empathy is a formal part of UX, we don’t get to use the “busy” excuse. Even mundane design activities should be daily reminders to listen to the people around you, like a sticky note on your monitor to “Put yourself in their shoes.” In other words, we can’t overlook that our clients are people, too. When we stop and think about user experience, we might just be doing our job, but we’re also saying that we choose sensitivity to others as our primary professional mission. And that is the first step to making great things happen.