User Centred Design

[#1]

There's been a lot of talk about user centred design at PlusNet recently. Everyone seems to agree that it's a good idea but not has been done about it. This is about to change... it's time to act! What is User Centred Design? The traditional design process works something like this:

1. Gather requirements
2. Write a specification - possibly go through a few iterations, refining the spec
3. Make a prototype - again, maybe refine it a few times because The Boss doesn't like the font 😉
4. Build
5. Test - internally or with a public beta
6. Launch!

It isn't until the very end that the users get to actually try the product, by which time it's way too late to make any significant changes. But that's OK because we're professional designers and we already know what users need, right? Well, not really. The trouble is, the more we use computers, the more we lose sight of how other people use computers. I see so many people double-clicking on web links. To us it's obvious but have you tried explaining the difference between things that require a double-click to activate (e.g. icons) and things that only require a single click (e.g. links and buttons)? It's not that easy. The point is that nobody knows what users need — not even users! Oh, rats. How do we get out of this one then? The answer is... (can you guess?)... user centred design! User centred design puts the user at the centre of the design process (there's a clue in the name there):

1. Gather requirements - ideally from your users, i.e. ask "what would you like the product to do?"
2. Build some paper prototypes and test them on users (see below)
3. Make a real prototype - test it on users
4. Build - test it on users
5. Launch - test it on users!

As you see, at each stage we're testing the product on the people (or at least the kind of people) who will be using it. This means that failures in the initial design can be caught very early on when changing the design is quick, easy and cheap. "Oh so people can't find the 'add' button in the top right corner? Let's put it at the bottom." Then test again. How will this help us? Not only does this result in a better product that more people will enjoy using but it also saves loads in support costs because people will have less trouble using it! So right now we're doing a trial run. We selected the 'Manage my Mail' tool in 'My Account' as a candidate because many people have been having difficulty with it recently due to the spam incident. For this trial we'll be selecting users internally to save time but finding non-techy people in Plusnet is actually quite hard! If you're in the Sheffield area and would like to come in for an hour or so one day to help out that would be awesome! I don't think we can give you any money but we'll certainly get you a free lunch, a game of pool and Wii tennis or whatever else :) So hopefully this trial will be a success and we'll be integrating user centred design into the business much more. I'm excited! Further reading:

• Pioneering a user experience process
• Don't make Me Think

What is User Testing? User testing usually involves three steps

1. Find some users - from elsewhere in the company, off the street, from a recruitment firm, friends & family... wherever. It's important that the users match your target demographic though. No point testing on teenagers if you're building a website about mortgages.
2. Sit the users down, one at a time, in front of your site; set them some tasks; watch them fail! Every time a user has difficulty performing a task, that's your website failing and it needs to be fixed.
3. Collate the results and feed back to the design team. Ideally you'd have the whole design team watching every user test but that's not usually practical and might be a bit intimidating for the user!

Further reading

• User Testing on the Cheap
• Getting Buy-In for Usability Testing
• The Things You Can Learn from Usability Testing

What is Paper Prototyping? Paper prototyping is exactly what it sounds: instead of designing your interface on a computer, just draw it on a piece of paper! You can even 'run' paper prototypes where one person acts as the computer, responding to user actions by moving switching bits of paper or even drawing new 'screens' on-the-fly. This has several advantages:

1. Encourages participation from less techy folks. Adobe Macromedia Design Studioshop Max 9.0... what?! Using specialist software locks out people who don't know how to use it. Paper, on the other hand, is far more accessible.
2. Easy to change. Don't like that layout? Here's another sheet of paper and a pen. Need to move that login box? Here's some scissors and some glue. Old school cut & paste.

Further reading

• Paper Prototyping
• Using Paper Prototypes to Manage Risk

[#2]

Paper prototyping? I think it's just an excuse for PlusNet staff to start throwing paper aeroplanes at each other.

[#3]

On the User Centred Design steps, you forgot Step 6: Profit!!! Will be cool to see a follow up to this afterwards to see if we can measure the difference it makes.

[#4]

So that's why they keep asking us what we had for breakfast. Oops, that was PlusToast not PlusNet! On a more constructive note, please also involve those with visual and agility difficulties in the early design process. User-selected large fonts can cause buttons to be off-screen making it more difficult for the user to find an important button - like "Continue>".

[#5]

Oh look - a design procedure that the rest of industry has been using for the past century! Actually, you haven't got it quite right. Because your first question "ask the users what they want ..." doesn't get you the right answer or a useful answer. If you are going to do this the full tried and tested way that car manufacturers etc have been using for years, then you do this. You first make a list of outcomes - these are the possible end point of what ever set of actions that the user will take. For instance let's take searching in a forum. The most obvious out come is that you get a list of results from entering a word and pressing the search button. But ... An end result could be that they get every post that includes the phrase "fat lady sings" in it. On the other hand, it could be that it includes every post that has the three words fat and lady and sings in it, but not necessarily as a phrase. Added to that it could be that you want all above, but only posts that haven't been read by the poster. So there are a lot of possible combinations and it is very quickly evident that your possible outcomes may or may not be achieved by your text field and search button. But what outcomes do people actually want? The average geek will always demand a search box that allows every possible permutation of searching from a multitude of check boxes, drop downs etc. But is this reasonable? If you designed a car where there were a multitude of ways to start the car depending on where you wanted to go, how many people would actually want to drive it? Product research, therefore, always starts with not just listing possible outcomes, but then putting those to research (focus groups, random members of the public, etc) to find which outcomes the user is really interested in, what will be useful to them. Now you have your little set of outcomes, you can put together your paper proposals - normally several - and test these to see which one or more gets the thumbs up. From these results, you then put together your first prototypes. These are possibly not actual working designs, but cheats that look like they are working, because at this stage you are not actually trying to solve the technical problems. In the case of software, you would also be creating several user manuals for each solution, and/or tutorials etc. This is because a great solutions is a bad solution if it is not easy to explain! Both elements have to be worked through and tested. Having done that and boiled everything down to one solution, now you go and build it. Years ago I was involved in the testing of a snack called Moments. We were making test TV commercials by basically filming story boards and putting a quick voice over on it. Believe it or not, this was at the very beginning of the design process. The company first came up with how the product would be advertised, fulfilling through advertising the end users expectation of a snack - how they would use it, what they wanted out of it, when they would use it etc. They came up with 5 possible snacks and five different advertising approaches for each snack. These then went into testing. Two years later, with all the results analysed, Walkers gave the results to their snack boys who designed the snack that fitted the best advertising. Gold Blend coffee was done in the same way. The famous couple falling in love etc was designed years before the coffee was even produced. Now, I wouldn't spend that long on designing a search button, but you can see the value of such a seemingly tortuous procedure!

[#6]

"Two years later, with all the results analysed, [...]" And that's the problem. We're a relatively small team working to meet rapidly evolving customer expectations. We don't have the resources to take on that kind of operation (or the cash to outsource it!). It makes more sense for us to do many small, qualitative usability tests leading to an iterative design process in which we get it 95% right in a short timespan than to do one huge quantitative test in which we end up with a product that is 99% right but obsolete