Usability will not be resolved with technology. On the contrary, with the advance in technology, new usability challenges are being created. Continuously; new technical possibilities, a wider range of applications, a fast growing group of developers.
In a far past usability of computer applications was constraint to actions performed on devices that had a key-board. The user group was small, typically technically high skilled, special interest groups. Like the ancient western movies; the guy with the white head is the hero. Simple. Then they introduced color. With computers it was the same; the device with the mouse. Nowadays computer devices have a vast amount of possible input devices. Not only key-boards and mouses, but also pens, touch pads and touch screens and so forth, and soon, with the advance of wearable technology and garnent integrated sensors, even your cloth become (an extension of) a computer. The user group also exploded, from a selected few computer fanatics, to everybody. Most people have at least one computer but with over 90% of phone users having a smart-phone and the huge success of the tablet computer, a large number of people no doubt have several. Computing is ubiquitous.
Usability remains problematic. New developers need to be trained, new technologies need to be understood, new domain knowledge needs to be obtained.
Luckily we have guidelines for the designers and check lists for those who evaluate. Despite all the guidelines and check-lists available, usability is still perceived as subjective. Check-lists and surveys seem to be a goal in itself, not a means to an end, leading to better understanding. Typically, I prefer task performance tests and wizard of Oz studies; relatively simple to apply and with a verifiable good/better/best/worst outcome. But, ok. Checklists and surveys as any tool provide valuable results in the hands of those who know how to work with them.
Basis for this dispute may be the apparent disconnection between design/development and test/evaluation. Although both have the same objective (the best usable product for the end-user), their reference, their golden standard differs. Product design is driven by guidelines, preferably as few as possible not exceeding 10. For example 5 timeless usability principles, Donald Norman’s design principles (or see here), Schneider’s 8 golden rules (or check here) or Nielsen’s 10 usability heuristics (or check here). On the other hand, test and evaluation is driven by checklists, preferably as much as possible. For example here, a checklist with 247 usability guidelines. Impressive. But useful?
If the objective is the same, why then is there no clear relation between guidelines and checklist?
If usability guidelines (top-down) were organized in a way to highlight their relation with checklist (bottom-up), the designer and the tester/evaluator have a shared reference of what is good, and can concentrate on making the product’s usability better. Most guidelines and checklists do cover all aspects, but what is missing is – IMHO – a structure that support our top-down goal-oriented thinking. There is some irony in the fact that check lists lack in this respect since top-down and goal-oriented thinking you will find both as usability guidelines.
Check out the check-list below. I will briefly describe the individual areas.
Users – One of the first things to realize is to identify whom the user actually is. Are we talking about a novice or expert? Are we targeting a business environment or more casual? How old is the user or target group? How important is gender? Differences between customers make a difference on how questions are evaluated.
Device – Often carefully overlooked is the device the software actually is for. Quite trivial and difficult to overlook, right? I mean, how can you mistake software developed for a smart phone with a web site. You are absolutely correct that is never overlooked. But you’ll be surprised how often meetings occur where software is created for one device and then carelessly assumed to be an equally perfect fit for another device. Designed for a tablet computer? Well, then it will run equally great on a smart phone, right? No.
Analyze – Put a device in someone’s hands and he or she will go through three distinct phases. No, although similar, I am not referring to the phases a civilization passes through; the ‘How, Why and Where phases’ (see Douglas Adam’s Hitchhiker’s Guide to the Galaxy).”For instance, the first phase is characterized by the question How can we eat? the second by the question Why do we eat? and the third by the question Where shall we have lunch?” The phases a person will go through are similar; where am I, why am I here (or what can I do?) and where to next. The first step is not about what button to click or where to swipe. No, it starts with the basics; defining where you are, what you can do here and how to do that. The user needs to know where am I now, where can I go to, and how do I proceed. For example, I want to go to the center of Amsterdam, then it is quite mandatory to first know where I am now, the options I have and how to use these options. I do not want to know what the price of the ticket of the train going from Utrecht to Amsterdam is. I need to know first that I actually am in Utrecht (and not for example in Zürich). You get the drift.
Choose – after a first analysis the user has to choose an action, ranging from a specific action to move forward or – worst case – to hit the home button and get out of here. To motivate the user to take the next step, the application has to be clear about it’s purpose, transparent in what you can do, and pleasant to look at. Call for action is often mentioned. To frame the action and to make results predictable the application has to be clear about the current status. Users find it easier if actions are framed in clear goals and related tasks. It helps to split tasks is sequence of actions. Knowing users will make mistakes, it is imperative to for a system to be robust and be error tolerant. Last, people do not like to read, and certainly do not like to rely on their memory; make sure to make full use of their ability to recognize.
Transition – The next level is transition; executing the actions to full fill the software’s purpose, and to arrive at the actions it is calling out so loud for.
The next few images show how the checklist covers the various guidelines (Norman, Schneider and Nielsen). Interestingly, the topics ‘clear purpose’ and ‘goal oriented/task driven’ seem to have less focus by the design guidelines. Also interestingly, the different guidelines appear to have their own focus, from more holistic (Norman: where am I) to very practical (Nielsen: what next?).
The ‘enabling users to ACT’ check-list aims to support a both a top-down approach (aiming at the design process, from left to right) as well as bottom-up approach (aiming at the verification process, from right to left). In addition, it the user and device area help to keep in focus both the target user and the environment in which he or she will operate. Try it. Let me know.