Would you get on this elevator?
Went to visit a good friend that just had their first child at a local hospital. On the way out from the joyful visit, I was greeted by this wonderful elevator:
The display was locked-up mid-boot and never did recover during my short trip from the 4th to 1st floor. Everything went well, but wow.
This brought up the importance of how it is often it’s the *subtle* clues software needs to be giving off that show that things are working ok and the software is built with enough quality to handle many eventualities to the level we feel confident enough for our important data (or in the case of this elevator – our very lives). Interfaces that lock up after you hit a button, spinning disks that don’t give you any clue how long they’ll take to come back, or dialogs that have confusing wording are all things that make you start to feel un-trusting of the software and start thinking it is glitchy or low-quality.
Brings me to a pretty decent book on UI design I read recently “UI Design for Programmers” by Joel Spolsky. Here were some of the notes I took while reading his book:
- People feel good about software/something’s usability when they get a “chain of victories” – when a tiny chain of perfectly timed events/accomplishments go off right. That’s what makes people enjoy using your software and perceive it has value and was well designed.
- Know the point of usability testing: You only need about 2-5 people to test your usability. More people than that, and you’ll see same stuff again and again. You don’t want numbers/stats like ‘27.5% of the people found the save dialog box’. You want to know what users think should happen – so the thing you’re looking for are things like “Most of the users kept opening the file menu to find the save feature – but it wasn’t there”. The point is to teach you how people *think* the interface should work. If you just outsource this and get a stack of numbers back, it’s like paying someone to go to college for you. You are not learning how the average person approaches the visual clues on a computer.
- Use ‘affordances’ to help users see/learn what to do:
Affordances are visual clues. Use negative space to show where hand or finger goes like they do on camera bodies, put ridges on window edges to show it can be sized/slid. Make tabs act like real file folders so they click and show new panes, etc. - Don’t break real world metaphors:
Windows briefcase was totally confusing since didn’t work like real briefcase. Do I put things in it then copy that to my pen drive to take it home? Also, always obey the laws of physics – windows tabs dragging things should behave as on a real desk. Don’t rely on the user knowing about strange ‘hidden’ panes or the like when switching between things (early versions of Mac Office did this). Don’t break people’s expectations of how something works if you use a visual metaphor. If you’re using it, it should be because it’s a GOOD metaphor. - Consistency
Certain hot-key combos and other UI behaviors had better be the same as other apps or people will get frustrated. Even if you hate the way Microsoft/Apple did it – different or ‘clever’ new UI or key shortcuts for cut/paste and other common features will just anger 99.999% of the people (yes – this means you Linux). If you’re going to do it differently, you better understand exactly why and that most people will probably TRY to do it the old way; so be ready for that. - Designing for extremes often produces better designs for everyone
If you design your product for difficult/extreme cases – it should become even easier for normal use. Design for people who are colorblind, for low light, shaky hands, wearigng gloves, etc. RFID cards for hotels were designed for folks that had poor vision/arthritis, but turned out way easier than standard house keys for buildings and are used all the time. People now just put coat pockets up to the the sensor when their hands are full – much easier. Designers started designing large handled kitchen tools for people with arthritis; and then it turned out everyone actually preferred them – now almost all modern utensils have large handholds with nice grips and large knobs. Your UI should never rely on color for functionality. A good number of people are partly colorblind – so if you design in B/W, it will help you create affordances that will likely help everyone – i.e. pie charts that have labels that float over each slice instead of just in a color key to the side with many different colors that are very close in shade.
For computers – design for people that can’t: read, use mouse well, or have memory so bad that can’t remember own name if it wasn’t on a card. This is the right way to design for usability that turns out good for everyone – and not condescending like the ‘clippy’ assistant was. - Mice are hard to control
Assume everyone is using your app with a crappy laptop trackpad or clip-on trackball attached to their laptop.
Listboxes should expand to whole physical page or max elements – don’t make them scroll if at all possible. Dropdowns should happen if you click ANYWHERE in dropdowns box – not just the down arrow. Always autoscroll down when near bottom of page. Use bold, fat fonts so characters are wide & selectable like Macs that use Chicago font. No characters should be 1 pix wide like if you use Arial. - Not all happenings are equally likely
Coders think that if you allow something between the range of values, that any value in that range is equally likely. This is usually wrong and leads to inefficiency. i.e. If the range of 0 to 100 is allowed, 50 is probably more likely than someone choosing 47. If you allow window repositioning, odds are most of time folks will want windows in certain spots – like right against edge, not exactly 2px from edge. Or if a window is inside another window – should you really allow sub windows to go past edge? Snap too or have elements go to the most *likely* values/positions. Photoshop has a snap to edge/nearest ‘edge’-like feature of the picture ability. - Don’t force remembering – give hints along the way
Menus give lists of commands so you don’t have to remember individual commands like the old Emacs days. Always try to allow folks to chose from lists of things instead of having to remember. Give other context hints: thumbnails show what the contents of a file is, autocomplete helps finish words. All little helps are good – but don’t go overboard – allow easy outs or pass arounds for your ‘helping’ or folks will get frustrated. If you fail to guess right 2-3 times, auto-disable the feature. Photoshop’s snap-to feature is easily disabled in the menu bar, or just hold down ALT to get rid of it for that operation. - How to design a product
Don’t design by listing features you want – start with list of activities you want to accomplish. What activities do you want to complete with your software? This is especially true for version 2.0 of your app. See what people ACTUALLY use it for and optimize for those activities. Turns out many people use Excel to make simple lists – which killed competitors when they optimized for other activities. - Don’t fall prey to “design time warp” effects
You take weeks to design the dialog boxes and flow – thinking long and hard about it – but the user sees it and needs to make a choice in 5 seconds. They see so many options – they don’t know what to do. i.e. a complex print dialog box that has so many options and parameters nobody knows WHAT to do with all the buttons/options. Solution is to take a printout of the dialog to conference room and ask 3 people what they would do if they saw it.
Over the course of the 6mo to 2 years you develop things, you come up with more and more ideas. While you learned them over months and years, your user will experience them in just a minute or two. The best designs are the simplest – like a toaster. If a software design team built a toaster, it’d end up costing $1200, make toast, BLT’s, have lcd displays, and boot up and ask if you want to register for AOL before you could make a single slice of toast – and it probably wouldn’t even do that right the first go. VCR designers kept adding more features until they realized what people really needed was if you put a tape in, it should automatically switch to the VCR mode of the TV/VCR setting, and actually start playing right away, then auto rewind when it hit the end of the tape.
Seconds feel like hours when you get no immediate response back. After about 2.7 sec, people get bored/give up. So when you click on something – always do SOMETHING, never just sit there blankly while you work. Turn cursor to hourglass, progress bar immediately appears, etc. try to break up long operations when it makes sense. Instead of waiting for VB to compile all at once when you hit F7, do the parsing after each enter for a half-second, so compiling was fast.
When that fails, bunch all long operations TOGETHER so you ask all the questions up front, then tell them to go get a coffee and when they return – it will be done. NEVER pop up a dialog half-way through that pauses the long action so they’re stuck at the machine for the whole time.
Basic takeaway: Over the time you design a package, you should be removing complications, not adding them. - Don’t confuse usability with learnability – Figure out if you need learnability or usability in your app. If the user is going to use it once or twice (like a map kiosk) they need high learnability. If it’s something they use every day – it needs to be very usable. Hopefully a usable program is learnable so that the user can figure things out on their own. This means it might not necessarily be that it’s easiest on the first go – but should act the way the expect the first time.