I was on a panel at the IA Summit over the weekend titled ‘where does IA fit in the design process‘. I was staking a case for Agile UCD, and these are the slides I used to outline my case in 5 minutes or less (Of course, you could talk about this topic for hours, so this is very much just an overview!).I’d be interested to hear your thoughts/experiences!
Here’s a typical story.
A project is in its final phases when it gets to the part of the Gant chart that says ‘usability testing’, and so they do.
People come in and are asked to perform tasks, and so they do, with greater or lesser degrees of difficulty. And yet, something else is wrong.
It’s not so much that they *can’t* use your website, it’s just that they don’t want to.
People ask me all kinds of questions about usability. What are the most common usability problems? What’s the best way to make sure our site/application/system is usable? That kind of thing.
It’s pretty clear when they ask these questions that they’re thinking on the presentation layer. Is that button in the right place? Is it big enough? Has it got the right label.
Now, don’t get me wrong, the presentation layer is important, but it’s not the biggest usability problem I see in my work. The biggest problem is that you’re designing something that people don’t care about. You’ve got your proposition wrong.
What’s your proposition? Well, basically it’s the value you’re offering to your customer. Are you offering something they want? Are you solving *real* problems for them? You’d be amazed how often this is not the case, and how often people don’t know about this until they’re about to launch their product or, worse still, once it has launched and is failing.
The diagram above is one that I pull out fairly often these days (it’s another one I’ve borrowed from Flow). It talks about how you need to design from the proposition down. You need to get the value offering right, then look at the model for delivering that value to clients at a conceptual level, then start looking more at what elements go on a page, what functionality is included, how it is structured and ordered. Unless you have all of these in order, it doesn’t really matter where your buttons go or what they’re labeled. Appearance level usability is the most superficial, easily remedied and perhaps even least important of all of the levels of design.
If you’ve got a flaw in your thinking at the top of the chain, then no amount of surface usability is going to save your product.
So, how do you approach this kind of Proposition design and usability? It’s pretty simple really, you test your proposition. This kind of testing (or really, research) is more about talking than tasks, and it’s about understanding your customers better and checking whether you are conceptually on the same page as they are.
I’ve been involved in several projects just in the past twelve months where doing this kind of research has saved companies tens of thousands of pounds (double that if you’re talking dollars) in *not* designing and developing functionality that either was unwanted by their customers or was designed to solve the wrong problems.
Working this out when you have a few pencil sketches or a couple of visio wireframes with a few days invested is an awful lot better than working it out when you get to the ‘usability testing’ line in your Gant chart.
So, if you really want my advice about usability, it’s that it starts right at the very beginning. Before a line (or a box) has been drawn. If you’re not designing the *right thing* then no amount of design expertise is going to get you a really usable product.
Talk to the people you’re designing for.
You’ll save lots of time and money and look really smart.
People say that it is some kind of Steve Jobs special sauce that makes Apple the company that it is, but as this Fortune article reveals, they reap rewards from using design techniques that we all have access to, and should *all* be doing. All the time.
These techniques include prototyping:
“One of the best pieces of advice Mickey ever gave us was to go rent a warehouse and build a prototype of a store, and not, you know, just design it, go build 20 of them, then discover it didn’t work,” says Jobs. In other words, design it as you would a product. Apple Store Version 0.0 took shape in a warehouse near the Apple campus. “Ron and I had a store all designed,” says Jobs, when they were stopped by an insight: The computer was evolving from a simple productivity tool to a “hub” for video, photography, music, information, and so forth. The sale, then, was less about the machine than what you could do with it.
But looking at their store, they winced. The hardware was laid out by product category – in other words, by how the company was organized internally, not by how a customer might actually want to buy things. “We were like, ‘Oh, God, we’re screwed!'” says Jobs.
But they weren’t screwed; they were in a mockup. “So we redesigned it,” he says. “And it cost us, I don’t know, six, nine months. But it was the right decision by a million miles.”
and User Research:
“When we launched retail, I got this group together, people from a variety of walks of life,” says Johnson. “As an icebreaker, we said, ‘Tell us about the best service experience you’ve ever had.'” Of the 18 people, 16 said it was in a hotel. This was unexpected. But of course: The concierge desk at a hotel isn’t selling anything; it’s there to help. “We said, ‘Well, how do we create a store that has the friendliness of a Four Seasons Hotel?'” The answer: “Let’s put a bar in our stores. But instead of dispensing alcohol, we dispense advice.”
OK. So maybe you don’t have budget to build a store twenty times over, but everyone has time and budget to do a paper prototype and show some people. Even if that’s all you can do, do it.
Both of these techniques have been key in helping Apple make more dollars per square foot than stores like Saks or Tiffany – a pretty successful outcome by any measure, not to mention the way that the experience of the Apple store contributes to the over all Apple brand equity.
WWAD? Prototyping and user research. Go crazy.
For my recent BarCamp session I shared a design technique that a colleague and I developed quite recently that we’ve found to be quite successful in both generating great design ideas and developing consensus about the design approach for projects within a multi-disciplinary team.
We call this technique Design Consequences, due to the similarity it has with the similarly named childrens games. We tend to use it in the earlier stages of the design process, although it can be used for more detailed interface design problems.
So, how does it work? It’s pretty simple really.
What you need:
- a clearly articulated design problem and design goal(s) - for the BarCamp exercise our design problem was to design an electronic version of the BarCamp session wall where people could add their own session and choose which sessions they were going to attend.
- some design ideas or components – when I do this in a client context, we do this by spending time beforehand looking at our specific challenges and seeing how other people have approached them, and trying to understand design techniques or principles that work (as well as those that don’t). This gives people access to a much greater repoirtore of ideas to draw in the Design Consequences exercise.
- a multi-disciplinary team - try to get the entire team if you can. The exercise works best with no more than 8 people involved, but it can be done with more if required. Get management to the table, bring all kinds of designers, bring the product managers and marketers, bring your developers. Bring everyone you can, as long as they’re familiar with the project and the design problem.
- lots of paper and markers and post its – make them as colourful and fun as possible. Make it look like a crafting session. A sense of play and enjoyment is key to this exercise.
- some examples of the type of output you’re expecting – anything that starts with the word ‘design’ can be very intimidating and scary. Lots of people ahve been told throughout their lives that they can’t draw, or that they aren’t creative. I have some *very* scratchy samples that have been created by people who design for a living. I show these before we get started so that people realise quickly that pretty drawings are not part of the equation.
- A bundle of energy – you need to be just a little bit hyper to run this exercise :)
What you do:
- Round One – everyone has seven minutes to design, individually, the the first page that users would see when confronting the ‘design problem’. So, a typical example would be a website homepage, but it could be any part of an application or website or even, say, an email. The faciliator(s) should participate, but keep an eye on the clock and give some warnings with a few minutes to go, and again at about 30 seconds.
- Round Two – here’s the consequences twist. Everyone picks up the page they’ve designed, then passes it on to the person on their right (or left, it doesn’t really matter). Everyone then has to review the page they’ve received (ask for clarification from the original designer if it’s a little sketchy in places), then decide – if you were the user, what would *you* interact with, and what would happen next. You have seven minutes to draw ‘what happens next’. (Don’t tell people about Round Two before Round One, it’s much more fun when it’s a bit of a surprise).
- Show and Tell – we then go around in a circle and each person describes the page they received, what aspect they chose to interact with and why, and then describes what they designed next. Discussion is encouraged.
What do you get? Lots of great data, and lots of great conversation fodder.
It’s a good idea to capture as much of this as possible as you go around the group. Of course, the best way to do this is to write up ideas onto post it notes as you go and stick them on the wall. There should be an ‘in’ section of the wall and an ‘out’ section of the wall. (‘In’ means that the idea has legs for this particular design problem). Affinity sorting on the run also helps to draw out the key themes or ideas that have emerged from the exercise. You should be leading the group discussion, helping the group to gain consesus and make decisions as to the design approach to be taken in solving the design problem, and trying to document these decisions as you go.
This process can be quite time consuming and intense, but more often than not there will be a few key ideas that the group is particularly enthusiastic about and that really propels the decision making.
By the end of the session you should be in a position where everyone is in agreement about *what* will be included in the wireframes that comprise the next phase of the design process.
Why would you use this approach?
- It makes a great change from the talk-fest of meetings
- It generates lots of ideas – and often some really great ones
- It stops people getting to attached to their design ideas and makes evaluation and critiquing more effective
- It helps get all the team feedback and ideas into the pot (in particular, it’s great to get management and technical input at this stage)
- It drives buy-in, involvement and consensus
- It pulls in cross-discipline scills (for example, developers are often really great at quickly identifying great ID approaches for Rich Internet Applications)
- You’d be amazed what you learn earlier rather than later by involving the entire team at this early stage
- Getting lots of brains involved in the design process can uncover some really creative gems
- It makes the design process faster
- It’s fun!
So, there you have it. Some quick notes on a technique that’s been quite useful for me lately. I’d be interested to hear what you think of it and if you try it, to see if you too find it useful.