Jargon annoys me. Especially when someone tries to “namify” a process in a way that seeks to own and obscure the method rather than reveal it. I’d love to find it funny and be flippant that professional practise gets obscured by jargon. But too often giving a name to a process implies that the thing is an artefact, a finished product, rather than a living process.
I remember being on a conference call where a group of really experienced IAs were going through a list of things we were expected to be experts in. Time and again we’d read out the name of a thing and struggle to find a definition before all realising that we did the thing all the time. Often, jargon tries to paint complex patterns on what would otherwise be plain. It’s like a curtain obscuring some self-important plonker, posing as an alchemist. Strip away the jargon and he’s just a bloke, not an actual wizard. Jargon is a camouflage technique.
I mention this because in a sentence I’m going to use the word ‘heuristics’, and I don’t want to be accused of using jargon. I like to think of heuristics as rules of thumb. And while testing is definitely the surest, cheapest and most interesting way to ensure that the thing you’re building is the thing that the people you’re building it for want, I think thumbs are probably the most important element of a user-centred design approach. Heuristics shape and refine practise. It shouldn’t be a stage in a design process – it’s at the heart of the process.
Thumbs up
As designers, every decision we make is based on our expertise, talents and experience. We build a working ‘play-book’ of strategies that we implement as we solve design problems and create solutions. This doesn’t mean we come to every problem with a ready-made solution – one other thing I dislike about design is people who trot around with a shiny solution desperately looking for a problem to solve with it. But as we grow professionally we all collect a set of tools that we use as we solve problems. I like to think of this as the wisdom of thumbs, possibly in counterpoint to the wisdom of crowds that we get through testing.
And occasionally we need to describe the techniques we’ve collected to others – so we need to be careful about the way we describe them. Maybe part of the problem is the ‘granularity’ of a technique and description. We all need to share what we’ve learnt so that we can get better together. And published methods and techniques will often hold secrets, hard won tips that started out as improvisation in response to a specific circumstance and were found to be better than the original. Professional practise should be a process of evolution where techniques are evolving and responding to challenges. Being creative means we’re not limited to the same set of tools. We can adapt the tool to the current challenge, we can follow our thumbs, but hitch a lift when we need to and bend the course to suit our desired destination.
Take cognitive walkthroughs, for example. Cognitive walkthroughs involve one or more professionals experiencing an interface as if they were a user. They use their imagination and try to complete tasks. According to Jim Ross on UX matters, if we’re doing this properly we should be asking ourselves four questions from the user’s perspective:
[blockquote]
- Will the user try to achieve the right effect?
- Will the user notice that the correct action is available?
- Will the user associate the correct action with the effect he wants to achieve?
- If the user performs the correct action, will he see that he is making progress toward a task’s solution? [/blockquote]
Jim explains that cognitive walkthrough’s didn’t catch on as the method. He suggests it’s because they’re inflexible: “If you’re going to use a technique that doesn’t involve users, why not use something that’s simpler and more flexible?” he asks. I couldn’t agree more. But I fear the problem with many methods isn’t the method itself – it’s the idea that the ‘right way’ to implement a method implies inflexibility.
The questions that we’re told to keep in mind during cognitive walkthroughs are helpful, but just like many descriptions of methodologies they suggest there’s one way to ‘do’ a type of technique – rather than a range of possibilities and implementations. They also suggest that these questions are part of a process separate to design – I think these and other techniques should be ghettoised into distinct research phases, this kind of thinking should be a part of our design practise.
A designer playing the part of a user
Robert Houdin is dead now. But during his life he did things to inspire Houdini to adopt his name and said:
[blockquote]a magician is an actor playing the part of a magician. [/blockquote]
I like this quote. And I think good designers are similarly required to act sometimes. User-centred design asks us to be designers playing the part of the user. If we’re doing this well, throughout every decision we’re not just using our experience as experts, we’re also considering the experience as if we were the end user. We need to be able to shift perspective as we design.
I think that the spirit of cognitive walkthroughs is bang on. It acknowledges that designs aren’t static objects – we design experiences. We can’t design without actually considering what is going through the mind of our user as they use the thing we’ve created for them – otherwise we haven’t really made it for them, have we? This is what the technique reminds us of – it’s a tool to pop in our back pocket to use when times are right.
As we get more experience, our thumbs get wiser. So why would we take to unthinkingly following a formula when our skills allow you to adapt, combine and refine the tools in our arsenal to address the current challenge? Printed, prescriptive ‘recipes for success’ might help out beginners, but they shouldn’t become a crutch. Expertise implies the ability to synthesis knowledge and make it practicable. Formulas will only get you so far. An expert will suit the solution to the problem, not try and force things to work the other way around. Actors playing a part implies that there are roles for us to play – fine scripts that lead the way to success, but the alchemy of design is in improvisation.
So how do we negotiate the need to share techniques to evolve professional practice with the implied notion that there is a ‘right’ way to do things? We can’t. But we can continue to publish and share what we’ve learned. We can give techniques and processes names, because it’s the easiest way to find and share things, but resist the temptation to conflate the naming of something with the notion that it is now a finished artefact. Processes live through their application, not through their description. This is what the rule of thumb is all about. We can pick from the range of things that worked in the past, pick them up and mould them like clay to suit the current challenge.
Leave a Reply