Fuzzy People

People are fuzzy around the edges, and so is their behaviour.

Users aren’t a very reliable source of hard data. They have ideas, but often no more than one or two. They have needs but may not know what they are. They think they know what they want, but they probably don’t. And they can rarely imagine things that don’t yet exist.

“If I had asked people what they wanted,” said Ford, “they would have said faster horses.”

They are a good source of soft data, however – although gathering soft data from fuzzy humans requires more indirect methods: observing them in their natural habitats, empathizing with their worldviews, and asking indirect questions – including why a lot – to get to the root of the problem we want to solve.

Taking into account the human factor is an integral part of design research: you have to frame the question correctly to get to the right answer. Building a better mousetrap won’t help if the mice have started a colony in the basement.


The Problem With Playing It Safe

Thinking too rigidly about user experience can make us blind to new opportunities.

An age ago, back in 2004, I was working in Amsterdam designing a website for Philips. User experience as a practice was still relatively new. There were rules, but they were different depending on who you asked. Best practices were a nice idea, but they weren’t very consistent. And that meant that everybody, and nobody, was right 100% of the time.

Our UX guy on the Philips project was a contractor – I’ve quite forgotten his name – and he was of the mind that things should be done just so, and any deviation would be a mistake. Thinking about it now I guess that makes sense: if you bill yourself as an expert in a field nobody knows anything about, you better at least be confident.

Of course, at the time I disagreed. I was an unruly, ego-driven designer, so I disagreed with everything. But in this case, my reasoning was sound: in my view the user experience discipline was too young to have all the answers. We were dictating behavioural patterns to users while knowing scarcely more than they did. And more importantly (to a designer, at least) we were missing opportunities to innovate on the UI side by allowing ourselves to be constrained by rules that were unbaked at best, and outright guesses at worst. Dogma seldom breeds insight.

It didn’t sit right with me, but I had to admit that my opinion was no more valid than his. And letting the process be driven by design would’ve been the tail wagging the dog, so we forged ahead, despite the UX field being in such turbulent flux that by the end of the project all our supposed best practices were obsolete anyway.

I’ve never forgotten that discussion, and I still maintain that the laws of UX, even as well-established as they are these days, can still be wilfully bent. Purists will point breathlessly to some high-profile case study (“Amazon changed the corner radius on their Buy Now button to 2px and it saved them $300M!”) but these are effects that are observable only at scale. For most everyday purposes, the rules, within reason – though not without good reason – can be challenged. It’s how innovation happens.

It is a mistake to dictate terms to users based on an overly-confident UX model, or to assume UX as a practice is fully baked. We should not be afraid to engage users on unfamiliar terms, or to ask them to follow new patterns. Their behaviour outside the sandbox can help us discover new ways to solve old problems.

How will we know if we aren’t willing to take risks?


Breaking Mental Models

When it comes to using a product, people rely on mental models – for better or for worse.

The mind draws on prior experience to create expectations which guide behaviour. We did this last time and it worked, so that’s what we’re doing this time, too. Mental models reduce cognitive overhead because you don’t have to make a series of decisions more than once – just retrieve a successful outcome from memory, and use the same template.

The base example of a mental model is one that every web designer learns to respect from day one:

Put the logo in the top left, and make sure it links to the homepage.

People expect this, and if they don’t get it then certain things might happen. They might become irritated at your brand, with its stupid logo sitting up there all non-linky and such, which is bad. At the very least they’ll wonder if your web designer is incompetent – not much better.

But just because a mental model exists, doesn’t make it mandatory. You can conform your UX to users’ existing (presumed) models, but you can also teach them new ones – if you have the courage. When Blockbuster said people come to the video store to rent a movie, it’s all part of the experience, nobody disagreed. But Netflix started mailing discs instead, and almost overnight the entire movie-watching population completely changed its behaviour.

Challenging mental models comes with risk, but the rewards can be considerable. When fresh thinking yields innovation, entire markets can shift fast.

Personally I wouldn’t recommend you move your logo link from the top left, though.


Reactive Solutions & the Anchoring Bias

Over-focusing on the first thing we learn stops us from seeing other, better solutions – and it happens whether we like it or not.

As I’ve mentioned before, it’s easy and natural to generate impulse solutions to problems as they arise. This is human nature. We’re so good at it that it happens without effort, and it makes us susceptible to the anchoring effect: a cognitive bias that makes the first answer we come up with crowd out everything that comes after.

This can be especially problematic when it comes to design thinking. There are large numbers of ways to solve any design or UX problem, and it’s much too easy to fixate on the first one that emerges. Any idea you come up with will seem like a good idea – to you.

Avoiding irrational attachment to early ideas – I call them reactive solutions – is precisely the purpose of brainstorming with more than one person. Leave it to one guy alone in a room, and the scope of possible solutions falls dramatically. This is also the reason why team play is an essential element of UX and design practice: one mind alone simply isn’t enough to cover all the angles.

To avoid reactive solutions and the anchoring bias, keep these points in mind:

Make UX strategy and design thinking a social exercise. When designing for interactivity and people, it makes sense that the best ideas will be generated by people interacting.

It’s nearly impossible for the first idea to be the best. Unless you somehow catch lightning in a bottle, the quality of solutions will increase in direct proportion to time spent. Put in the time, get better results.

Think first; design later. Especially for visual designers, our brains tend to run straight for the canvas, making any hare-brained idea seem better than it is. If you have to move to the design phase to make a point, you’re probably making the wrong point.


User Needs & the Availability Heuristic

“People don’t want quarter inch drills. They want quarter inch holes.”
— Theodore Levitt, Harvard Business School

What people say they need probably isn’t what they really need.

It’s easy to confuse process with result, because people like the idea of taking action more than pausing a moment to ponder abstract outcomes. Doing is easier than thinking.

This makes users notoriously unreliable sources of information about what they need. It’s human nature to automatically generate a solution to any problem that presents itself, and the first one that comes to mind then tends to dominate our thinking. This is a version of the availability heuristic: the tendency to place greater value on information that comes to mind quickly. And if you ask a user what he needs, I bet you a box of Timbits he’ll make the same mistake.

To properly understand a user’s needs, forget tools, the mechanics of the process and the functional requirements document. Features and functions are products of the solution, not its drivers.

Instead, probe the user’s motivations for a more complete understanding of the problem. Simple task completion might be the wrong success metric if the motive is less tangible, like proving your worth to a team or avoiding becoming a bottleneck in a production pipeline.


The User Experience of Hotels

The principles of user experience are now quite widely known, yet still lacking in some of the most obvious places.

Any customer service-oriented business is also in the user experience business. Bars, restaurants and other hospitality-based enterprises should be especially aware of this. Organizations who engage with customers over extended periods of time – airlines, for example – have even more reason to develop and deploy rock-solid user experiences. But, almost universally, they do not.

Why not is a mystery. The basic principles of user experience are very simple: understand who your customers are; know what they want to do (or what you want them to do); and design pathways to make those things easy. A simple plan, but in the real world, somewhere between theory and execution, it all goes off the rails.

Hotels make for excellent case studies in this area. Whenever I travel and visit a hotel, I assess the user experience, because I can’t help it. Somewhat pessimistically, I don’t expect the UX to measure up, and I am usually right. The question is, by how much will it fall short?

Continue reading “The User Experience of Hotels”
Categories: UX

Test Against Scenarios, Not Problems

In The Hitchhiker’s Guide to the Galaxy, an experiment to find the meaning of life yields a famous answer that cannot be understood without asking: Uh, what exactly was the question?

Clarity is critical in user testing. Testing sessions often include pointed questions like: “If you wanted to change the language to French, how would you do that?” Testers are wondering if the user will think to look in a certain place for a way to complete the task. Here is a problem, they are saying. Solve it.

However, giving a user a problem to solve is less useful than outlining a scenario and letting them frame the problem themselves.

From the perspective of the user, when asked for an answer, she must first be sure she understands the question. This happens on different levels. Subconsciously she might say to herself: But I don’t speak French. Why should I change the language? Consciously she might wonder: Is the solution somewhere unlikely? What is the question getting at?

The example above is very simple, but as tasks become more complex, understanding the syntax and intent of the question becomes a problem in itself. It introduces a level of uncertainty that clouds the purity of the test: even if an answer comes readily to mind, she must then reconsider her understanding of the question, to see if the two match. Solving someone else’s problem is much less intuitive than solving your own.

If the tester frames the question as a scenario, rather than a problem, that uncertainty evaporates. “The website is in English, but you speak French. What will you do?”

The difference seems trivial, but in user experience trivial things matter. Now the user can frame her own problem (I need to change the language) and then begin working on the solution. She already knows she understands the problem, because she articulated it. This approach yields more authentic test results, since in the real world we don’t have annoying UX testers asking us leading questions. We identify, and solve, our own challenges.

Categories: UX

Everyone is Their Own Personal UX Guru

“I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it.”

This quote is often attributed to Bill Gates, but given the magnitude of his achievements it’s hard to imagine him using it as a guiding philosophy. Something being difficult to imagine doesn’t make it false, of course, but in this case the true source was Frank Bunker Gilbreth Sr., an engineer and one of the first true usability experts. And he was talking about bricklaying – a task one might reasonably think much less-nuanced than inventing programming languages.

Either way, is it true that a lazy person will find an easy solution? They might, but easiest doesn’t mean best, and lazy solutions cut corners. Lazy people are not good for business.

Given the choice, though, most people will at least look for a more efficient solution, because it’s human nature. All of us have the same innate tendency towards the path of least resistance because less work means more play. We are experts in the subject of our own personal user experience because we optimize our lives towards efficiency. That’s not lazy, it’s smart.

To design the easiest path to a goal, don’t ask how a lazy person would do it. Ask how an efficient optimizer would do it.

Categories: UX

Who Are You Building That For?

We build products for ourselves or for customers, and the difference isn’t always clear.

When I started out as a designer we knew (in theory) that we were making websites for clients, so they could make money from customers. But, from the vantage point of experience, it’s easy to see that we were really making stuff for ourselves: for kudos, money, reputation and further opportunity. Form always trumped function. Before design was usability-driven, it was ego-driven. It seems absurd that we ever thought otherwise, but Jakob Nielsen, and his Bauhaus-like functional idealism, was right all along. We’re sorry, Dr. Nielsen.

Perhaps it mattered less in that age. In the mad rush to dominate the internet, websites back then had shorter lifespans. Big brands were content to spend vast sums to be seen as innovators, and if we didn’t get it right we’d do another one next year anyway. And even if we’d asked the right questions, would there’ve been enough data to provide useful answers?

Perhaps not, but these days there certainly is, and we should be smarter. Secondary motivators – awards, reputation, money, social likes – will always exist, but usually as goals at the end of the wrong path.

To uncover the primary motivator, ask the primary question: who are we building this for?

Categories: UX