Early chapters in the book try to define what the field of user experience is, and what it means in relation to games. There is a degree of confliction here, with each chapter giving a slightly different interpretation, but they often settle on themes such as immersion, fun, presence, involvement, engagement, flow and playability.

Also wind, fire and heart!

The book gets more exciting when it presents a range of methods for evaluating user experience in games, with a variety of models appropriate for various stages of game development, from prototyping to post-production. This encompasses many custom models for different situations, such as a model for inexperienced gamers, or one for fitness games.  The book also presents studies of the usability of game controllers, and the development of heuristics, which is particularly interesting in the last chapter which aims to collate and amalgamate previously created gaming heuristic.

All this content is interesting; however, a liberal spreading of maths means it often comes across as extremely academic (particularly in comparison to Isbister’s book). This can largely be accounted to the background of the various authors, largely coming from academic institutions, compared to the real world perspective of Game Usability.

Where the book excels is the divergence from this academic interpretation, notably in the papers by Vertical Slice and Emily Brown. Vertical Slice cover the current state of user experience evaluation across three Brighton game companies, and give an insight into the methods used through case studies, from the expert evaluation found in the earliest stages of production, through to the user testing close to the end of a project.

Brown gives a comprehensive overview of the range of tools currently in use, and shows optimism for the future, since she recognises only a “lack of knowledge” as a hindrance to the extension of user testing into gaming, rather than opposition to the methods. This conclusion is reinforced by the case studies by McCallister and White, who show game developers are looking to extend their application of user experience testing in the future.

Which will be the same as today, but with more robots

Unlike Remote Research or Game Usability, this book is not a practical how-to guide. Instead it presents the state of user experience in games, and where the cutting edge of research is. Personally I have found it very useful for developing my own research.  However the book would be unlikely to be a ‘one stop shop’ for a developer looking to start user experience research at their company.

It will be useful to see how the wide range of interesting ideas found within this book can be integrated into practical solutions for companies to use when producing games. This move from the theoretical to the practical will greatly assist the field of user experience in games, and will truly see the ‘coming of age’ of video game usability.

Related posts:

1. Game Usability: Advancing the Player Experience Book Review
2. Remote Research – Book Review
3. A Theory of Fun for Game Design by Ralph Koster – Book Review

Don't judge it by it's cover...

Why would you consider remote research?

Written by advocates of remote research, the book highlights many of the potential advantages that remote research gives compared to a more traditional lab based study. These advantages are fleshed out throughout the book through testimonies of experts who have experience in this field, who offer real world examples to emphasise these points.

Some key advantages are:

• Access to a geographically diverse user base. Unlike traditional research, where a moderator would have to be in the same physical location as the subjects, remote research allows a study to be run with anyone who has a high speed internet connection, widely expanding the potential study-group.
• Easy to let stakeholders get involved. Because the research session is being broadcast over the internet, it’s possible to allow stakeholders (i.e. executives and designers) to view the session, and give (moderated) input. This of course increases their engagement with the process, and will be the ‘evidence’ for any conclusions derived from the research.
• Natural browsing environment. The validity of the research can be improved, not only because you are allowing the user to perform the task in a familiar environment (their own home computer), but also some recruitment methods allow you to capture a user performing a task they have selected. For example, recruiting a user who came to the site to buy trousers, for a task based on buying trousers, would provide more accurate results than asking someone to pretend to buy trousers…
• Cheaper (debatably). Not having to pay for travel can keep costs down, however other costs, such as incentives, will still be required, as well as paying for the software.

The remote research book doesn’t advocate killing off lab tests though – instead, it recognises that there are cases when the lab is still appropriate, such as when privacy is a concern. The book also features Andy Budd’s defence of the lab, which argues that remote research fails to pick up aspects of non-verbal behaviour, as well as arguing that remote research doesn’t just remove a selection bias (geography), since it also adds another (internet speed and technical ability). It’s brave of the book to include the case against remote research, and helps project a more trustworthy and reliable image for the book itself.

How to do remote research

The ‘meat’ of the book are the sections dedicated to how-to guides on the different forms of remote research. The book contains step by step instructions on performing moderated or un-moderated research, and includes key topics such as recruitment (and live recruiting), card sorts, and lots of handy hints – such as using IM clients as a chat room for multiple observers to automatically share and timestamp notes.

The book doesn’t just cover basic topics – it goes on to develop novel approaches to user research, such as using ‘reverse screen sharing’ to protect confidential software or data, and using mobile web to gain a new understanding of time-dependant information, outside of the traditional moderated setting.

It also extends the remits of remote research – it doesn’t have to just be websites, but can include doodles or sketches, as well as developing ideas for automatic research with analytics.

Another sort of remote research?

Conclusion

Remote Research is one of the easiest to read UX books I’ve reviewed. Like many Rosenfeld publications, it is laid out well, without appearing dense with text, and has a friendly tone throughout. The book can be likened to Krug’s writing in its style, and presentation.

The book is also practical and realistic, and deals with real world issues, like ‘fakers’ (who can be outed by using open ended questions to discover motives), legal issues, and common challenges such as reluctant stakeholders.

Most importantly for the practical UX practitioner, the book is not dogmatic. This is especially evident in the last chapter which admits that usability shouldn’t be the exclusive goal of product design, and needs to be coupled with initiative, and innovation to develop great things.

Overall this book is a great introduction, and how-to guide to the growing field of remote research, and will be an important tool for anyone trying to keep up to date with the latest research methods.

Related posts:

1. Rocket Surgery Made Easy by Steve Krug – Book Review
2. Evaluating User Experience in Games – Book Review
3. Selling Usability by John Rhodes Book Review

Effective UI (the book this time) is not a self-start guide, or a definitive how-to, unlike Krug’s new book. Although it does give an introduction to UX tools, such as paper prototyping and user interviews, it doesn’t go into the depth that other books may do. Instead, the book seems to be aimed at a single person within an established company, who needs a one-stop resource to bring them up to speed on what User Experience is, and what it can do for their company.

Hence the book features a little bit of everything. Not only does it introduce the key concepts of UX, but it also has chapters on prototyping methods, how to understand and define key users (including how-to exercises), how to bring together a good UX team, and how to sell UX at your company (although it has less emphasis on subterfuge and guerrilla tactics than John Rhodes’ Selling Usability)

Pictured: John Rhodes at work

It’s in these high level overviews of crucial UX subjects that the book excels. EffectiveUI (the company) have been using these methods with clients for years, and have built up excellent ways of explaining the key concepts to clients. Through use of extended metaphors, referring to the process as a war, or akin to building a bridge, the book shares some of the best practices they’ve developed in this period. Some notable insights the book offers include de-emphasising the importance of written functional specs (which are incomplete, ill-informed, and slow to produce and react to change), and insight into appropriate methodologies, favouring an agile (with no capital letter) approach but also stressing the importance of not getting hung up on a formal adherence to a methodology.

The years of experience that the authors have had also give the book a wide range of real-world examples to draw upon, such as the production of year book software, which are used to illustrate and emphasise points. It’s definitely a credit to the book that the examples are relevant, and realistic, and help explain the key concepts being demonstrated, and how user centred testing improved the final product.

There are however a few odd choices, which may detract from the book’s ability to succeed in the marketplace. Most prominent is the name EffectiveUI (the book, not the company). I can understand why, as promotion for their company, the authors have chosen to name their book after their company. However it doesn’t seem very appropriate for the subject matter. Having not encountered the US-based company before, I had no prior knowledge of their work. Hence, the title has no associations to me. And it says “Effective UI”. Wouldn’t the reader assume the book is about producing an effective User Interface? Which isn’t the same thing as User Experience. Having looked for references to UI, it doesn’t appear in the index of this book at all (since it is a completely different subject in itself). I can see how this can lose potential customers – people looking for a book on UX are likely to miss this one, and people who buy this book looking for insights on UI will be disappointed.

UI. Not UX.

It’s also important to understand what this book is. It won’t give you step by step instructions on how to investigate UX. What it will do is introduce a non-UX specialist to the key concepts of UX, and give the reader an understanding of the benefits of UX . So don’t buy the book assuming that it’s a one-stop guide on becoming a UX practitioner (Each of the topics it covers could probably fill a book by themselves with how-to instructions!)

However, if you are new to the subject, and want a high-level introduction to key UX concepts, this is the book for you. Or if you are a manager, have heard about the emerging field of UX, and wonder what it can do for your business, this book will tell you everything you need to know. It won’t tell you any trade secrets, but it might just convince you to hire them!

Related posts:

1. Rocket Surgery Made Easy by Steve Krug – Book Review
2. Game Usability: Advancing the Player Experience Book Review
3. Selling Usability by John Rhodes Book Review

Krug’s previous book, Don’t Make Me Think, aimed to introduce the idea of web usability to a general audience, and had a number of key characteristics. It was short, designed to be read during a plane journey, and it was accessible, so that anyone could read it and understand usability. It also had a chapter on performing usability testing, which was removed in the second edition. Rocket Surgery Made Easy is that chapter.

In the decade since the emergence of this first book, Krug has been honing his usability testing skills, and through running numerous workshops, has perfected how to teach usability testing. This book is the summary of that experience, and in a wonderfully brief and readable style, is the only book someone new to user experience will need to start performing usability testing. Looking at that statement in more detail will give a deeper insight into the book.

Pictured: Steve Krug, international man of mystery

“The only book”

Krug’s book is a complete introduction to testing your company’s website, and guides the reader through every step of the process, from recruitment, and pre-test setup (including the equipment required), through to running the session and the debrief. The book also offers all the test-scripts and task cards you’ll need. Throughout the process Krug offers his best practise techniques, useful maxims to remember, and pitfalls to avoid. Essentially, you could start performing usability tests with this book alone as a reference.

“someone new to user experience”

This book aims to be an introduction, and so requires no prior knowledge (although reading his other book wouldn’t be a bad start). It also assumes that you are not a usability professional, just an interested party at a company, and that there isn’t a large degree of company buy-in, and believes that many rounds of semi-amateur testing is superior to one round of professional testing, which is valid. Because it assumes you don’t have a large amount of support from your company, in particular monetarily, it focuses on how to perform usability testing with a large degree of constraints – how to do it cheaply, how to do it quickly (just one morning a month) & how to get people interested through pastry!

“will need to start”

Because of its small size, Krug’s book is only designed as an introduction to usability testing, and won’t contain any new information if you’ve done this before. At best you could pick up a few best practises, but you’re not the intended audience. Just for you, the book has suggestions for further reading “for overachievers only”, with some interesting books to continue studying this field, but the book is largely aimed at newcomers to the field.

“performing usability testing”

Also due to its brevity, the book only covers one on one think aloud tests with websites, and only hints that other forms of usability testing possible. The book ends with a short chapter on remote research, but only hints at the possibilities that we saw at the UX Brighton event. Other types of usability research, such as quantitative methods, expert analysis, or focus groups, are left out entirely of the books remit. Although the book offers a complete solution, it’s a complete solution for one particular type of usability testing, and only covers websites (although the skills could easily be applied elsewhere).

Its not rocket scien.... oh.

Conclusion

Krug’s new book is short, and simple. However neither of these points are negative. It’s short because it has to be, to introduce a wide audience to usability testing, and to emphasise how easy it is to begin. It’s simple, because usability testing can be simple, and done for just a morning a month. If you’re someone who has been doing usability testing for years, or a professional who does a large amount of usability testing, perhaps it’s better to look elsewhere. However if you’re looking for an introduction to usability testing, having never donae it before, or just need a short walkthrough guide to getting usability testing started at your workplace, Krug’s book should definitely be your first choice.

Related posts:

1. Effective UI by the EffectiveUI team – Book Review
2. Remote Research – Book Review
3. Game Usability: Advancing the Player Experience Book Review

The most obvious thing that strikes you about Koster’s book is the tone, and the format – despite it being said that you shouldn’t judge a book by its cover, the cover of this book, a notepad covered in doodles, is a preview of the format of the book. The book is written in a personal, conversational tone, and every page of text has a corresponding picture page, with a hand drawn doodle, serving to summarise the text next to it. It’s immediately clear this is not an academic book, and this makes it all the more useful to people trying to understand fun in video games.

Reflecting the light tone, and doodled illustrations is the books approach to the subject. Koster is not interested in an academic definition of fun, instead he wants to know why it exists, why games can be fun (or dull), and how we can improve a player’s experience of fun with the game.

These guys are having so much fun, they don't even have to plug the controllers in!

To understand fun, A Theory of Fun for Game Design starts with cognition theory, explaining how the brain works, and what it enjoys. These chapters essentially condense down to an understanding that the brain enjoys challenge, and learning how to overcome these challenges (‘grokking’). Successful games give sufficient opportunity to learn, and then challenges the player by offering variations of application for the learnt skill. For an example of this, consider jumping in Mario – the player learns to jump over a hole, then many holes, then holes that spit lava, then holes where the landing space is moving, then holes where the landing area disappears, then all of the above together! By challenging the player to stretch their application of the new skill they’ve learnt, the game continues to be fun.

Games are an important medium, as they can offer this opportunity to challenge in a direct manner, which other mediums can only abstractly offer. Hence, games can be used to teach life skills – how to aim, how to gamble, how to win. Koster offers an explanation to why these are common goals in games due a cultural background of power and hierarchy – human’s have evolved needing to fight, and win, and games offer a way to learn and challenge these skills (as do sports).

So why are some games boring? Koster tells us that games fail to be fun either when we’ve learnt everything they have to teach, or we feel we are not learning anything from the game. Games that are too hard are ‘boring’, as the learning is above our ability. Games where all the main elements are learnt early on, without variation through the later levels, get boring early, as we’ve learnt everything. This can be seen in Assassin’s Creed, where reviews often commented on it being repetitive – you’ve seen everything there is to see in the first hour. As people interested in user experience, we can see the value here for longer play test sessions with real players, to uncover the long term appeal of games.

Pictured: Not Fun.

The latter half of the book considers the question of whether games are art, and what they need to achieve to become art. Currently the book identifies games as offering only a choice between ‘fun’ and ‘boredom’. When they move beyond this medium, and become open to interpretation, and a way to teach us about ourselves, they will become art. Perhaps we can see the beginning of this development in great introspective games, like Deus Ex, Half Life 2, or Lego Rock Band.

Ultimately, for user experience practitioners, this book will not change how you do your job. It won’t give you set rules on how to make a game more fun, or on what to do to discover whether something is fun. However it will give you a deeper understanding of why some games are fun, why some games are boring, and give an ethos for improving the player experience. And it might just change how you think.

Related posts:

1. Game Usability: Advancing the Player Experience Book Review
2. Evaluating User Experience in Games – Book Review
3. Remote Research – Book Review

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.

Related posts:

1. Effective UI by the EffectiveUI team – Book Review
2. Game Usability: Advancing the Player Experience Book Review
3. Rocket Surgery Made Easy by Steve Krug – Book Review

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)

Related posts:

1. A Theory of Fun for Game Design by Ralph Koster – Book Review
2. Evaluating User Experience in Games – Book Review
3. Rocket Surgery Made Easy by Steve Krug – Book Review

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.

Related posts:

1. Alan Cooper’s The Inmates are Running the Asylum
2. Evaluating existing technologies, paper prototypes in action, Windows 7 and the disappointing user experience of my DVD player!

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.

Related posts:

1. The Humane Interface by Jef Raskin