BlogmyQuery – BMQ

As I sat in my local co-working space, shoulder-deep in a design problem on my MacBook Air, I could hear him. He was on the phone, offering screen-by-screen design recommendations to his client for the project they were working on. When this acquaintance of mine arrived at the subject of a particularly hairy task flow, he said, “Well, these aren’t going to be very savvy users, so we should probably put some instructions there.� He followed this by rattling off some dry, slightly too formal line intended to clear up any confusion about the page.

Image Source: Robb North

It was an act that reflected his apparent belief that some savvier type of user is out there who would immediately understand the screen and could live without the instructive text. I cringed. I’ve heard the same suggestion on far too many phone calls, and it’s been wrong every time. To shed light on my reaction to it and to illustrate why such a suggestion is problematic, let’s consider a quick tale of two users.

A Tale Of Two Users

First up is the type of user who my acquaintance thought he was trying to help. Let’s call him John.

John is a guy with little experience using the Web beyond the typical. He pays a few bills, Facebooks a few friends, buys the occasional bauble, but he has found himself having to use this fancy new internal Web app as part of his job, the one designed by the person in my co-working area.

At the next desk over is Jane, a tech-savvy user who spends nine hours a day doing one thing or another on a variety of screens — her laptop, her phone, her tablet — and whose hobby is loading up on as many apps as she can find. She’s never met a problem the Internet couldn’t solve. She has chops, and she loves to use them.

When John approaches this complicated Web app, he knows a couple of things: that he has to learn to use the thing in order to do his job, and that he often struggles to understand the complicated interfaces that seem to come at him from every direction these days. He’s not excited about having to cope with this one, too.

Jane, on the other hand, is a “producer.� She gets things done, and she pushes this app’s buttons without hesitation. The list in her to-do app has a hundred things on it, and doing work on this app is just one of a slew of tasks whose ass she’ll kick before even heading out for lunch.

John and Jane both see the same screen, but they see different things there. Their understanding and familiarity with it are not the same; their confidence in conquering it is at different levels; and different psychological factors are at play when they interact with it. For John, the pressure is in figuring out how to do this part of his job so that he can get back to nervously doing the others. For Jane, the pressure is in cranking through this so that she can devour the next item on her list.

Identical Needs

Now comes the part that too few people who make design decisions realize: while John and Jane have different problems and are different types of users, their needs are identical. In short, they both want to get the hell off this screen. John is unconfident, and Jane has other things to do. They both need the screen to make sense. They both need the task flow to be obvious. They both need to just get past it.

So, which user was my acquaintance helping by adding instructions to the page? In truth, the answer is probably neither.

The only reason a line of instruction would help John is because the screen was designed for Jane, whose vast experience helps her decipher the purpose, benefit and flow of this task. And that’s exactly the problem. Jane, though perhaps more likely to work her way through the screen with some success, has better things to do than struggle with it. She may have more technological experience, but she’s in a hurry. Besides, a poorly designed screen can make Jane feel as much of a moron as John feels. Her experience means nothing against a screen that wholly fails to explain itself.

John is less likely to recognize design patterns or to be able to parlay his previous experiences to this one. Jane is more likely to recognize patterns, but only if they’re used in ways she’s familiar with or can quickly adapt to (although weak designs are weak usually because established design patterns have been misused). John’s lack of confidence pitted against a tough design might kill his desire to ever work with it again. And Jane, despite being ready and willing to fight through it, will not be any more loyal after the battle.

In short, Jane is just as likely as John to walk away from this screen frustrated. And no line of instruction will compensate for a bad design.

Frustration Is Frustration

Despite hearing it all the time from designers and executives alike, the notion that tech-savvy users will be more amenable to difficult interfaces is, in a word, crazy. Yes, some users, when asked, would prioritize user control over ease of use (and vice versa: unconfident users would prioritize ease of use over control), but does this mean that the tech-addicted among us will more readily understand an unclear message, tolerate a poor task flow, or swear by a product that they themselves have trouble using? Heck no. Complexity can be managed, control can be beneficial, but frustration is never a good business strategy.

It doesn’t matter how savvy your users are, better design benefits everyone. Having a proficient audience is no excuse to slack off. You’re still designing for human beings, and human beings, one and all, have better things to do than try to make sense of a weak design.

You’re A Jane

If you’re reading this, odds are that you’re a Jane. You are a tech-savvy, confident user who jams those buttons down like there’s no tomorrow, fearlessly marching your way through whatever task stands in your way. When was the last time you had the time and willingness to put up with a poor interface from a company that thought it could get away with it because you’re an experienced user? When was the last time you liked it? When was the last time you recommended an app with such a design?

The next time you’re designing for John, remember that you’re also designing for the Janes of the world, too. Their to-do lists will be the better for it.

(al)

© Robert Hoekman Jr for Smashing Magazine, 2011.

Right there in the center of my boilerplate for design proposals is a section that I glare at with more resentment each time I complete it. It’s called “Deliverables,� and it’s there because clients expect it: a list of things I’ll deliver for the amount of money that I specify further down in the document. Essentially, it distills a design project down to a goods-and-services agreement: you pay me a bunch of money and I’ll give you this collection of stuff. But that isn’t what I signed up for as a designer. Frankly, I don’t give a damn about deliverables. And neither should you.

(Image: Snoggle Media)

Case in point: for months now, I’ve worked consistently with a particular client for whom I do almost no work on actual design artifacts (wireframes, prototypes, etc.). Rather, I hold frequent calls with the main designer and developer to go over what they’ve done with the product (i.e. poke holes in it) and what they should do next (i.e. help prioritize). Some days, they hand me wireframes; sometimes, a set of comps; other days, live pages. Whatever the artifact, our purpose is always to assess what we have now versus where we need to get to. We never talk about the medium in which these design ideas will be implemented; we focus strictly on the end result, the vision of which we established long ago and continually refer to. And in working this way, we’ve been able to solve countless significant problems and dramatically improve the client’s website and products.

It’s not about deliverables. It’s about results.

Understanding why this works depends on understanding the real role of the designer and the deliverables they create.

A Designer’s Work

First, consider the role of a designer compared to what we actually spend most of our time doing.

What designers are hired to do — the reason why companies seek out designers in the first place — is what my friend Christina Wodtke calls “The Big Thinkâ€�: we’re hired to solve problems and develop strategies, determining what needs to be achieved and making design decisions that help to achieve it. But because companies have a compulsive need to quantify The Big Think, designers end up getting paid to create cold hard deliverables. Our very worth, in fact, is tied intrinsically to how well and how quickly we deliver the stuff. Heck, we’re often even judged by how good that stuff looks, even when much of it goes unseen by a single user.

Is this how it should be done? Absolutely not.

Hiring a designer to create wireframes is like hiring a carpenter to swing a hammer. We all know that the hammer-swinging is not what matters: it’s the table, the cabinet, the deck. Clients don’t hire us to wield hammers, but to create fine furniture. It’s not the process they need or the tools, but the end result.

In theory, companies understand this. In practice, not so much. They cling to the deliverables.

The Essence of Deliverables

So let’s look at what a design deliverable really is.

The purpose of a design artifact, whether a wireframe, prototype or sketch, is to illustrate our thinking. Pure and simple. It’s part of the thinking process. It’s also, according to some, a record to look back on later to aid when reconsidering decisions, tweaking the design and so on. But let’s be honest: people rarely look back at these documents once the design grows legs and starts walking on its own. More often than not, significant changes result in new wireframes, and minor tweaks are made on coded screens, not back in the deliverables that we were paid so much to create.

(Image: HikingArtist.com)

Most of the time, design artifacts are throwaway documents. A design can and will change in a thousand little ways after these documents are supposed to be “complete.� In terms of allocating time and budget, design artifacts can be downright wasteful. They can even get in the way; designers could get attached to ideas as they transition to functioning screens, precisely when they need to be most flexible. Every design is speculation until it’s built.

Like it or not — and some of you will surely disagree — we can survive with fewer deliverables. Of course, what this looks like depends on how you work.

Breaking the Deliverables Habit

The most important parts of any design project are the vision of the end result, the requirements for it, the design itself, and a way to measure its success.

Interestingly, only one of these parts involves complicated design artifacts. The vision is merely a statement that describes the purpose and desired outcome. Requirements are but a list. Success metrics? Another list. The only part that involves more than a simple, concise summary is the design itself. And nothing requires that process to involve layer upon layer of wireframes, prototypes and comps before going to code. (More on how to change this in a minute.)

(Image: lucamascaro)

Comps, of course, are a must when graphics are involved; in addition to necessarily being the source of the graphic files to be used in the actual design, they define the visual language, the specifics of layout, spacing, typography, etc. Creating wireframes, on the other hand, as quick as it is compared to creating coded screens, can take much longer than going from sketch to code. So, consider cutting the load down to what’s most essential and useful: the interaction model.

In other words, you don’t have to create wireframes and comps for every idea or every screen; just for the toughest screens, the ones that define the most crucial interaction paradigms. Use them to iron out the model, not every last detail.

It’s time for more design and less stuff. Consider the revised process below.

1. Strategy Document

Distill your research on users and the business down to a short vision statement on what the user’s experience should be like. Add to this a list of design criteria (specific guidelines or principles for the design), as well as success metrics (how you will know that the design is achieving your goals). You should be able to do all of this within just a couple of pages; and keeping it short will help to ensure that everyone reads it.

2. Activity Requirements

Write a list of tasks that users should be able to perform, and functions that the system should perform that will benefit users. Prioritize the ones that will appear on the screen.

3. Sketch

To apply the design criteria and meet (or exceed!) the requirements, sketch a dozen or so ideas — in Keynote, on paper or on a whiteboard — and then take pictures of the sketches. Sketch the toughest, most complicated and most representative screens first. These will frequently determine the interaction model for most of the design.

4. Comp and Code

If you’re not doing the visual design yourself, collaborate with the graphic designer to iron out the details of the most representative screens and any other screens that require graphics. At the same time, collaborate with the developers to identify issues and areas for improvement throughout the process.

Forget the lengthy strategy documentation. Forget the deck of wireframes. Just short summaries (long enough to get the point across, but short enough to be able to do quickly), sketches and comps, limited to the things that need to be brought to a boil in Photoshop. Skimping on the deliverables can save a lot of time.

Untying Deliverables From Project Fees

Of course, sufficing with this shorter list of artifacts and untying deliverables from your fees require a change to the design process. In short, we need to shift the emphasis from documentation to collaboration.

Set the expectation from the beginning that you will work with stakeholders collaboratively. They will help you think through the design at every step. You will not be a wireframe monkey. Rather, you’ll focus on The Big Think. And you’ll do it together. If the client is unwilling or unable to spend time and energy on the design as you develop it, find another client. A client who is too busy to get involved in the process is a client who doesn’t care about their customers.

Collaboration is essential to great design. No one person can think of everything or always have the best ideas for every aspect of a product. It takes a group to make this happen. This might require you to occasionally browbeat the client into being available for frequent discussions on new and developing ideas, but the result will be infinitely better. And with the added input, you can focus less on stacks of deliverables and more on converting rough ideas into comps, prototypes and/or functioning pages that give undeniable weight to those ideas.

In practical terms, this means working closely and constantly with the visual designers and developers (assuming you’re not doing this work yourself). And it means frequently reviewing what’s being done and discussing at a deep level and at every step how to make improvements. It means talking through every detail and making sure someone has the job of being the resident skeptic, questioning every idea and decision in the interest of pushing the design further.

Break The Habit

By focusing on The Big Think, the deliverables will matter less. And for a designer, focusing on beautiful products is a whole lot more rewarding than dwelling on the step by step of deliverables. On your next time out, consider breaking the deliverables habit. Go from idea to code in as few steps as possible. Hefty amounts of collaboration can cure the sickly feeling that you’re an overpaid wireframer, empowering you to build designs that you know are killer work.

(al)

© Robert Hoekman Jr for Smashing Magazine, 2011.