90 percent of everything : Usability Blog
Written by Harry Brignull

Author Archive

Designing end-to-end user experiences.

November 11th, 2008 by Harry BrignullComments

When you’re designing an experience, it’s easy to look at your competition and get caught up in the normal way of doing things. Rather than being innovative, you end up creating some small incremental improvements.

A better approach can be to look beyond the conventional ends of the experience. Any human activity is usually couched inside a bigger activity, and that within another bigger activity in turn. Life, in a sense, is like Russian dolls, and sometimes being innovative involves focusing on a different layer to your competition. Here’s an example of digital video cameras and how The Flip brand cameras stormed the market. Andy Budd’s user experience curve diagram gives us a neat way of visualising them…

drawing3small.png


In the diagram above you can see the experience curve for a traditional miniDV camera. It starts low (1) because of the faffing involved in taking out the battery, charging it separately, unwrapping the tape and and so on. Once it’s all ready to go, point and shoot (2) is pretty easy going, but when it comes to download & edit (3-6), things can get pretty annoying at times. Eventually, once you’ve completed the export process, you’re a happy bunny. Despite the negative points, you’ve ended up with some fairly high quality footage on your computer. So now lets look beyond the ends of the designed experience by extending the scope of the timeline before and after…




drawing4.png



drawing5.png



So what have we got here? Outside the scope of the designed experience, it’s a complete car crash. Firstly, you have to refer to the manual. You have to go out and buy some tapes. It’s tiresome and fiddly and you need a rainy afternoon alone with the camera to really get to know it. Then, at the other end, you’ve got the sharing issue. You’ve got your lovely, high resolution video file sitting on your computer but how do you get it to your friends? Up until recently, getting your footage onto YouTube wasn’t a joined-up experience. You had to know about settings and codecs and all kinds of techy stuff.

Then The Flip camera came along in 2007 and all that was history. They nailed the market with a cheaper, lower spec piece of technology - and they did it by designing beyond the conventional ends of the experience.

My VBUG’08 talk - following up on the developer Q & A session

November 6th, 2008 by Harry BrignullComments

I’ve just got back from giving a talk at VBUG 2008 in Reading. It was a very friendly crowd of developers who showed a lot of interest in “this user experience thing”, and I ended up doing a solid half hour of Q&A after my talk! I’ll put my slides up on here soonish, but until then, here’s a list of extended answers to some of the questions I was asked yesterday…



Q: “What design tips do you have for tricky situation X”
A: I often get asked this question, and my standard reply is “Start with research, then do some low fi prototyping, then iteratively research & design until you’ve ironed out all the pain points”. On hearing this, the person asking the question almost always looks disappointed - they tend to want some guidelines so they can skip the research phase. The important thing to remember is that even when you stumble upon some suitable looking design guidelines, you have to adopt them tentatively. As I said in my talk, always treat your expectations as hypotheses - you can’t be sure if your interpretation of design guidelines is going to work for your context of use & user-base. Bear in mind that guidelines can easily be misinterpreted, and the authors may not have considered your particular context. For example, if you consider the tip “Ensure your UI is consistent so it is predictable for users” - this seems like a sensible guideline - but you can get carried away and create “foolish consistency” where you’ve gone beyond the point of usefulness. The good news is, with a spot of UI prototyping and lightweight user research, you can quickly establish whether you are on the right lines or not.



Q: “As an independent developer, I often have to design UIs. I have minimal time and budget for user research. What can I do?”
A: Well if you have zero time, then there is zero you can do. So, the first thing you need to find time and resources, and that means approaching your client and educating them about the value of user research in improving UI design, and how good UI design has various beneficial effects such as improved conversion rates (e.g. on e-commerce sites), reduced learning curves and reduced requirements for technical support (e.g. if writing enterprise software). There are various success stories you can refer to - try Googling around User Experience / Usability / ROI / success stories and you should be able to find a case study that’s appropriate to show your client.

If you can claw together a few days of time, but no budget beyond your day rate, then you’ve got a choice - (i) take the hit and get some real users in for some face to face usability testing, or (ii) opt for some less costly though potentially less effective desk research. If your users are cheap and easy to access, then (i) is clearly the best option. There are lots of guides out there on how to plan and run your usability research, so I wont repeat them here (links below).

If you are going for the desk research option then I’d recommend carrying out a competitor evaluation. Here’s a rough outline of what to do:

First, pick a few user journeys that you would like to evaluate. A “user journey” is essentially a well trodden route through your application, involving one of its primary features. Then you should pick two or three top competitors - bearing in mind that they don’t have to be operating in exactly the same space. For example, if you are designing a UI that allows users to download and install a piece of software, then you could happily look at Skype.com, even if you aren’t doing VOIP. If you don’t know what sites to pick, ask people on a mailing list like uk usability or ixda, and I’m sure they’ll make some great suggestions.

Having picked your competitors, you should walk through one user journey, taking screen grabs as you go (don’t use printscreen - instead use an app like snagit or this firefox add-on that scrolls the entire page and grabs the whole lot). If you have the wall space, it’s very useful to tack these up on the walls and then cover them with post-it notes. Use one colour for “pitfalls to avoid” and another colour for “good practice”.

Having done all this, you should then come up with your own user journey, simply using paper and pens. Remember, your goal is to support user laziness, not developer laziness :-). This whole approach may seem ridiculously simplistic but believe me, it works.



Q: What are some good user experience resources?
A: If you are going to just read one book, I’d recommend Don’t make me think by Steve Krug. It’s clearly written and short enough for you to read in one sitting. If you want something more practical, then Luke Wroblewski’s Web Form Design is very good. If you read all of that and still want more, then just look at your Amazon recommendations. There are literally tons of UX books out there, and you need to find one that speaks to you. If you want just one site, then Jakob Nielsen’s useit.com is probably a good place to start. If you want more, there’s some more links here.

Diebold touchscreen Voting machine - not fit for purpose?

November 3rd, 2008 by Harry BrignullComments

If you’re like me, you may have read about the usability problems with the Diebold touchscreen voting machines in the States. Before I saw this video, I didn’t realise quite how serious the problems are. It’s not a question of a subtle usability issue or two - as the video demonstrates (at 1m 15s), even when the touchscreens have just been calibrated, they are innacurate, making it very easy to select the wrong candidate without realising.

It’s been argued that the problems stemmed from a lack of budget for usabity testing. This is nonsense - ‘expensive’ usability testing isn’t needed to uncover this problem. A simple QA process would have shown immediately that the device isn’t fit for purpose.

I can’t understand why didn’t they just use hard buttons rather than touchscreens. It would have been cheaper and would have avoided the need for calibration entirely… The mind boggles.

Multitouch with just a webcam. ‘Touchless’ - an open source project from Microsoft

November 2nd, 2008 by Harry BrignullComments

Touchless is an open source demo and SDK from Microsoft. It was released in October - and it looks so much fun!

How to get yourself a sweet .ly domain name

October 23rd, 2008 by Harry BrignullComments

After messing around with Domai.nr a couple of days ago (a really cute tool for coming up with domain hacks), I found out there are quite a lot of nice .ly domain names still available. It seems the reason is that they aren’t particularly cheap ( $149.50 US), and not many places sell them. I’ve just bought elegant.ly (on the off chance I might need it for a future project), and there are lots of other – arguably even better URLS – available. Like nice.ly. Or useful.ly. Or intuitive.ly…

Why not go have a look for yourself - head over to Libyan Spider. They also have a list of name suggestions here.

Mine took about 24 hours to sort out, and I had one technical support query was answered in a few hours. No problems, basically. I can’t imagine wanting to use a domain hack for a mainstream site, but if I had a neat little web app, it might be just the thing. Enjoy!

Are you doing your user research on the right people?

August 25th, 2008 by Harry BrignullComments

dilb4.gif

There’s a persistent myth about guerilla user research that it’s perfectly OK to grab just anyone to act as a proxy for your users. Perhaps it’s something to do with the whole low-cost, lo-fi ethos that makes this myth so easy to believe.

Actually if there’s one thing you shouldn’t cut corners on, it’s your recruitment. User testing should mean real end users, not Bob from accounts or some random dude walking down the street. Let me explain why this is so important with a case study.

Picture this: a large institution designs and builds a decision-making app for their customers. Their customers are sales-staff in small, partner companies whose job it is to resell the larger institution’s products to joe public, along with a commission. Now, during the early stages of design they thought they were doing all the right things. Wireframing, low fidelity prototyping, and usability testing - but here’s the crunch - they did their user research on their colleagues within the institution. They included middle management, data entry staff, the receptionists, and even some of the staff in the canteen. In other words, everyone but the sales staff in the partner companies who the product was really for.

And so they ended up with a product that was really usable - even a naive first-time user could use the system to punch in the data and get product recommendations out.

At this point, having spent about half a million dollars, they were sure they were onto a winner. So, they decided to get some real end-users in for face-to-face research sessions. The first few users were very polite since they had strong professional and political relationship with the institution making the product. But then one of the users, an admin assistant, commented that they would never use this system in her workplace. Her boss would do all of this work on paper and in his head. Then, he’d give her his calculations and she’d double check them in Excel. Apparently, his figures were almost always spot on.

Sure enough, when all the other users were asked about their current practices, they admitted that they also did all their decision-making in their heads. In fact 3/4 of them said they’d never use the app, because it would actually increase their workload. The owners of the product suddenly had a crushing realisation. The app was highly usable but simply not useful - it was solving a problem that didn’t exist. In other words, they were screwed.

And so ends today’s lesson. Always carry out research on real users, or you might end up like them.