Archive for the ‘HCI’ Category
Applying Games UX lessons makes dull tasks fun!
I recently watched Sebastian Deterding’s presentation ‘Just Add Points?’. It covers applying lessons learnt from games to software, to make software more enjoyable to use. The talk then goes on to cover where this model traditionally falls down, before rebuilding a model with new rules. The presentation was engaging, very well designed and a good extension of the principles within Ralph Koster’s book, applying its lessons to the real world, and therefore well worth a look.
The presentation first covers ways in which the UX lessons learnt from games have, or can, be applied to dull tasks to incentivise people to do them. Some examples of this can be found on Volkswagen’s thefuntheory.com website, such as turning a staircase into a piano to encourage people to take the stairs, or turning a bottle bank into a game to encourage people to recycle.
all the encouragement I need...
Deterding does provide some critical analysis of this model – what happens on day 2, for example? Is it still fun to recycle? I also question the justification provided by Volkswagen that the bottle bank performed better than a standard one. Although it did in the example, when the user was provided with a choice between two geographically-close bottle banks, this fails to be a conclusive proof of the fun bottle bank being more effective at encouraging recycling. (would the ‘dull’ one receive an equal amount of recycling to the fun one if there was no alternative – what about over a number of months?)
The typical theory of fun is that ‘adding points’ will magically make dull activities fun, because of It adds competition, re-playability, and a new ‘meta-game’ to the activity taking place. However, Deterding’s presentation challenges this, and says that ‘just adding points’ is a too simplistic understanding of the application of fun to menial tasks. Instead, games present an optimized version of many positive psychological features of real life, and through the recognition of this, real life can be optimised.
As I discussed in my review of Ralph Koster’s book, ‘fun’ is the act of learning and successfully applying, and adapting the knowledge learnt, and typically games present an adaption of this. Games optimise ‘fun’ because:
- They allow the construction of clear, realistic goals, with measurable progress
- The goals are presented in a manageable manner, with a clear ‘call to action’, indicating what is to be done, and when it has been achieved
- The player’s current status is clear, and their progress towards the end goal is indicated
- New tasks are built upon knowledge already gained
- Social comparison can be made with your friends to compare progress
So the obvious way of making dull tasks fun would presumably be to integrate these principles from games? However this conflicts with software, and menial tasks, core goals of efficiency. As I’ve noted before, ‘press a button to win’ is effective, but not fun.
Unlike games, software (and menial tasks) doesn’t give designers full control over the environment – instead the user defines the goal (such as ‘write a letter to the TV Licensing people’). This makes direct application of the features from games difficult.
We have taken re _ _ _ sses_ _ _ of your _ a _ s _ _ r
Instead, Deterding presents us with a list of ‘patterns, models and words for emotion and rule design’, that he has derived from games. Unfortunately, they are not as simple as ‘just add points’!.
I highly recommend watching Deterding’s presentation, it is an effective synopsis of a debate that is very much still in progress, and shows us why a simplified or direct application of Ralph Koster’s rules doesn’t work with non-games, despite what Volkswagen have been showing us. Instead, Deterding presents his own models, which are not as simple, or easy, and yet may turn out to be a more practical lesson for how we can apply knowledge from games to improve the user experience of mundane tasks.
Replacing the Desktop?
Just under 40 years ago, the desktop metaphor was devised as a way to allow computer users to understand graphical interactions with their computer. Standard tasks, like using a calculator, or deleting files, were presented in a manner familiar to workers from a traditional office place, as an effort to build their experience of computing upon pre-existing knowledge. And, as is evident by this metaphor’s continued existence today, it was a massive success.
Just under 16 years ago Microsoft attempted to reinvent the desktop metaphor, and bring it up to date. The product, Microsoft Bob, aimed to shift computing from an office metaphor to a home metaphor. And it was a massive failure. My first home computer came with Bob installed, and so today I’ll be looking at why it failed, and what we can learn from this failure.
Usability advantages of the desktop metaphor.
So why has the desktop metaphor proved to be a lasting success? Introduced at a time when graphical methods of interacting with a computer were new, it had several key characteristics that led to its success.
...such as fun games
First of all, the desktop was familiar. Rather than having to learn context specific methods of interacting with a computer, it built upon the user’s pre-existing knowledge. For example, when deleting a file, a user could use their existing understanding of a trash can, and drag the file into it (rather than running a deltree command, which doesn’t map with any real-world knowledge). Therefore the desktop metaphor was easy to figure out, and consistent with real life experience, reducing the learning curve upon adoption. This meets Nielsen’s heuristic on a ‘match between the system and the real world’.
Building upon this familiarity was the appropriateness of the desktop metaphor for the tasks at hand. Before home computing, the workplace was the most likely place for users to use a computer, and the computer would be performing office-based tasks, such as word processing or calculating. Hence the adoption of a workplace metaphor seemed appropriate for developing a graphical user interface, as it registered with the target market. This meets Nielsen’s heuristic on ‘recognition rather than recall’.
Furthermore, the desktop metaphor was wide enough to expand to meet the growing roles that computers played. By extending the workplace metaphor through terms such as ‘cut’ and ‘paste’, and the development of graphical tools emulating image manipulation tasks, the desktop metaphor proved that it wasn’t static, and could extend to reach an ever growing range of requirements.
The desktop metaphor also met the heuristic requirement, of having a wide degree of flexibility, by allowing ‘experienced’ users to automate or speed up tasks, such as by selecting groups of objects, or utilizing keyboard shortcuts.
What did Bob try to do?
In the mid 90’s, Microsoft Bob was devised as the successor to the desktop metaphor. Recognising a growth in home computing, Microsoft aimed to shift the graphical interface model for computing from a business/creative focus, to the ‘home’. It was thought that this would open the computing world to a whole range of ‘novice’ users, who would have found the desktop metaphor inaccessible.
Bob presented the user with ‘their room’, covered with clickable objects, such as bookcases, clocks and a notepad. Clicking these things will launch the relevant program (or help you locate files), and you can add your own programs to the shelves. It’s just like your home! (assuming your home is littered with boxes that say ‘Internet Explorer’ and ‘Corel Draw’).
Bob in action
Why did Bob fail?
Microsoft Bob offered an alternative to using the desktop metaphor, aimed at novice users, but its primary failure was that it didn’t offer any significant advantages. For a product that came over twenty years after the ethos of its competitor, this wasn’t a good sign…
Despite being based on the home, Bob still had a learning curve, and so missed it’s key objective of being intuitive. Clicking on a clock to open a calendar, or a pen and paper, still required just as much learning as a calendar or notepad icon in a traditional desktop environment. More complex tasks than just opening programs still require further learning. Also, the enforced ‘home’ layout is just plain inefficient – rifling through a cabinet to find a file offers no advantage to browsing a list of files in a folder.
By attempting to change the way people interacted with computers, Bob alienated itself from existing computer users, and prevented new users from being able to ask for help from power-users. By offering only ‘simple’ ways of interacting with computers, the user was unable to allow users to grow, and learn superior (and more efficient) ways of performing tasks.
It’s also apparent that the ‘cuteness’ of Bob didn’t sit well with users. The two elements of this operating system which outlived the OS itself are among the most hated villains of computing – Virtual assistants like Clippy, and the Comic Sans font. Obviously Microsoft failed to understand the needs of their target market.
The final nail in Bob’s coffin came within a year of its release. Microsoft released Windows 95. It sold… quite well, and offered a fully-powered alternative to Bob based on the traditional desktop metaphor. Bill Gates punished those responsible for the mess that was Bob. He married lead project manager Melinda French. Burn.
What will replace the desktop?
It’s obvious through Bob’s failure that the Desktop cannot be beaten by a simple re-skin or appropriation of another metaphor without offering significant advantages.
As I wrote about in my review of The Humane Interface, Raskin proposes a ‘Zoomworld’ which offers a non-windows environment with no gaps between the operating system and the files. However development by Archy has stalled and they seem to have fallen off the internet…
Or maybe the future will be more like Google, and involve typing queries or commands into a prompt to find answers and perform tasks? Although this does seem like a regression, and breaks several key usability best practises.
So what other systems are out there that offer a viable alternative? Or will it be desktops forever? As ever, I’d be interested in hearing your thoughts in the comments below!
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.
UX needs an Agile environment
Agile is a relatively young software development methodology, with the Agile Manifesto being written less than 10 years ago. It claims to offer a significant advancement from traditional ‘Waterfall’ methodologies, not least because it allows user experience principles to be applied and integrated within the design process. Today I’ll cover a brief introduction to the key differences between a waterfall and agile method for developing software, and how UX integrates well with the Agile methodology.
Traditional Software Development
In the olden days, and today in large unwieldy companies unsuitable for adaption, software was produced using a waterfall methodology. The waterfall methodology involves splitting the design process into distinct stages, and completing each stage before moving onto the next. Exactly unlike a waterfall. Some standard stages are
- requirements gathering
- design
- coding
- testing
- deployment
Each of these stages would be completed, documented and signed off when completed. Effectively this means that there is little scope to go back and make changes based on emerging requirements. For example, after coding has begun, no further design work could be done, even if the user’s needs change.
Another danger of the waterfall methodology
This methodology was found to have numerous problems, and be unsuitable for a typical software development process. So in 2001, a group of engineers came together and devised the ‘Agile Manifesto’
Agile Software Development
The Agile process aims to address the inflexibility of a traditional waterfall methodology. Essentially Agile development is iterative, and consists of short repetitive cycles. These are typically:
- evaluate the existing solution
- design a solution, based on the last solution, to the problems found during evaluation
- build this new solution
- GOTO 1
With a cycle being completed every few weeks, this process should be repeated until the software is complete (or no significant problems are found with the solution)
Sometimes going in circles can get you somewhere
Agile and UX
So why is the Agile methodology best suited to integration with user experience testing? Since you ask, there are a whole bunch of reasons!
- The Agile method gives a workable product that can be shown to users earlier, getting their opinions and insights straight away.
- Has appropriate stages for fixing problems found by users earlier. In a waterfall methodology users won’t see a product until the last phases, and by then changes will be costly, or impossible.
- Waterfall methodologies assume that you can know everything about the requirements of a project at the outset. Real life experience with clients shows that this isn’t often the case. Agile allows for input throughout the process, and doesn’t presume to know the unknowable.
- Waterfall only engages the stakeholder s (anyone who is interested in the final product) at the beginning of the design process, and then keeps them in the dark until the final unveiling at the end. Obviously this makes what would normally be a minor problem with the final product into a big deal, because it is ‘complete’. In contrast, using UX methods on an Agile methodology keeps stakeholders invested in the product throughout the design process, minimizing dissatisfaction with the final product, and ultimately leading to happier stakeholders.
The UPA have recently been focused, in their magazine coverage and events, on integrating UX tools into an Agile methodology, but I’d be interested in hearing other people’s thoughts, or insights into the advantages of Agile. What are your thoughts on Agile?
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!
