UX & The Weight of Expectation

I’ve been thinking increasingly about the importance of user expectations in planing an effective user experience.

The greatest asset we have in going to meet the challenge of the user’s mental model is simply knowing it exists in the first place. A huge part of user research concerns itself with the needs of the user, but it’s important not to let this spill over into a hapless quest for what the user wants.

Don’t Give Me What I Want

User requirements are one of the basic tenets of user experience design. We know however that if the user got everything they wanted then we would almost certainly have a very messy interface to contend with, one overflowing with superfluous functionality and options. In short, what the user wants is often at odds with that they truly need.

This points to a very particular approach to user research.

In my own experience when the opportunity exists to talk to users in person the line of questioning should monitor the distinction between wants and needs very carefully. When talking through a particular system with a user group, the type of question I try to avoid is “what do you want to see on this page?”.

Love Me, Love My User

A quick aside here – people are amazing. Watching them in action on a website or an application is possibly the single greatest education a UI designer can have. They won’t always do what you expect them to do or what you want them to do. They will however do what they feel they need to do in order to achieve a goal. And that, of course, can be endlessly frustrating for designers.

In research as in life, framing a question can be as important as the question itself.

An open question such as “what would you like to see on this page?” (as a crude example) will garner very different responses from “what would you expect to see on the next page?”. The former can lead to some serous flights of fancy, where the entire web as we know it has to be re-engineered to match the heady goals set for what the site has to provide. Expectations are so much more important than perceived need.

Let Me Down Easy

When engaging with stakeholders, the same types of enquiry can help to keep a sense of promise to a minimum. “What do you want…” infers a degree of promise about what will be delivered. So much of stakeholder engagement is about inclusivity, giving people a platform to make contributions to a process that values their input. To over-promise in these situations is to mislead participants as to what will be done with their feedback. “What do you expect?” carries with it less of an overt sense of promise, and more one of discussion.

What’s New, Pussycat?

And what, you may ask, of innovation? If we only deliver in line with expectations, how does anything new enter the mix? Clearly, delivering “to expectations” is a lowly objective for any project. However, delivering what users expect is an imperative. The point is that we are not constantly seeking to reimagine the web. The time for reinventing conventions is gone. Lord knows we saw enough “innovative” – some might say wacky – attempts at elements such as navigation systems pre-2002. We have been left with a web that, generally speaking, conforms. And there is no shame in that. Most of our consumer products do the same; even the iPod delivered innovation in a very familiar package, building on the form factor that products such as the Walkman had created. Everyday innovation almost always arrives in tandem with the familiar. And delivering based on expectations does not preclude the element of delight.

Conclusion

Users do not like the unanticipated, but they will react positively to a system that simplifies a task. Strive for innovation of course, but be careful how you define it. And make no mistake – managing expectations is possibly the single biggest task faced by UX practitioners. As techniques such as responsive design gain traction, the issue of expectations grows ever more complex. In user research, assume nothing… and expect the unexpected.

A few words about the Five Whys

Following this piece on FastCo Design about getting to the root of a problem, I thought I’d share a little experience of using the ‘Five Whys’ technique in the field, plus a few observations I’ve made on its use for user research for the web.

For those unfamiliar with it, the Five Whys involves posing an initial query (e.g. “Why is online booking so difficult on this site?”), asking participants for a top-level response, then gradually peeling back the layers of their insight by successively asking what makes their previous answer true. This is repeated until five answers have been offered, with five seen as the optimum number of levels.

Firstly, it is a great technique. Hours could be spent in discussion with users or stakeholders resulting in only a fraction of the information yield that this provides. When it flows well you will uncover hugely useful insights into underlying problems that could only come from those closest to the issues. When it doesn’t flow so well, you may be left with one of those activities that feels like a step too far, when you could really be pushing on with focusing on the salient issues. The common issues I have encountered using the technique in practice are:

The problem is obvious to participants – in this case, a problem can be so apparent that everyone nails the problem within just one or two steps. This can lead to some uncomfortable forced extrapolation as participants attempt to reword what is essentially the same point

The problem is obvious to you – as with all research, check your own preconceptions at the door, and listen. Your ideas about what the real issues might can blind you to the smaller details that might be hugely significant.

The problem is too abstract – what you are looking for may not easily be encapsulated in participants’ submissions. Visceral factors will not be readily dealt with in an environment where participants need to submit succinct, specific thoughts.

As with all user research, it’s best to simply persevere and work with the data as you find it. If the sample group is small enough, you’ll very quickly get a sense of obvious bias on the part of any participants. And needless to say if the group is large, anomalies will similarly stand out.

I have found it best not to reveal and discuss each participant’s answer before moving on to the next “why”. One of the major barriers to authenticity of results in research is that participants do not want to appear ‘stupid’ or caught lacking in front of other participants; revealing the line each participant is thinking too early is to invite groupthink into the discussions. Best instead to get all contributions in before proceeding with linking and clustering different responses.

Needless to say I wouldn’t base an entire workshop or test session around any one single activity, and the same applies here. Conclusions reached as a result of this activity should be cross-referenced against the results of other activities or discussions. But as a short and sweet method of quickly getting a group’s insight into problems – ususally as an opener – the Five Whys is a worthy addition to your research toolkit.

—–

The Five Whys technique has been credited separately to both Sakichi Toyoda and Taiichi Ohno of the Toyota Motor Corporation and is one of many excellent techniques collated in Dave Gray’s Gamestorming.

A sense of completion

Throughout a career primarily as a visual designer, I’ve always struggled with the judgement of when a piece of work is “done”. In graphic design, the urge to continue adding, embellishing is almost overwhelming. Maturity and of course experience influence better decision-making, but inevitably you find yourself mentally revisiting each project many times in the months after it’s supposedly ‘finished’, thinking of better choices you could have made, better directions you could have taken, better refinements you could have insisted on.

The craftsman’s eye

I often find myself looking at things that my dad made during his life, his joiner’s skills manifesting themselves in seemingly flawless dovetail joints and perfect angles, and outputs consistently fit for purpose.

The end is not nigh

Producing work that is deployed in a digital context brings with it a frustration, a yearning for a sense of completion where you know that something is simply done. This is something that has dogged me throughout my working life to date, whether I realised it or not. The quest for completion led me to acquire technical skills I never believed I would want or need, in what I now believe was the hope that they would bring me a clearer understanding of “finished”.

In short: I’m older now

What this drive for completion has meant for me is a quest for metrics, for data – measurable factors. In joinery, a glance through seasoned eyes can likely offer all the reassurance required to know it’s a job well done. Call it a search for meaning if you will, but moving deeper into UX thinking has brought me closer to the answer; knowing the right questions were asked, the right conclusions were reached and the right recommendations were made is as close as I believe I’m going to get. That sense of satisfaction is what drives me now – a far cry from the “cool” factor that motivated the younger me, an empty quest to mimic the latest ego-centric design trends.

So…

And yet, no matter what nostalgic gloss I might put on it, I am sure Dad would have been able to see in his work where improvements could have been made. It is both the blessing and the curse of the craftsman – the belief that the next project will be closer to elusive perfection that never comes.

Putting the spotlight on ‘delight’

Disclaimer: I tend to react adversely to industry buzzword memes.

A new word has been gradually creeping into the design industry lexicon. Designers should now, apparently, design for “delight” – and once again a word has been introduced without context into the forefront of design debate.

I’ve avoided ‘cool’ for most of my professional career. I don’t do ‘awesome’. I don’t trust it. I don’t strive for it. But I like ‘effective’. Effective I can work with.

The most rational, level-headed thoughts on this come from CX Partners’ Giles Colborne. The points Colborne makes illustrate that we don’t really know what we’re saying. It’s all too easy to drop these phrases into discourse, but it’s quite another to try and measure or define it. And yet invariably a section of the design community, certainly within web design, will regurgitate this type of commentary and broadcast it without questioning what it actually means.

I don’t disagree with the sentiment; I agree fully that ‘delight’ would be a.. um, delightful reaction for users of our work to have. But to impose this on an industry that strives for effective results appears to be imposing very shallow measures on a complex profession. If we’re going to propagate something meaningful, what about “design for success” – how’s that?

“Delight” is a meme and a millstone. It’s another way of saying that we should design something cool. But cool is not a commercial imperative, and it’s place in the process is undefinable. So, at what point should ‘delight’ appear? Until definitions and metrics emerge I will continue to hold such opinion at arm’s length.

There is no magic ingredient for a successfully designed product. There is only process and effort. As with cool, ‘delight’ will be a by-product of an effective outcome.

‘Delight’ happens, just as ‘cool’ happens, most often through rigorous attention to detail and a rock solid understanding of user requirements.

Rockstars, preachers or craftsmen. Time to choose.

My father was a joiner, serving his apprenticeship in the Harland & Wolff shipyard in Belfast. He took a simple pride in his work, going on to develop his skills in a number of construction firms across the city. I don’t believe he would have labelled himself a “craftsman” and I am confident that, while knowing no project he worked on would be complete without his contribution, he had a balanced sense of where that contribution sat in the greater scheme of things. We are fortunate to still have a couple of pieces of furniture that Dad made over the years as labours-of-love. They are simple, usable items.

Intense introspective

When I first read this recent blog post by Jon Tan it resonated hugely. His thoughtful appreciation of our industry is a heartening summary of how quickly things have changed and improved. On reflection though, should we subject ourselves to so much soul-searching based on moments of awkwardness in social situations? Should it matter what others’ perception of us is?

The drive towards a craft-based approach to design for the web continues to gain momentum, something worth fostering. Craft implies care, thoroughness. If we are to be craftsmen, we also need to accept that dedicated craftsmanship is often carried out in relative anonymity. Our contributions, if they are effective, will go unnoticed by most. Intuitive usability implies a lack of conscious effort on the part of the end user which, in turn, suggests a lack of acknowledgement on the part of the user.

My Dad ended his working life as a Clerk of Works. You may not be familiar with that role. I don’t believe Dad would have minded and would quite happily have explained his job to anyone. As our profession matures and we struggle with perceptions and interpretations of what we do, we should prepare for nothing but a muted response from those outside the industry or elsewhere in the design community.

We do great things, but they are not made any greater or lesser by how others perceive them.

You’re either with us or you’re against us

Elsewhere on the web, others appear keen to let us know exactly what defines us.

During his years in trade, Dad came into contact with engineers, architects and tradesmen of all kinds. He took an interest in them and how they contributed to projects. It informed his own work. To the best of my knowledge he never took it upon himself to accuse others of not being genuine joiners. As in all professions, he knew there are two types of practitioners: those who are effective, and those who are not.

I have written before of being proud to work in a profession that places effective practice over showboating. However there has been a trend of late for showy pronouncements suggesting what designers are or are not, depending on their approach. For example:

“…you’re not a web designer, you’re something else.”

“You’re not a user experience designer if…”

“A designer who does not write markup and css is not designing for the web, but drawing pictures.”

The defense for statements of this nature tends to be that they are intended to “provoke debate” or similar. I really wonder. Because sometimes, just sometimes, the intention appears to be to create divisions in our field where there are none; to create a ‘them and us’ based on approach and technique, rather than effectiveness of output.

A situation where a relatively small number of (I should state – exceptional) professionals, with the biggest platforms, who shout loudest feel empowered to define what we should or should not be is one that I’ll call unhelpful. Producing great work sets the best possible example to others in the profession. Sharing of the process gives something back to the community. Does proselytising really add any more value?

Future proof

We want to attract the best possible calibre of people into our industry. A clear sense of ourselves and what we contribute as UI and UX designers is crucial to that effort. Promotion of best practice, which is always changing, is a positive. There are suitable ways and means to do this. I suggest that haranguing those with a different perspective is not one of them.

Reading much of our internal debate of late, I cannot help but hear Dad’s voice and what he said to me in so many situations over the years:

“Just get on with it, son”.

I commend this sentiment to the industry.

——

Update: Following some particularly gracious feedback from Jon Tan, whose blog post is referenced here, I have edited the text of this piece to more accurately establish sources and targets for a number of points made. Thanks to Jon for his input. The original post has been retained for reference.