A UX manifesto
8 minutes read
Manifesto (noun) – A public declaration of intentions, opinions, objectives, or motives, as one issued by a government, sovereign or organisation.
Dictionary.com
I usually shudder when I hear the world ‘manifesto’. This is principally because it’s such a politically loaded word. It’s a word that is all too often uttered by untrustworthy politicians (is there any other kind?) before rattling through a long list of pre-election promises that will be completely ignored once they have hoodwinked people into voting for them.
One manifesto that I’m happy to say I don’t shudder when I hear mention of it is the Agile Manifesto. Not a political manifesto, but one outlining some guiding principles for software development.
The Agile manifesto came out of a frustration. Frustration that the traditional waterfall process, whereby all requirements are defined upfront, designs drawn up, implemented and then tested in a very linear fashion is generally a very painful and ineffective way to deliver software. In February 2001 17 developers got so frustrated (you know what developers are like) that they decided to get together to come up with something better. That something was Agile software development, and to help communicate the guiding principles of this brave new approach they put together the following Agile manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Inspired by the Agile manifesto I have put together my own UX manifesto to encapsulate and communicate what I believe are some of the key guiding principles of UX. Here they are…
Collaboration over siloed working
I’ve written before about how UX design is a team sport, and is best played as one. Collaboration is key to great UX design. Collaboration with other UXers; collaboration with developers; collaboration with domain experts; collaboration with users; collaboration with business stakeholders. The list goes on.
Because UX sits at the intersection of user needs, technology constraints and business goals it really can’t be anything other than a collaborative endeavour. The alternative is the sort of sling it over the fence mentality that some design agencies sadly still exhibit. Rock star designers will go away to their ivory tower, create some seemingly fantastic designs (I say seemingly because on closer inspection they often don’t stand up to scrutiny, being largely based on assumptions) and then sling them over for the poor development team to implement. The stakeholders complain that they’ve not been included, the development team complain that the designs are impossible to implement and the poor users are left with a design that invariably doesn’t actually address their needs.
Interactive prototypes over static documentation
I hate writing requirements documentation. I really, really do. It truly is a soul destroying activity, like mowing the lawn, or watching Celebrity Big Brother live. Requirements documentation never gets read, it needs to be constantly updated as designs and requirements change, and it can be really hard to find the right level of detail. Too much and development teams will run away screaming. Too little and they have to ask so many questions that you wonder what the point of the documentation was in the first place. This is why I’m such a fan of interactive prototypes.
Interactive prototypes are the best way to convey designs, and design requirements because they show how designs work in context. Rather than document in excruciating detail what happens when a user clicks or taps on something, you can simply include it as an interaction in the prototype. Developers love prototypes because it shows them how the design works. Stakeholders love prototypes because they can see the design brought to life. UXers love prototypes because it allows them to see what designs will look and feel like in the flesh. Most importantly prototypes are great for capturing feedback from users by allowing them to directly experience and feedback on a design.
With the wealth of prototyping tools out there (take a look at my guide to UX prototyping tools for a full rundown) it’s now ridiculously easy to rapidly create interactive prototypes. The days of excruciatingly detailed requirements documentation should be well and truly over.
Designing for users over designing for stakeholders
‘UX’ is of course short for ‘User Experience’. I’ve always wondered why it’s ‘UX’ and not the more grammatically correct ‘UE’. I guess ‘UX’ just sounds a bit sexier. I want you to remind yourself exactly what ‘UX’ is short for every time a stakeholder tries to dictate a design because it’s users you’re ultimately designing for, not stakeholders. Sure you need to please stakeholders, after all it’s usually them paying the bills, but it’s users who will dictate the success or failure of a design, not stakeholders.
Great UX is about finding that elusive sweet spot. The one that exists between user needs, technical constraints and business goals. Stakeholders, will be thinking first and foremost about business goals. Technical teams will be thinking first and foremost about technical constraints. It’s really therefore up to UX and UXers to look after users, by thinking first and foremost about their needs.
What users need over what users want
I’m a parent of 2 small children. Like every parent I’m painfully aware that all too often what children need, is very different from what children want. If I always gave my children what they wanted, they’d be exclusively eating chocolate, cake and ice cream and spending most of the day watching Dora the Explorer, and Power Rangers!
As Steve Jobs famously said, “It’s not the customers job to know what they want”. No it’s not. But it is the job of UXers to try to find out what users need. I’ve written before about why the user is not always right. You can’t find out what users’ needs by simply asking them, you need to understand them. You need to understand their problems, their goals, their frustrations, their motivations, their jobs to be done. Sure you can ask them and should absolutely include users in every step of the design process, but don’t expect them to do your job for you.
What users do over what users say
I’ve either facilitated or observed well over a hundred usability testing sessions over the years. Hours upon hours of watching people use technology of one kind or another. One common theme in all of those sessions is that what users say, can be very different from what users do. I wonder, does something like this sound familiar to you?
Me: So, overall how easy to use did you find that?
Participant: Oh, it was a doddle. No problems at all.
Me: Really? You experienced no problems at all?
Participant: Nope
Me: What about the 3 tasks that you were unable to complete? Or the screen that you said had clearly been designed by a ‘moron’?
Participant: Oh yeah, but apart from that, it was really easy to use.
Users might be too polite to say that something is hard to use, or they might not want to admit that they have to employ a sneaky work around. Heck, users might not even remember that they experienced problems in the first place. As the peak-end rule tells us we tend to remember only fleeting snap shots of an experience. When someone tells you that they found something to be easy to use, when you observed differently, they probably genuinely mean it.
Whether it’s usability testing, observing users, capturing usage data, or simply asking someone to describe a task or job that they go through, it’s what users do that really counts, not what they say.
User insights over assumptions
I’ve written before about why designers should research, and researchers should design. User research and the user insights derived from good user research, are the bedrock of good UX design. Without user insights you are building on assumptions, and like a house built on flaky foundations, a design built on assumptions is destined to come crumbling down.
Assumptions are not necessarily a bad thing. Moving forward with working assumptions and then validating them along the way can be a great way to progress a design (just so long as you do actually validate those assumptions). However, as the great man Steve Jobs once said, “The broader one’s understanding of the human experience, the better design we will have“. User insights should be driving your UX designs, not assumptions.
Pragmatism over user-centred design pureism
A few years ago I gave a presentation with the snappy title of, How I managed to kick the UCD habit & learn to love lean UX at UX Cambridge. In the talk (which incidentally you can watch online) I spoke about my own experience of user-centred design (UCD) and of how I had come to embrace a new dogma – lean UX.
You see I have a love hate relationship with UCD. I love the idea of putting users at the heart of the design process, but I hate the fact that UCD projects often don’t get off the ground, can be slow and expensive to carry out, and don’t necessarily always deliver the goods. I think that some of this is because we UXers can often be somewhat purist when it comes to UCD. “Oh no, we need to usability test that with at least 12 users before we can even think about releasing it. Oh we need that budget alone just on the user research activities!”.
I’m of course a fan of lean UX, but what I think is most important is to be pragmatic. In the talk I gave the analogy of MP3s. Now an audio purist (a.k.a. audiophile), the kind of person that doesn’t flinch at the thought of spending a small fortune on their precious Hi-Fi setup will rant and rave about the short comings of MP3s when compared to CDs, or even better, LP records. They will complain that the the treble on MP3s is always terrible, the music sounds so flat and artificial and that MP3s ruin the listening experience. But to most of us, listening on our tinny headphones or cheap speakers, in an already noisy environment, MP3s are good enough. Sure it would be nice to have a format that delivers better, richer sound, but being pragmatic, the sort of quality that MP3s deliver is fine 99% of the time.
You should apply the same sort of pragmatism to UCD. Do just enough to deliver the sort of benefits that UCD can bring, but no more. Don’t be afraid to flex the sort of UX research and design activities that you undertake, but certainly don’t be a UCD purist.
My UX manifesto
So here we are, my UX manifesto. Let me know what you think, and what guiding principles would make it into your UX manifesto.
- Collaboration over siloed working
- Interactive prototypes over static documentation
- Designing for users over designing for stakeholders
- What users need over what users want
- What users do over what users say
- User insights over assumptions
- Pragmatism over user-centred design pureism
(Note: I still believe that there is value in the items on the right, just that those on the left are of more value.)
Image credits
Robert Kennedy speaking to a crowd in 1963 by Leffler, Warren K.
