Posts Tagged ‘paper prototyping’
The importance of usability in Mobile Geolocation games.
Mobile geolocation games are a hot topic right now. The popularity of the iPhone, the potential for geolocation in HTML5, the geographic API integration with Twitter, and the rise of games like Gowalla and Foursquare all point to a significant shift in people’s perceptions of the potential of geolocation. I’ve recently been involved in the design of a geolocation game, and have seen the potential of the medium, as well as the usability lessons which must not be forgotten when designing multiplayer games with location in mind.
Working in a small group at the University of Sussex, and in conjunction with the Brighton based mobile games company Locomatrix, we designed and prototyped a game that uses location as a game-play element. Unlike currently popular games, like Gowalla, we wanted the game to be immediate, and played as a short, fixed-term game, not an ongoing campaign. Hence, after evaluating several ideas, we developed a ‘Predator’ style game, where the players are hunted, and turned into hunters, until only one survivor remains.
Pretty much like Willy Wonka & The Chocolate Factory
Into every step of production of the game’s design we aimed to integrate usability and user experience tools. For example, the initial design of the game was based on a survey sent out to a group of prospective players, with their results collated to inform elements such as the game’s multiplayer element, objectives, and artistic style.
In the iterative prototype development cycle, user research was conducted. From the first paper prototypes, to the final JavaScript version of the game, real players were brought in, and asked to play the game. Their reactions and observations were noted by invigilators, and further developed through post-test questions. Hence, even before we had a playable version of the game, it was possible to test player’s reactions, and deal with problems earlier, rather than later, where they would cost a lot more time to resolve.
An early geolocation prototype
So what did we learn about mobile geolocation games? Exactly the same things that should be considered for any sort of product development.
We discovered the issue that was most crucial for the mobile geolocation game is considering the context in which the game will be used. The game we made was designed to be played outdoors, fast paced, and possible in a busy city. Hence the game’s interface needs to make this easy. We ended up with
- Very few buttons (one most of the time, a second one when you can tag a player)
- Large buttons (takes up half the screen)
- Audio cues associated with important activities, such as when the player is in danger, or when the can perform an action.
So, instead of having to stare at the screen all the time, the player is free to look at their surroundings, and only involve the phone when given an audio cue that they can act. They won’t need to hold their phones in front of their face as they play – crucial for not being mugged! And when they need to act, they can do so quickly and easily, not impeding the game-play.
The interface, which could have proved a huge barrier to a ‘fun’ game, has been minimised, as a consideration to the context in which the game is played. This was discovered as the optimal method through iterative prototypes and tests with users, and is heavily dependent on the type of game. A minimal interface may not be ideal for all applications (consider a first person shooter with one button), and yet the context of a geolocation game allowed it to succeed here.
So, what lessons could we take from the development of this game? More important than the discovery that outdoor mobile games work best with a minimal interface is the method used to make this discovery. Involving users brings advantages no matter what product is being made, or what stage production has reached. From the first paper prototypes, we could see the interface players preferred, and hence reduce development time and cost. The time ‘cost’ of involving users is greatly outweighed by the time it saves from redundant coding. And everyone can see the advantage of that!
Effective UI by the EffectiveUI team – Book Review
Effective UI is a new book by … EffectiveUI, which aims to give an introduction to the art of building a superior user experience. EffectiveUI (the company) are a user experience agency from the US, recently known for building the iPad app Ideate, a tool for wire framing and sketching which uses pre-set templates for designers and developers. This book is the result of their years of experience, and aims to share some of the lessons they’ve learnt about delivering superior products through user based research.
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!
The Uncanny Valley of Wireframes
The uncanny valley is a theory describing how, as games and robotics produce more accurate representations of humanity, people’s reactions towards them are increasingly negative. This is also true with the production of wireframes, and in user experience testing and is something user centred designers need to be aware of.
The uncanny valley was originally discovered in the field of robotics, but also frequently applies to video games. It describes a phenomenon with replications of humans, whether they are life-like androids or avatars on a computer game. Initially, as the reproduction of a human and its movement becomes more lifelike we react more positively towards the object, so we’d like Lara Croft more than Leisure Suit Larry. However a point is reached, when the reproduction becomes too life-like, and the emotional response drops rapidly, meaning we feel repulsed from the object. Consider Keanu Reeves’ acting. Almost human, but utterly repulsive!
The term ‘uncanny valley’ therefore comes from plotting a graph showing our emotional response against how lifelike the reproduction is, with a sharp ‘valley’ appearing in the emotional response between a very lifelike reproduction, and the real thing.
Got that?
A similar phenomena can be seen in the production of wireframes, and hence is of critical importance to UX designers. After spending hours producing beautiful wireframes in Omnigraffle, I presented them to a client, to show how their ‘event registration’ pages would function. They came back and said “yeah it looks good, but we need to change that label text… and we need to make the dropdown arrow bolder… and can we make the heading font bigger”. This was their first view of the wireframes, to approve whether they functioned correctly, and it’s obvious what I’d done wrong.
The time and effort I’d put into making the wireframes look good, and look like a real website weren’t just wasted, they were actually hindering the process – since the mock up looked like a real webpage, the client was focusing on the small presentational details, and not the functionality itself. They expected it to look and function like the final product. If instead, I’d done a rough sketch on paper to demonstrate how the registration process should work, the client would have focused on the functionality instead. A design that looks to be in the early stages will encourage more far-reaching comments and criticism, rather than ‘fine-tuning’.
This is most important when you’re trying to focus the user experience when performing tests, especially with people not overly familiar with your site or game. Performing tests to ascertain the correct information architecture, or user’s experiences with a website’s functionality would be useless if all your comments ended up being about the site’s colour scheme. To make it clear that the designs are rough, and the presentation is not the focus, it is important not to create overly realistic designs.
Similarly care should be taken to pick an appropriate prototyping method. Paper isn’t used just because it’s quick and easy, but it also helps manage the client’s expectations. If you spent the time making the webpage on a computer, they’d be expecting it to work like a real product. On paper, this isn’t the case. Like the uncanny valley, getting too close to the real thing will be detrimental to the client’s perception of your work.
And you wouldn't want your work to look like this...
So, what steps do we need to take to ensure that the client, or user will focus on the right areas of your wireframes and designs?
- When performing initial designs, use lo-fi methods, like paper, post-stick notes, and whiteboards, where possible
- If using design software, like Pidoco or Omnigraffle, use a ‘sketches’ template, which renders your design in a pseudo-drawn method.
- Avoid drawing/designing unnecessary parts of the design – focus only on the essential
- Use filler text, and don’t work on the copy until later.
- Make it clear to the user/client that these are rough, disposable prototypes.
So, whether you’re working with a client to design their site, or conducting user testing, take care not to over-present the design, in order to manage expectations, and prevent unnecessary complaints!
Evaluating existing technologies, paper prototypes in action, Windows 7 and the disappointing user experience of my DVD player!
This week our HCI course featured an introduction to starting the design process by evaluating existing technologies, and the key advantages of this were made apparent when we started to build paper prototypes.
In an abstract sense, the advantages of evaluating existing technology is that aids redesign – you can see what elements turned out successful, and which did not. What this means in practise is that you can steal the best bits of the competition, and fix the bits that users complain about (and hence find raw user experience data on the internet). This is particularly pertinent with this week’s release of Windows 7.
Aside from multitouch (surely useless for most home users), two of the main ‘new’ features of Windows 7 are likely to be the result of evaluating existing technologies – mainly OSX.
The task bar now has persistent icons, so they don’t go away when you close the program. Programs that are closed have a slightly different visual effect applied to them on the task bar. OSX users will of course remember this from their own Dock.
Windows 7 Taskbar
Or is it this one?
Another borrowed feature is the new way show desktop works on Windows Seven. Hover over the bottom right hand corner of the screen, and it will look like this:
show desktop
As OSX users will know, this is the same as leopards’ exposé feature, which allows users to show all open windows, all application windows, or (as in windows 7) the desktop, by moving the mouse into the corner of the screen. When I used to work on Mac’s, I thought this was a great feature, and its no surprise why Microsoft borrowed it.
Both of these are examples of taking ideas that were either popular or productive, from a rival operating system, and integrating them into your own design.
Also this week is the launch of the first Microsoft Store. Again, they evaluated the existing user experience of an Apple store (sleek design, answers bar, the layout) and… nicked it. Great success!
This isn’t just Microsoft bashing by the way, its just relevant examples of evaluating existing ideas, and taking the good bits. Everyone knows that Apple nicked all its ideas from Xerox anyhow!
So, in the spirit of ‘evaluating existing ideas’, we have been involved in the design of a new system for the University. User Experience will be important here, for the feature we are designing is likely to be used by students in high stress situations. We had half an hour to paper prototype some ideas on how to build the system (which it quickly become apparent was not enough time). Then we swapped, and compared our own designs to those produced by other groups. My personal favourite design (by Hassan and James ) had emulated key features from eBay, particularly how they categorised entries by the status (i.e. on eBay, ‘items being bid for’, ‘items I’m watching’, ‘items sold’ appear on separate lists).
This practical exercise brought home the advantages of paper prototyping, and evaluating other designs. Paper prototyping had proved to be:
- Fast
- Useful for brainstorming ideas
- Able to be changed quickly
- Adequate at demonstrating the key features of a website
and evaluating existing designs had not only helped our group find a better solution than the one we’d implemented, but also had been a key part of James and Hassan’s design process.
My ‘design gripe’ this week was my DVD player. It has many problems, a few of which I’ll share here.
- If there is no DVD in the player, it displays ‘NULL’
- The ‘time played’ counter (the default on the front of the player while playing a DVD) only counts to an hour. Then it goes back to 0 minutes again.
- The sound volume of a DVD is roughly half that of the normal audio output of the TV (and this is with the player’s DVD volume settings set to max)
- If multiple camera angles are available on the DVD, the icon for it (a little film camera) appears on the TV screen always. Its quite distracting when watching a film, and cannot be turned off. Same for if you use the ‘zoom’ functionality.
From this, we can deduce the following points:
- User experience wasn’t a priority, as ‘Null’ would mean nothing to a non-geek audience
- The player is probably intentionally badly designed, to drive the user to a higher priced one (I assume the company make more expensive ones). This may be counter productive though, as I’d be unlikely to go for the same brand.
- You shouldn’t buy the second cheapest DVD player Argos sell. (I’d hate to see the functionality of the cheapest one)
my next dvd player
I’ve started reading Alan Cooper’s The Inmates are Running the Asylum, which diagnoses the problems with technology currently as a lack of understanding by the business of the need to separate programmers and designers. Programmers are great at thinking logically, and making tools they themselves could use effectively, however they need to be given clear goals and design models by people who are better placed to understand user needs, and that is where our role as designers come in. I have to say, it’s a lot more readable than the HCI textbook, and Alan Cooper has a great degree of insight into the subject. He recounts the following (rather old) joke, which is quite relevant to our field of user experience.
He shouts down “I’m lost, where am I?”.
The man replies “You are in an airplane, 100 feet above the ground”.
After hearing that, the pilot immediately flies off, and lands successfully without a problem.
“How did you do it?” he was later asked.
The pilot replies “Well, with an answer like that, I knew I must be at the Microsoft building, and I know my way back from there”.
As we can see, the answer was true, but not helpful. This is what we want to avoid as user experience architects.
I was going to feature here the terrible user experience of Ticketmaster’s website, but I think it’s so bad it could fill an entire blog post on its own. Expect this soon (especially since I’m bitter I didn’t get my Paul McCartney tickets)!
HCI learning, a day analyzing user experience, and thoughts about remote usability testing
My membership to the Usability Professional’s Association went through this week (although disappointingly I have to wait a whole 4-5 weeks for my Designing The User Experience poster), and to celebrate I went to the UX Brighton event (‘Remote User Research – A 360˚ View’ ), and met the head of the UK Chapter of the UPA, Claire Mitchell (small world!). I’ve written more about this at the end of this blog post, but it’s a bit epic, so I’ll cover everything else first!
a paper mockup of the T1000
This week in HCCS, we’ve been learning about the process making of paper mockups (mostly scissors and sticky back plastic!), and the advantages (quick, manages user’s expectations, gives the opportunity to hide in a box and pretend to be a robot).
This has been supplemented by the (rather dull) course text book by Dix ‘Human Computer Interaction’. Dix tells us about the ways to input information into a human (sight, touch, sound, smell etc. ), how it’s stored (sensory input, short and long term memory – needs more ram!), and our limitations (we can only remember around 7 chunks at a time – a factor in Tetris’s success!). When amazon can be bothered to deliver it, I’ve ordered Alan Cooper’s (The Inmates are Running the Asylum), which should be a more interesting read.
The design complaint I contributed this week was Amazon’s log in link being “Sign in to get personalised recommendations” (with the sign in link being on the personalized recommendations text).
a design mistake?
As documented in Krug’s Don’t Make Me Think most users will ‘scan’ a page rather than read the full text, looking for buttons or links which do the task they are looking for. As someone looking to sign in, my ‘scan’ would reject this link as a) ‘Sign In’ isn’t the link and b) You’d assume the link would take you to personalised recommendations, not the sign in page. However, as we discussed in class, Amazon do a lot of A&B testing (running two versions of the page concurrently with slight differences, to see which ones get the most successful ‘goal completion’ rate). Therefore we have to imagine that this has been a conscious choice by amazon, either because more people are looking for personalized recommendations that to log in, or because it increases customer’s awareness of this feature.
We’ve been given the task of logging our experiences with technology through a day, and considering them from a design point of view. That’s what you lucky people are in for now! (hold on tight, its ranty!)
Waking up:
Alarm Clock – Hit snooze (big button on top, good design feature). Turned it off by turning the radio on and off. Design fail – I imagine there’s an ‘official’ way to turn the alarm off, but in ten years of use, I’ve never found it.
design success - you wont fall asleep with this alarm clock near you!
iPhone – ran out of battery last night, and I left the plug of the charger at my parents, so has to charge off USB. Plugged it into my work laptop to charge, but the USB only charges when the laptop is open (not in standby!) Design fail – annoying that I have to have the laptop open to charge my phone.
TV – is quite old, and turns on to the analogue channels, rather than the scart input. We have cable, so it only ever uses scart. I guess it should auto detect whether theres analogue or scart data being fed in, and select which to show automatically. Design fail - It doesn’t though.
Employment fun:
Laptop – Backlights failed on the screen, so have to take it into work to get it replaced. Replacement has no battery life, so won’t survive unplugged. Design fail – Laptops too frail for my clumsy ways.
Successfully got to my desk with the new laptop, and charged my phone with no design issues!
IP Phone – I don’t understand it. It says I have a missed call, but no details of when/who/what. Red light is lit up on handset, I cant recall whether its always been like that. Later in the day it tells me I have a voicemail, with a flashing envelope icon. I lift up the receiver, and press the button next to the flashing icon. Nothing happens. I try again with the receiver down, the phone beeps at me. I lift up the receiver, and try other things. The button marked messages does it. It asks for a pin. I have no idea, but am logged into the phone, so it should know its me already, right? Eventually find my registration email with a voicemail pin. Successfully retrieve voicemail. Design fail – too many to count.
Coffee machine – I’ve worked this out now, but it took a short amount of observation when I joined. Its next to a pile of cups. Do you need to put the cup in the machine before selecting the drink? If so, where? (turns out, for all of you who are worrying, that it doesn’t need any cups, it automatically gives you one) Design fail – Not clear how to load/use initially.
Home time:
Sky+ – I’m not particularly familiar with Sky+, so it’s a learning experience… Design fail – Everytime you return to the TV guide, it goes to the start of the list!
Book – papercut! Ow! Design fail – paper should be replaced with some sort of foam.
What a busy day!
My impressions of the UX Brighton event
The Remote User Research – A 360˚ View event was in the Old Music Library, which although lacking in heating and lighting, does have a lot more scary art than most venues. Free beer was generously supplied by the sponsors, which starts the night off on a good foot. The topic of the evening was performing remote usability testing, with talks given by Feralabs, Ethnolabs, Pidoco, and Flow.
The first three talks were presentations of technology the companies had developed. Ethnolabs have produced an API which collects data on specifically tagged topics from feeds such as twitter, social network sites and email correspondents, which can then be used to correlate user experiences. The example they used to demonstrate this was people’s impressions of a new digital camera. Although their API technology seemed functional, I was under whelmed by their product – although the piecemeal opinions of users aren’t useless, I think that without specific tasks to try to achieve, or interview questions being asked, it’d be hard to achieve any standardized conclusions from the data. Also I’d question what incentives would be offered to the user’s to bother to tweet their opinions – surely without an incentive causing every user to tweet, the data retrieved will be rather biased to the polarized views (“I hate this!”).
The second talk was by pidoco, and was about their collaborative wireframing tool. The technology here did impress me, and I can see the use in immediately being able to adjust and present new wireframes to a client remotely (the system also logged voice, so longer suggestions could be reviewed later). The artistic style of the wireframes imitated pencil sketches, rather than the precise lines you’d get in omnigraffle, which is also helpful in managing client’s expectations. I know before I’ve presented wireframes that look precise, and the client has spent along time reviewing minor items like the text within it. Pidoco’s tools’ emphasis on a rough sketch aesthetic would help manage situations like this!
The last two talks were slightly linked – a presentation of a remote data logging tool by Feralabs, which gives users tasks to complete and logs their precise experience in doing this, and a report by Flow on their experiences using this tool. The tool seemed effective, logging the user’s navigation, mouse clicks, and asking them questions after, and Flow’s review was interesting, and sold the idea to me. I would defiantly consider using a logging technology like this in performing certain kinds of usability testing. In the heated Q&A session after, it was discussed at length that this should be used in conjunction, and not instead of face to face interviews, for it was agreed that remote usability studies cannot log or reproduce every element of a close personal study, you fail to see the emotions and reactions of the participant involved, and it’s harder to adapt the test to study interesting emerging behaviour variants. However, it is cheaper, and I know the business side of most organisations will like the sound of that!
