Archive for the ‘UX Book Reviews’ Category
Selling Usability by John Rhodes Book Review
Last month, the UX Brighton Book Club read Selling Usability, a new book by John Rhodes that claims to reveal the secrets to infiltrating usability and UX practises into your workplace. Having not finished the book by the time of the meeting, I missed what the UX Brighton people thought of Selling Usability, however I’m sharing my own thoughts here. I’d be interested in hearing what the UXBrighton group thought of the book, so please comment!
Essentially the book is divided into 40 short chapters, each claiming to reveal another secret about how to sneak user experience practises into your company, and how to make your position relevant to how the business works. As you can imagine, this is an important contemporary issue as still today many large multinational companies do not employ dedicated usability and user experience specialists, and it’s easy to see that the company’s products suffer because of this. Think about the last time you got lost trying to use an online bank, or had to suffer through a terrible interface on a piece of software. These are the problems that usability specialists should be fixing for their employers, and so a book like this offers a way that usability specialists can get their services recognised.
My initial impressions were that this book could easily have been a series of blog posts, due to the short nature of each chapter, and the overlapping nature of some of the topics. A large section of the book is taken up with guides on how to deal with every level of the business, from sales people, through consultants, to CEO’s. Most of this advice can be condensed to a few key points – teach them about usability, and get them to talk about UX in their own terms, by bribing them with the promise of increasing profits. These chapters, despite having different audiences, all seem rather similar.
and if talking about money doesnt work...
Another main angle proposed by the book is changing the language you use, to one more in line with business needs. Call users ‘customers’, and translate your findings into money (i.e. ‘50% of users found this feature harder to use’ becomes ‘50% of customers couldn’t complete this form, losing us £2,000 in sales a week’). In short, hide the UX language and processes, and present results in a quantifiable manner to impress the company.
Selling Usability also advocated volunteering to do the jobs no-one wants to do, like taking notes, proofreading, or giving presentations, and give them a UX angle while writing them. The book then extends this idea to documenting finished projects, and giving them a UX focus in the write up, presenting them as case studies. Although undoubtedly an effective model to increase the reputation of usability within a company, this does seem a little.. Stalin-esque. It probably works though.
one upset user is a tragedy; one million is a statistic
The book seems most snappy and useful when it moves onto miscellaneous ‘tips’ – good ideas for getting UX out there. Things like including a UX quote in your email signature, using physical examples like DVD players or remotes to illustrate UX points, including quantifiable results on your CV, or writing a newsletter. These short ideas all add up, and pique interest in usability and user experience among otherwise uninterested colleagues.
Ultimately Selling Usability does do as it claims, and helps you sneak UX and usability ideas into a business, so that people start talking and thinking about it. The book’s 40 chapters do contain a lot of helpful information, even though it seems sometimes that the book has less than 40 points, leading to repetition. However the approach advocated fails to promote the idea that UX should be integrated into every stage of a project’s development, and so I wouldn’t recommend it as a complete guide to usability in business, simply as the first stepping stone if faced with an environment hostile to usability. It’s a good start, but without moving beyond the constraints in the book, your company will never experience the full benefits that proper user experience based development can give.
Game Usability: Advancing the Player Experience Book Review
I’ve recently finished reading Game Usability: Advancing the Player Experience, edited by Noah Schaffer and Katherine Isbister, which (as its title may suggest) tries to give a complete overview of the field of usability within computer games. Game usability is a relatively new topic, yet all the key figures of the field are included in the book, including contributions from Microsoft’s User Experience labs, Sauli Laitinen and the Super Mario Club and interviews with figures from many major companies. Game Usability recognises that this field is new, and aims to provide an introduction for complete novices to how usability is developing within computer games, and the shift from ‘hardcore’ games, towards a friendlier user experience.
The topics are widely spread, and try to cover every aspect of usability and UX within computer games, including an introduction to heuristics, how to perform an expert evaluation, and guides to many of the processes of user experience testing. Since the topic is relatively new, there is a wide range of material than can be drawn upon – maybe this book wouldn’t be so useful in ten years time, after a greater degree of precision is applied to each area of usability testing.
Where this book excels is when it covers the actual ‘how to’ of usability processes. If the reader had never performed an expert evaluation before, this book would give them a great introduction and allow them to get started. Similarly for running user tests, articles in the book tell you what to do (and what not to do), common problems encountered, and what results you should be looking for. This is supplemented well by concrete examples, such as Microsoft telling us how they use heat mapping to work out which areas of Halo are causing problems, and what actions they took to fix it.
now try to capture the flag
It also covers the difference between ‘casual’ and ‘power’ gamers, and how games should adapt to the shift towards casual games that can be seen through the success of the Wii. Unlike Alan Cooper (whose book Inmates says that the divide between casual and power users should not exist), this book recognises that ‘power-gamers’ have grown up developing a different skill set to casual gamers, and are more prepared to put up with issues like dying repeatedly, and a higher degree of challenge. By addressing the differences between gamers, and what their expectations are, this book would be a useful aid in the design of personae, and at targeting your game to an intended audience.
Some aspects of the books seemed a tad odd however: An interview with Georgios Yannakakis of Copenhagen University asks only three (very brief) questions (maybe Georgios wasn’t aware it was an interview). Another interview is with someone who shares Schaffer’s last name, and looks to be the author’s dad. Schaffer’s dad has been established in the field of usability, but has little to add with regards to games.
Perhaps the main issue not covered by the book is that all the contributors to the game are established in companies that accept the value of their work. The book briefly covers some counter arguments to common complaints about performing user testing (“It’s too expensive = It’s cheaper than shipping a rubbish product”, or “It takes too long = It’s integrated with the design process so doesn’t take much longer”). However it’s getting into a position where UX is a consideration at all within a company that will be a consideration for many (and is the subject of John Rhodes’ book Selling Usability ). Maybe future revisions of this book will include techniques for making usability a priority within your company.
The focus of the book is maybe sometimes too wide, and only lightly touches each subject before moving on. If you were already familiar with the topics covered in this book, there will be nothing new for you here.
These oversights are only minor though, compared to the large amount of ground the book covers as an introduction to usability. It offers more in terms of practical “how-to” guides than Alan Cooper’s Inmates, and its focus on Games means it can offer fairly comprehensive coverage of the main topics of the field. If you are new to the subject, or a non-usability specialist looking to understand the subject, or can only afford one book, Game Usability would be a great introduction to the theory and practice.
Also, to finish, my quick Usability fail discovery, from Sussex University.
Instead of letting the user break it, how about… not offering the ability to make mistakes (See: Macs)
The Humane Interface by Jef Raskin
Along with Alan Cooper’s book, when starting studying Human Computer Interaction, we were recommended to read Jef Raskin’s The Humane Interface. Having recently finished The Humane Interface, written by a designer of the original Mac (credited with the design of the one button mouse), I will briefly summarise its topics, and give my impressions.
My immediate thoughts are to compare this to Alan Cooper’s the inmates are running the asylum. This book is a harder read than Cooper’s – often going deep into highly technical topics (like how he would like to notate mouse clicks), and lacking the wit or lightness of Inmates. The most readable parts of Raskin’s books are the anecdotes about the development of the Mac and Canon Cat, and these are too few. However, this is likely due to a change in the intended audience, as Cooper’s book intends to sell usability concepts to a business audience, whereas Raskin aims his book directly at computing professionals.
Another key difference between Cooper and Raskin is they favour different methods of investigating the quality of an interface design. Whereas Cooper’s book favours qualitative data and methodology, through the establishment of persona’s and attempting to get inside user’s heads, Raskin favours quantitative methods. He includes a chapter on GOMS, a method of assigning arbitrary times for actions such as typing a keystroke, moving a mouse, thinking and moving from the mouse to the keyboard. Then by adding up the times it takes to do these actions, you can compare interaction methods by the time taken. (Its important to note that these times will not relate to the real world, as user’s act at different speeds, and can only be used to compare against other GOMS scores.)
My initial impression of this form of quantitative research is that it would highlight the speed/efficiency of an interaction, but not the quality – which is not necessarily the same thing. If a task takes a few seconds more, but is considered a lot more fulfilling, GOMS wouldn’t record this. This is particularly relevant to the field of videogames, where a purely GOMS based method to check interaction quality would lead to games such as this below:
Maybe the computer could press the button for you?
GOMS can be a useful tool to help compare interaction times, but should not be used exclusively.
Raskin also documents a number of problems with current interaction, with a particular dislike for modes (i.e. interactions that do different things in different concepts). A simple way to explain modes is the ‘caps lock’ key; turning on this mode will make ‘TEXT LIKE THIS’, despite my keystrokes being the same as when making ‘text like this’. He advocates an elimination of modes, as they introduce cognitive dissonance, and make it harder to form habits. A useful compromise, Raskin say’s is quasimodes, which is a mode that requires a constant input to achieve (and hence can be part of habit formation). This would include holding the shift key to produce capitals.
The elimination of modes extends into the elimination of applications – typing ‘SUM 7 + 6’ should produce ‘13’ everywhere, not just in a calculator. This improves the quality of interaction by allowing the user to be clear that the methods they have learnt will work anywhere. I believe this trend can be seen in current operating systems (such as the amalgamation of windows explorer and IE), and this is one of Google’s main aims with their OS.
Raskin also advocates an unlimited undo feature (even through closing and re-opening documents), and the elimination of dialog boxes asking ‘are you sure?’ These two are linked, giving that level of undo freedom would make ‘are you sure’ unnecessary, and is more technically feasible now than when the book was written. I assume it’s a matter of conventions, and momentum which would hinder people advocating these new interaction methods, and it is this mindset Raskin is trying to overturn.
An even more radical suggestion is Raskin’s radical redesign to information architecture. Looking at the hierarchical, folder methodology we have of storing files currently, Raskin notes that it is inefficient – from any point, you cannot see what’s in the folders below, or in the level above you. Since the book was published in 2000 we can see efforts have been made to combat these criticisms – in Windows, folder icons now show the file types inside (and previews if they are pictures), and have made it easier to go up a level. On Macs, they have additional folder view types that make it possible to see ‘up’ the hierarchy.
Raskin however has a more radical suggestion, which he calls ‘Zoom World’. Imagine, flying over a world with a series of zones, ‘I.e. pictures, home, work’. Then you zoom in on pictures (while still being able to see the others), and note that closer up we can see the pictures has it own sub zones, entitled ‘pictures of France’, ‘pictures of the dog’, ‘pictures of lily’ etc. Zooming in on ‘pictures of the dog’, now we are close we can see some individual pictures, one of the dog smiling, one of it playing with a ball
One of the dog playing counterstrike
Zooming in further on this picture would let us read and alter it, but we always have the option to quickly and freely zoom out and see any area of ZoomWorld. The advantage of this system is it solves the issues with being able to see the files above and below at any point, and not be restricted to your current folder. It has been implemented in ‘Archy’, which includes many features Raskin advocates in this book.
Ultimately its interesting seeing how many of the ideas Raskin advocates are ahead of their time, and were included in later revisions of Macs, and in general interaction. (such as searching starting from the first character you type, rather than waiting for you to press ‘enter’). As a book though, it’s harder to get through than Inmates, and does go on in exceptional depth about less than inspiring topics. Raskin talks endlessly about the Canon Cat, a system from the eighties with which he had tried to implement many of his interface ideas. He notes however that it met resistance from users who were used to the existing human computer interaction paradigm, and was not commercially successful. Perhaps, with the moves made by the leading Operating Systems, and Google OS breaking down the barriers between an OS and a browser, people would now be more susceptible to higher quality interaction with computers, and are prepared to unlearn their bad habits.
Alan Cooper’s The Inmates are Running the Asylum
Alan Cooper brings together his breadth of experience with interaction design, as demonstrated through his works with Visual Basic, and consulting with many prominent clients in order to explain the need for, and the role of interaction designers. Having recently finished the book, and found it very educational, I’ll draw out, and discuss some of the book’s main points.
Primarily Cooper is definite about the job title being ‘interaction designer’, rather than ‘interface designer’. The connotations are important here – an interface designer would be someone who just designs the part of the customer-facing part of the code. Cooper notes that this is just applying plasters to a broken system – instead we need to start considering interaction from a holistic viewpoint, and build systems that take user experience into consideration from the start.
To achieve this, we can no longer put design in the hands of programmers – as is currently often done, due to historical legacy. Although they know the code inside out, there are many reasons why they should not design it:
- Programmers typically think about implementing a list of ‘features’, and this is not an appropriate manner to design software if we want to end up with a positive user experience
- Programmers have a vested interest in either reusing existing code, or implementing code that they know how to do.
- The programmers ability to design will be blinkered by their past experience of programming and using computers, and this makes it hard to see novel ways of achieving things
- Programmers will often assume that user’s are as adept with computers as they are, or diagnose user issues as lack of training. Instead it should be the system’s job to accommodate users.
Instead we should implement a goal based design process, based on personas. Personas (personae?) involve distilling a large amount of user research (interviews, etc) into a small number of generic ‘people’. These people will be given names, back stories, maybe little pictures, and will sum up the experience of their demographic using the software. For example, if you were designing software for an image manipulation program, you might (after an extensive amount of research) define two key personas, “John” the web designer, who uses the program to create a large number of graphics and logos for his sites, and “Jill”, the casual home user, who uses the program’s wizard to improve the quality of her digital pictures. Creating personas will allow you to identify the goals of each user, the pitfalls they may encounter, and allow you to focus on necessary features/aspects of the program. By being able to realistically identify with the end users, it is possible to design software for them, rather than a generic ‘user’ who is a mis-mash of various ideas and people and would lead to software that is too generic and unfocused.
Another key point drawn out from Cooper’s book is the importance of goal based design. Typically software design is done by making a list of features. For example you may approach the programmers and say “it must be blue”, “it must allow the user to resize photos”, “it must allow the user to reduce red eye effect on photos”. These features would then be added, and ticked off. Features that didn’t make the cut, for whatever reason, would not be implemented. Goal based design is an important development of this. Instead of adding a list of feature, you must use your persona’s, and think about the tasks they might want to do. There is a distinction between the ‘task’ they must do to achieve it, and the ‘goal’. For example, with resizing photos, the task would typically be ‘click on ‘resize photo’ and insert a new height and width’. This is not the user’s goal. The user’s goal is to have a resized photo. Focusing on this as a goal, rather than a task or a feature allows us to think about the optimum way to achieve this. What would the user want to do to resize their photo? By approaching it from a goal perspective, we can see how the user may want to adjust the image by dragging a corner of it, that they’d typically want it to stay in proportion, that they’d like to preview the change before it occurs… lots of things that may optimize their user experience.
The part of the book that I felt is particularly useful in explaining interaction design is Cooper’s metaphor with shooting a film. In a typical software design scenario user experience testing would only be thought of in the ‘edit’ stage, after the shooting (programming) had been done. This is obviously not how it is done in films, for the shooting is the most expensive part of the process. To minimize this expense, and to ensure fewer changes need to be made, films have scripts and storyboards to guide the shoot. This is what our job, as interaction designers, should be within the field of software design.
Implementing a complete design approach, thinking about the user experience from the beginning makes sense at every level. Despite concerns about the loss of time (and the expense of having programmers idling) the outcome will be a better designed product that will receive a warmer reception from users. It will give managers and marketers a larger degree of control over the final product, and give programmer’s a map to progress with, allowing everyone involved to know when the product is complete. The time loss (and potential loss of being ‘first to market’) is more than made up with by quality, as can be seen by the difference between Apple’s Newton and the PalmPilot. Ultimately it can mean the difference between a successful product, and an expensive failure.
