Category: UX

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?

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.

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.

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.