Increasing conversions through better usability

1. Andy Brice, Oryx Digital ltd at ESWC2007 Increasing conversions through better usability

2. 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

3. 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

4. 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

5. The conversion funnel Heard of? Credible website? Does what I want? Right price? Easy to use?

6. 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)

7. 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

8. 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

9. 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

10. Efficiency • Minimise the number of clicks/key presses for common tasks ‘Up’ is in a different place each time

11. Innovative UIs are risky Kai’s Power Tools MSOffice 2007 ribbon bar

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. Workflow • Take the user through step-by-step • Only show relevant information at each stage • Don’t enforce the sequence

26. 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

27. 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

28. Textual hints • Tooltips and hint text can be very helpful

29. Use examples • Examples are easier to understand than abstract definitions (even for programmers)

30. 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

31. Use pictures

32. 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)

33. Avoid unnecessary mappings • Why didn’t they caption the buttons ‘Abort’, ‘Debug’ and ‘Ignore’?

34. 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

35. 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

36. 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

37. Configurable warnings • Users should be able to turn off non-catastrophic warnings

38. 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

39. 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

40. 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

41. 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

42. Field reports • Support emails/forum posts/phone calls • Pro-active requests for feedback • Instrumentation crazyegg heat map

43. 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

44. 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

45. 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

46. The effects of poor usability

47. 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