470 likes | 842 Views
Andy Brice, Oryx Digital ltd at ESWC2007. Increasing conversions through better usability. Introduction. A quick dash through the huge field of usability: what usability is why usability is important how we can write more usable software Questions at the end. About me.
E N D
Andy Brice, Oryx Digital ltd at ESWC2007 Increasing conversions through better usability
Introduction • A quick dash through the huge field of usability: • what usability is • why usability is important • how we can write more usable software • Questions at the end
About me • Developing software professionally since 1987 • Interests include: • usability, optimisation, cross-platform development, developer productivity, effective marketing • Full-time MicroISV since Jan 2005 • product: www.perfecttableplan.com • consulting services to other software companies, big and small • Blog: www.successfulsoftware.net • Email: andy@oryxdigital.com
New realities • Bad ol’ days • maybe read a review in a PC magazine • go to shop • look at 1 or 2 choices available • pick software with nicest packaging • Internet consumer nirvana • read reviews on forums and blogs • look at lots of product websites • trial several most promising • buy the best one
The conversion funnel Heard of? Credible website? Does what I want? Right price? Easy to use?
What is usability? • Highly usable software is: • familiar • predictable • consistent • responsive • efficient • Result: • shorter learning time • reduced time to perform a task • fewer errors • improved decision making • happier customers • more sales • increased GGH (Gross Global Happiness)
Another view • “A user interface is well designed when the program behaves exactly how the user thought it would” Joel Spolsky • Occurs when the model of the world presented to the user closely matches their own mental model
Familiarity • There is no ‘intuitive’, only familar • “The only ‘intuitive’ interface is the nipple. After that it's all learned.” Bruce Ediger • Make your app look/behave like other apps the user is familiar with • e.g. Outlook, Excel, Word, Internet Explorer • Follow platform conventions • Use familiar idioms and patterns • idioms: explorer, web page, shopping cart, first person shooter, IDE, discussion forum, media player • patterns: browse files button, tabbed dialog, hyperlink, tool bar, pop-up menu, wizard
Responsiveness • Errors increase as responsiveness degrades • Give feedback on all actions • let the user know their action succeeded • ideally within 0.2 seconds • errors noticeably increase above 0.5 seconds • Use timer cursor for longer actions • ideally with % completion feedback • group all user interaction at the start/end of a long task • use threads to keep application responsive • Remember that users usually have slower PCs than developers
Efficiency • Minimise the number of clicks/key presses for common tasks ‘Up’ is in a different place each time
Innovative UIs are risky Kai’s Power Tools MSOffice 2007 ribbon bar
Beware of metaphor • Can be more misleading than helpful • your software will never behave exactly like a real world object • May overly constrain what you can do • Can get in the way once the user has learnt the software
Design for the user • Know your user • personas • Realise that they probably think very differently to you • try to understand and match their mental model • What is appropriate depends on: • how IT literate your users are • what terminology, idioms and metaphors your users are familiar with • how often your users use the software • the platform • the sort of tasks they are trying to achieve • Put the user in control
Design for a range of skills • Novices use the menu • Intermediate users use the tool bar • Experts use shortcuts and accelerators • Step-by-step wizards may be helpful for novices • Defaults should be tuned to the novice • Experts may want a command line interface, macros, scripting language or API
Cater for novice, elderly and disabled users • Novice users: • might not use double-click • might not use right-click • might not drag and drop • don’t use keyboard shortcuts/accelerators • Elderly users: • might require larger fonts or higher contrast • Disabled users: • might use only a keyboard or only a mouse • all of the above
Put the user in control • The user should feel they are controlling the application, not vice versa • all actions initiated by user as far as possible • allow interruption of extended tasks • avoid disruptive validation • avoid excessive use of modal dialogs • don’t move the cursor for the user • don’t overly constrain
Minimise the cognitive load • A well designed UI will minimise use of cognitive resources as well as machine resources • less resources to drive software=more resources to solve real problem
The other side of the interface • Useful to understand a bit about human perception, processing and memory • limited short-term memory (7±2 ‘chunks’) • has built in hardware for some tasks • perception is highly complex • uses lots of cues and assumptions • optimised for movement/change • Compared to a computer, brains are good at recognising patterns and making decisions and bad at arithmetic, handling simultaneous tasks and detailed recall
Human short-term memory is a major constraint • Don’t assume users can easily commit information to long-term memory and retrieve it again • it is better to allow the user to select from alternatives rather than try to retrieve items from long-term memory • Don’t assume that users can hold large number of items simultaneously in memory • choices between alternatives should be restricted to around 7; if more are required they can be organised hierarchically • Allow for ‘closure’ • having lots of ‘open’ tasks puts a big burden on short-term memory, so tasks should be grouped into well defined transaction units
Movement • The eye is naturally drawn to movement, so use sparingly • flashing cursor • animation • Rapidly changing textual or numerical displays can be fatiguing and difficult to read • Large blinking areas are believed to aggravate epilepsy
Less is less • “Everything should be made as simple as possible, but no simpler” Albert Einstein • Fashion for simpler UI (e.g. 37 signals) • ‘users only use 20% of the features in MSWord’ – unfortunately they all use a different 20% • SUV effect • users have a tendency to buy more than they need • Trick is to provide a rich feature set while presenting a simple UI
Hiding complexity • The digital SLR is a good model for managing a rich feature set • complexity is hidden, not flaunted • huge number of options (focal length, focus, aperture, shutterspeed, ISO, whitebalance) but usually get a fair result from just point and shoot
Hiding complexity • AutoStitch just requires a list of image files and uses sensible defaults and intelligence to create a panorama • complexity hidden in the ‘Options’ window
First contact • The first few minutes are critical • Spend some time getting the installer right • Provide a soft landing • avoid the ‘blank canvas’ effect Blank canvas Soft landing
Workflow • Take the user through step-by-step • Only show relevant information at each stage • Don’t enforce the sequence
Layout • Users will usually scan top-left to bottom-right • use a logical ordering • place most important information at top-left • group controls appropriately Poor layout
Beware nested warnings • Only small children and idiots ask the same question again and again • e.g. If the user is going to overwrite n files, give them an option to ‘Overwrite all’ instead of forcing them to click ‘Overwrite’ n times
Textual hints • Tooltips and hint text can be very helpful
Use examples • Examples are easier to understand than abstract definitions (even for programmers)
Don’t expect user to read • Most users won’t read your documentation • Many users won’t even read what is on the screen (PEBKAC) • get over it • keep text short • use pictures Your dialog, as seen by the user
Use appropriate terminology • Use words your users will understand • e.g. if your users aren’t developers use ‘window’ instead of ‘dialog’ and ‘document’ instead of ‘file’ • Remember that users count from 1 (not 0)
Avoid unnecessary mappings • Why didn’t they caption the buttons ‘Abort’, ‘Debug’ and ‘Ignore’?
Error messages • Some real error message: • ‘This error should not occur’ • ‘(77) Unknown Bogus Error Code’ • ‘Nasty practice #4720’ • ‘osgbpg syntax error#%BootMenu already loaded.#Press any k"#"!’ • ‘Keyboard not present, press F1 to continue’ Not helpful
Colour • Use colour sparingly as an additional cue, not as the only form of information • 8% of males and 0.5% of females have some form of colour blindness • red-green colour blindness is the most common • allow colours to be customisable • check your UI on http://vischeck.com • Don’t use large areas of saturated colour • Get the default colours from the OS • Colours have cultural associations
Icons • Work better for nouns than verbs • Try to make them all look different to each other in terms of shape and colour • Beware of cultural issues
Configurable warnings • Users should be able to turn off non-catastrophic warnings
Attention to detail • Window checklist • Title & icon • explanatory text/images • consistent terminology & layout • sensible tab order • sensible default focus • tooltip for each control • keyboard shortcuts/accelerators • context-sensitive help button • useable on lowest spec machine e.g. 800x600 pixels
Sound • Amount of information that can be conveyed through sounds much less than vision • Many business machines don’t have speakers • Generally not appropriate in an office environment • make sure there is an option to turn it off
Test for mimimum spec • Decide your minimum system requirements and test the UI under these conditions • screen size • colour depth • processor • Use web logs to decide minimum system requirements
You are not your user • The user’s experience will be very different to yours • you have lived this software for months/years, they will judge you in minutes or seconds • you probably have very different skills to your user • the user doesn’t really care about your software, they care about the task they want to achieve • Corollary: you need user feedback
Field reports • Support emails/forum posts/phone calls • Pro-active requests for feedback • Instrumentation crazyegg heat map
Usability testing • Requires just a suitable ‘virgin’ user, PC, software and (if you are being fancy) a video camera • Set tasks • Ask user to verbalise thinking • Don’t help! • Rinse and repeat
Trends • UI guidelines are being loosened • Separation of presentation and logic • Convergence of web and desktop • Ribbon bar • Animation and multi-media • Gradients, round edges, transparency and other ‘eye candy’ • Experience engineering • Metrics/instrumentation
Conclusion • Concentrating on usability: • makes users more productive and happier • increases sales • Is the right thing to do • Good UI design: • is difficult to do • is iterative • looks obvious in hindsight • If a significant number of users find your software hard to use it’s your fault, not theirs • But you can’t please all of the people all of the time
Further reading • ‘User interface design for programmers’ J.Spolsky (2001) • ‘Designing interfaces’ J.Tidwell (2005) • ‘Don’t make me think 2nd Ed’ S.Krug (2005) • ‘Design of everyday things’ D.Norman (2002) • ‘Mind Hacks’ T.Stafford & M.Webb (2005) • ‘Programming as if people mattered’ N.S. Borenstein (1991) • ‘Guidelines for Designing User Interface Software’ Smith & Mosier (1986) • My blog: www.successfulsoftware.net