Posts Tagged ‘inmates running the asylum’
iPad Usability Study
Just a short update this week, sharing some thoughts on the recent Nielsen-Norman report on usability for the iPad. The recently published study was based research from a combination of both expert evaluation and user-testing, and aimed to discover how people interact with the iPad, and what issues typical users would encounter that prevent them from achieving their goals.
An iPad Nano
Jakob Nielsen admits that the study is not as thorough as a typical usability study. However has decided to share it anyway, due to the over-inflated impact that usability studies produced early in a devices’ lifecycle have been seen to have. As an aside, this is an interesting contrary viewpoint to the disadvantages of being first-to-market noted in ‘Inmates’, which argues that being first to market is irrelevant compared to being ‘best’.
The report has some interesting key findings, including that the apps seen on the iPad and the iPhone suffer from the re-emergence of a problem not seen since the early 90’s. Unlike web browsers and desktop software, which has established graphical conventions to highlight buttons and GUI elements, iPhone and iPad software has not implemented standard conventions, such as making a clickable button appear 3D. Hence there is no consistent manner of designating important aspects of the UI, and users just didn’t know what they could click on. Nielsen likens this to the first emergence of graphical interfaces of the early 90s, when anything and everything could be a button.
Its therefore clear that the main recommendation of the study is to standardize common elements, like navigation, among first and third party applications, such as “swipe to turn page”, or “press and hold to delete”. This also links with the studies’ findings that users were unsure what reaction their action would cause, as the apps have yet to find a consistent manner in which to work.
Not just a big iPhone
The study highlights how the iPad is not just a big iPhone, and different usability issues emerged on the larger device – most pertinent is that navigation elements on the bottom of the page, as seen in many iPhone applications, will not work on the iPad. The larger screen means that these elements are too far from the user’s field of vision to be noticed – and hence are not appropriate. What this means for people who make apps is that a custom iPad version is needed, not just relying on the ‘universal’ up scaling of iPhone apps.
The full report is linked below, and worth a look if you’re interested in the usability, the iPad, or designing an application!
Read the full report, here.
Telling Tales – Stories for promoting user experience.
Stories have long been an important way of recording and imparting information, as evident through the survival of folklore, myths and songs from our past. As a tool for communicating, and retaining information, they are highly valuable, and the principles of this can be applied to the promotion of User Experience.
Why do teams need to understand UX?
When working within a team, whether it’s a small web development company, or a large multi-national company, it’s impossible for one person to oversee every aspect of development. That is why it’s important for everyone to understand the principles of user experience, due to the large variety, and span of tasks that it encompasses. A good user experience designer is not the one who works longer hours, or has more creative control over the final product, instead they are the one who makes sure everyone understands UX goals, and works towards them.
It is this reason that books such as Krug’s Rocket Surgery Made Easy heavily promote the idea of getting everyone, from the CEO to a junior developer, involved when testing with real user’s, as it is these people who will be able to implement user experience ‘fixes’. The solution Krug suggests involves inviting these people to view the user testing sessions, and bribing them with snacks.
Because encouraging successful user experiences requires everyone’s involvement, it’s important that everyone understands the goals of user experience, and can incorporate them into their work. The problem is making them understand what those goals are.
Pictured: not a goal
What are stories good for?
Homer’s Odyssey was composed in the 8th century BC, and yet a canonical written version wasn’t produced for another 300 years. Before this, the tale was remembered, and shared orally, through song. Considering that the Odyssey contains over 12,000 lines, this is no small feat. That’d be like remembering, and reciting on demand, every blog post I’ve done so far… So how was it possible?
The answer lies in the power of stories. Stories, like Homer’s Odyssey, are memorable, due to the plot and the events contained within, and hence easily form visual images within the mind, and aid memory. Plots make stories interesting, and hence easier to remember than non-fictional texts (such as remembering all of my blog posts).
Stories can also be used to impart useful information. These be obvious life lessons (The Three Little Pigs teaching the benefit of putting adequate effort into your tasks), or life saving, such as Ring a Ring o’ Roses imparting symptoms of the Black Death (although this may not be true)
or Cinderella teaching us the dangers of stepmothers
Using stories for UX
So, stories are memorable, can be used to impart useful information, and are easily transferred, as made evident by the 300 years that Homer’s Odyssey lasted without being written down. Hence they seem ideal for the promotion of UX within teams, as they can be used to quickly impart the benefits of UX, and what each individual needs to do to aid a user centred design process, in a memorable and transferable fashion. By bringing the whole team onboard with the principles and goals of UX, a greater degree of coherence can be achieved across the team. Therefore to get better results without manually verifying everything the team does, a User Experience Designer needs to champion user experience principles with all members of the team, and stories are an easy way to do this.
Some examples of UX stories
Many authors have understood how stories help to impart information in a memorable fashion.
- In The Design of Every Day Things, Don Norman uses stories of real world examples to emphasise the dangers of ignoring user centred design, with examples including nuclear accidents and plane crashes.
- Stories based on metaphors are also used by Alan Cooper in The Inmates Are Running the Asylum to emphasise the importance of designing for the end user, by comparing the software design process to film making.
Also of interest, Sam Nixon shared a short story by David Travis called “The Fable of User Centered Design”, which aims to bring clients and team members on board with the benefits of a user centred design approach. Definitely worth the read, and should be shared. The book is available to download from his website.
If anyone has other examples of stories that help define the importance of user experience, remember to leave a comment below!
How real-world game usability testing is changing
Recently I visited a global game publishers’ usability lab in London to help out for a day, and participated running UX tests on the current revision of an upcoming game. The experience was extremely educational, and enjoyable, and changed my perception of integrating usability within an established company. Unlike the academic settings in which I have previously been working on usability, this companies position as a global entertainments company demands that the needs of the business is taken into consideration as well, and this has an affect on how usability is tested. The role of usability and user experience in game design is changing, and this could be clearly seen.
What’s testing usability of games like in the real world?
Compared to an academic approach, as we have been working towards in our course based at Vertical Slice’s labs, there are a few differences to how large companies typically evaluate the user experience of a game.
- Companies will often consider usability testing a ‘stage’ near the end of the game design process
- A business will tend to have a wider focus when it comes to analysing player data (taking a ‘breadth’ look at the data, rather than the ‘depth’).
- This translates to a testing the game with multiple players at the same time, and observing their play session live looking for problems.
- When a problem is found, a business will focus on how to fix the problem, not why the problem exists
- The business wants results. Now!
NOW!
Why does this difference in testing game usability exist?
To understand the reasons for these differences, you have to understand the demands that the ‘business’ places on their usability specialists. In short, they want to fix the maximum amount of problems, and fast. Working in video games often means tight time frames, and the demand for instant feedback and results. This of course comes down to money – time that programmers are left idle is a wasted expense, and also there is a large degree of pressure to ship the game on schedule, and not lose momentum built up by marketing to competitors. The ‘waterfall’ methodology used by many businesses divide the design process into stages, and usability testing will appear as one of the later stages.
Alan Cooper, in The inmates are running the asylum, argues that these demands are based on false premises, and looks to the failed early 90’s attempts to design popular PDA’s as an example of why being ‘first to market’, at the expense of a more user friendly product, is not always the most successful game plan. But, nonetheless, these are the demands put on real world usability labs.
wait, when did we want the results again?
What effect does this have on the results?
This ‘wide angle’ mass testing approach imposed on labs has several advantages which are of interest to businesses.
- Major issues, such as problems that most people will encounter, can be seen easily as you will have a room full of people complaining about it.
- Simultaneous testing means you get the opinions of a large data-set quickly
- It is cheaper to the business than a deeper integration of usability into every step of the process.
- Any sort of usability testing has to be applauded, as it’s been shown to generate a better product, improve customer relations and cause a post-launch reduction in troubleshooting and maintenance costs
But, equally the approach forced by the demands of a business has several disadvantages:
- A ‘lets just fix it’ approach means that you won’t learn about the causes of problems found, and can lead to the same problem being created in the next project.
- A business with the attitude of ‘sending it for usability testing’ near the end of the development life cycle limits the amount of changes that can feasibly be made to a game or product.
- ‘Finer grained’ problems, that the player may not be aware of, but that would show up on an close analysis of their play session, will likely be missed.
How should it be done?
This companies’ usability lab is an expert in the field, and so conduct a range of usability tests at different stages in the development process. And this is the correct approach, meeting business demands for fast, cheap results, by changing the nature of usability testing.
Rather than simply being a ‘stage’ of the process, as you will often see in typical ‘waterfall’ project management methodologies, usability and testing the user experience should be ingrained in every aspect of game design, even before the first line of code is written. By doing smaller scale testing, but more frequently throughout game design, we can overcome the disadvantages that the traditional method imposes upon us.
- Time becomes less of an issue, as it runs concurrently to programming and game design
- More problems will be found, but at a more manageable pace
- This means that each problem found can be focused on in more depth, leading to a deeper understanding of their root causes
- Problems will be found with enough time to fix them
- Larger problems will be found, and fixed earlier, reducing bug fixing time.
My impressions from working with this global game publisher and distributor was that this is the direction they are heading, and as market leaders, I imagine that it’s a direction that most companies involved in game design will soon be following.
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.
