Learning from lusers is all well and good when you’re designing for, uh, novices. But what about experts? Sometimes they’re just as problematic. To the layperson, usability is almost synonymous with learnability –the capacity for new users to sit down in front of the app and successfully use it immediately the first time they see it. And indeed, for something like a web site or a toaster oven for the general public, learnability is often the overwhelming first priority.
But there’s a whole other side of usability that’s about making powerful and efficient apps for those with expert knowledge. For example, a tremendous amount of human factors engineering went into the flight deck of a Boeing 777, and the result is a highly usable interface for an experienced air transport pilot, but you certainly wouldn’t expect a random person off the street to be able to figure out how to simply start the engines.
Should your software be the toaster oven or the flight deck? Users of public web sites need the toaster oven. On the other hand, for many database applications, such as those for customer service, process control, and financial transactions, your users interact with the app every day, perhaps all day long. They’ve seen older systems and processes come and go. They’ve been doing the task for years, maybe decades, and know more about the domain in their respective little fingers than you will ever learn in making the UI. Efficiency and power become the main goals for these experts, and they need the flight deck. Most apps fall in between the extremes of flight deck and toaster oven, and you have to balance learnability with expert concerns. As Alan Cooper points out in About Face, most users are neither super-power users nor complete novices. They have some expertise, but they also perpetually have new things they need to learn. Fortunately, design features to maximize efficiency do not necessarily degrade learnability, so by working with both in mind, an optimal design is achieved.
But let’s focus now on just what experts need from a UI. It depends on what you mean by “expert.”
Task Experts
These are people who know the task to be accomplished and what it takes to accomplish it with the software. They are the users who will use your program daily, leaving it permanently opened on their desktops. They are likely well-trained on the software, but whether they are or not, a few months of such intensive use of it makes them plenty knowledgeable. They may form an informal mutual technical support group, passing hints and advice across cubicles on faster and better ways of completing the task. Here is where focusing on efficiency pays off, where saving one click can translate into thousands of dollars saved per year across 100’s of users.
To maximize efficiency, you should provide shortcuts, both for when using the keyboard (accelerators and mnenomics) and for using the mouse (toolbar controls, context menus, and double-clicking). You should support both keyboard and mouse methods for executing major actions in order to minimize the need for the user to switch between mouse and keyboard. Support drag-and-drop, perhaps with alternate actions contingent on the modifier key the user depresses. Support the mouse’s scroll wheel.
When looking for speed, any work to get to the work is unproductive. The UI should be designed to minimize navigation as much as possible. Consolidate all information and feedback to one or a few windows. One big complex window is better than three simple windows. Avoid a “home” page or window that is nothing but links or menus to other content or activities. Instead, provide a “dashboard” that allows the user to monitor key information and perform the most common tasks. Alternatively, have no centralized window at all, and simply open the application to the windows the user uses, populated with the queries they most likely need to execute. Organize your fields for rapid scanning and quick, unambiguous selection (e.g., from combo boxes), validating that your organization is consistent with how your users think.
Use direct-manipulation design to provide the users with the ability to view and modify the attributes of data objects directly in the primary window. Nearly all input should be do-able by users changing various controls displayed in the primary window. Trips to the pulldown menu should be rare. Use of a dialog box should be unheard of for common tasks.
To allow so much information in the confined space of a few windows, use minimum but clear text. Controls should have short brief labels. Trained users don’t have to identify fields from reading labels; they only have to recognize them. The label only has to help remind them of what the field is. You may even want to use abbreviations and symbols for labels or field values, especially if it makes the difference between having one or two windows. Avoid explanations or documentation in the window. If a trained or experienced user needs such an explanation or reminder, you’re UI is wrong. Redesign it.
Loading up everything on a window is great for these experts, but even they have limits on the clutter they can handle. Make a proportional UI design, prioritizing your data and features, keeping the most frequently used items close at hand (e.g., at the top of the primary window, in large bold font). More rarely-need data and features may be a step or two away, perhaps even in a separate window. Optimize accessibility to commands and parameter values within controls, with the most often used values used at the top. Default controls to the most commonly used values. All of this is driven from your research of the users, tasks, and environment. The final UI is tuned to maximize productivity on the most common tasks.
Make sure your UI is internally consistent. You’re planning for your users to fly through the UI. They won’t have time to stop and think of exceptions. Make sure the same action has same effect throughout the app. The same command should have the same label, same accelerators, and same toolbar icons everywhere. If a shortcut is provided in one place, than provide it everywhere. For example if the user can drag and drop data records in one window, then it should be possible in all windows. If you provide a Save and Proceed menu item and accelerator for data entry of one class of records, then provide it for all classes of records.
Platform Experts
Platform experts are those highly knowledgeable with the user interface conventions and even some of relevant technical details of the operating system. They know all the standard shortcuts and presentation options and expect them to be available.
For these users, external consistency is critical: you need to stick closely to the platform’s UI standards and conventions. For example, the execute button in a dialog box should be in the lower right for Macs, and second from the right just left of Cancel for MS Windows. Copy and Paste should be under Edit. A folder icon means “open.” Checkboxes are used when the user may choose many from many options. Option (or radio) buttons should be used when the user may choose one from many options. You should never re-invent controls with functionality that is the same as any standard control. Slide-out drawers might look slick, but a platform expert user can use combo box faster and more accurately.
Your app should include all the general capabilities and features one sees in a GUI, even if these are not necessarily related to specific requirements or use cases. Platform experts know these capabilities exist and will use them perhaps in ways you never anticipated. Your app should support multiple running instances and/or open primary windows. Each primary window should be resizable, maximizable, and iconifiable. Your menus should support accelerators and mnemonics, and these should be indicated in the menu item caption. Toolbars should have tooltips. You should back up the pulldown menu with data object-specific context menus, where the default action may be executed through double-clicking.
Double-clicking-for-the-default should also be supported in dialog boxes, where double clicking on a parameter selection control, such as a list box item or option button, selects that parameter value and executes the dialog’s action, closing the dialog as it goes. Undo, cut, copy, and paste, should be supported in all windows, even if it’s only to manipulate simple database fields such as dates. Tabbing should move focus from field to field in a reasonable order.
And you should have Help. If MS Office is any indication, Help is more likely to be used by expert users than anyone else.
Legacy Experts
These are experts at manipulating that clunky old legacy system you’re aiming to replace. You may have seen these experts firing away at their green-screen character-cell terminals at the airline ticketing or rental car pick-up or hotel check-in counters or similar locations. Hands on keyboard, fingers ratta-tat-tatting like machine guns, they send fields and menus and screens flying by at astonishing speed. They’ve memorized zillions of arcane codes for field values and screens which they hammer out in an unending stream. (Really unending. I have to wonder what the heck all that typing could possibly be. They have my reservation. So why isn’t it just, “okay, you’re here, click-click-swipe, here’s your key”?). These experts are a living monument to human adaptability over years of daily experience to the limitations of a primitive information management system.
So now you show up to free them of that old dinosaur and give them a new state-of-the-art client-server, or maybe web-based, system. Boy, are they going to thank you.
Sure. The thing is, while those old green-eyed monsters took forever to learn, a lot of them were pretty fast to use once they’re learned. If you roll out a new UI with lots of pretty colors but no performance advantage, you can expect resistance from these experts, and it’s not an irrational reaction. They were doing perfectly well with the old system. Now they have to learn a new system, which involves some effort and pain. They don’t give a hoot that this system can be learned in one tenth the time as the old system –they already know the old system. They have to exert what they see as unnecessary effort just to achieve their prior performance.
Or maybe to achieve slightly worse than prior performance. When it comes to a database app where the UI is a set of virtual forms, there’s very little inherent in a GUI that will make the job faster. A GUI’s mouse, toolbars, tabs, resizable windows, proportional font, and color provide little or no performance benefits when a highly experienced user is typing away on a form. Just going GUI is not going to automatically give you better usability. If you blow a couple usability issues –get an icon wrong here, mess up the field order there –then you’re asking your most expert users to learn something new that makes their job harder. No thank-you brownies for you.
The number one rule for satisfying legacy experts is to design the new UI for superior performance over the old UI. It’s not good enough if users can match prior performance. After training and experience, users should be able to do their job faster and more accurately with the new system.
Study the old system and the experts’ use of it and look for neat little things that can be imported into your new system. Did you see how they can escape up to a blank line at any time and type in a different account number to retrieve its records? Your design calls for File – Open to get a dialog box with multiple fields to generate a list of accounts to choose, and an Open button to complete execution. A flexible and intuitive design following conventional GUI practice, but the legacy system design cleans its clock on retrieving a known account number. Solution: a text box in the toolbar for entering the account number to retrieve.
Also look for weaknesses in the old system, such as steps that can be eliminated or automated. What’s this “bundling numbers” associated with past transactions? Why do users need to enter them in order to review the transactions? What? It’s a holdover from the punch card days? Get rid of it.
Expert users may be willing to learn a new system if it clearly makes their job better, but that doesn’t mean they won’t also appreciate your efforts to ease the learning curve, so you should also do what you can to maintain consistency with the old system, by working the same conventions into the new UI. Use the same function keys for the same actions in the legacy system as the new UI, making them accelerators to the corresponding menu items. Keep those arcane codes for those fields values –just make them prefixes to the fully-spelled out field values in your combo boxes, so new users can see the whole value, but experts can still select their intended values by typing the code (assuming your combo box supports auto-complete).
Generally, seeking legacy consistency should not be done at the price of forgoing improvements in either efficiency or learnability. After all, the legacy experts might be close to moving on anyway, but new users will likely be coming on board for a long time to come. Sometimes the design can accommodate both new and expert users with virtually no cost. For example, Saving a record can have both Ctrl+S as an accelerator (for your new users who have some platform expertise) and F2 (for your venerable legacy experts). If you have to, you can design in an “old-timers” mode for these experts that can be set in the preferences. This way, the legacy experts can have F10 to open a query dialog and slash accesses the menu, just in like the old system, while your new users can have the more conventional or platform-standard key bindings. At the very least, you could provide brief documentation on the key differences between the legacy and new system for migrating users.
Domain Experts
Domain or subject-matter experts know the business process your software is intended to support. With the exception of the casual user of simple utilities (e.g., to set up a home network), your users are nearly always domain experts. They may not know your software, but they know a lot about inventory control, or running a water treatment plant, or building a shipping schedule. They do it 40 hours per week. Even for apps outside the business world, your users often have a high level of expertise. Users of photo-management software know about photography. Users of word processors know a lot about writing (generally having at least 12 years of formal training in it). Heck, users of an ecommerce site for clothes know lots about clothes. Whatever the domain, all domain experts are best served by you making the UI about the domain and not about computers. This is basic usability engineering, where you study the task, to determine what information the users need, how they use the information, and what goals they are seeking to achieve by such use. Then it is merely a matter of designing the UI to best support all that.
However, among your domain experts, there are those with exceptional expertise, the ones who know truly arcane details about the business process, who see larger patterns and purposes in the work, who can see problems and solutions in daily work long before anyone else. You know when you found one these when you do your initial interviews of the customers and users. You go to one of them to verify one simple little business rule only to find, after 45 minutes of explanation, that it’s not really quite that simple.
These domain super-experts are served well by the same things that serve task experts. They know exactly what they want to do and how to do it, and the most important thing is keep the software from getting in the way of them doing their job.
The difference between such a domain super-expert and an ordinary task expert is clear once they get away from the typical tasks and standard procedures and confront something truly exceptional. The domain super-expert will gather data, formulate a plan, and execute it. The task expert asks the domain super-expert for help.
A domain super-expert knows way more than you do about the domain, and scheduling a few more days of interviews is not going to change that. Short of working in the business yourself for 20 years, they are going to know exceptions and contingencies to the business rules that you are just not going to know about. You can design a UI optimized for the normal everyday work with a relatively small amount of research, but it is not practical to try to catalog every possible event and design the UI to handle it. Not going to happen. Forget it. Even the domain super-expert couldn’t provide such a catalog. The world is a messy place, and they very well may be confronted with a situation they would never have anticipated. However, they have such depth of knowledge that they’d still be able to figure out what’s happening and what needs to be done.
Designing a UI to support these users means designing for creativity. You can’t anticipate every way your software may need to be used, but you can provide basic tools in the UI that may be creatively assembled to address these complicated and unpredictable exceptions.
Supporting creativity is best achieved with an object-centered UI structure, where each primary window presents certain classes of data objects. As described for task experts, the most common tasks are usually achieved by manipulating the attributes of these objects with controls and other interface elements within the primary window. However, for your domain super-experts, the periphery includes menus and other controls for general fundamental data manipulation. It’s okay or even preferred if these functions are on the periphery of the UI because they will be rarely used (so you probably don’t want them getting in the way) and, given that their misuse might result in a lot of damage, they probably should be insulated from the more typical user.
These controls should allow your super-experts to perform on any object shown on the screen the basic object manipulation tasks: create, associate, copy, convert, remove, sort, search (or sub-query). You should support multiple ways of adjusting the presentation of data so your super-expert can study the problem. Allow multiple windows, multiple simultaneous views, resizable panes, and split bars. With these building blocks, experts can string together a set of commands to accomplish things you never thought they’d need to do. This is the true spirit of the airliner flight deck, where the user has the ability to do any action anytime to anything.
These peripheral commands should be powerful, making it possible to do a lot with a little. Searches and ad hoc querying should allow complex Boolean logic to filter objects. Don’t make users execute the same command separately for each data object. Allow users to multiply select data objects then execute a single action (such as move) on all of them at once. Complex series of commands may be needed more than once, perhaps with some slight modification next time. Allow users to save, retrieve, and edit their ad hoc query instructions, data presentation set-up, and report definitions. Perhaps provide a macro recording or scripting feature.
Provide overrides. Consider that you don’t want the software to enforce all business policies, because some day your user may need to go against them (perhaps the very same user who told you about the policy in first place). Is it really necessary to prevent users from entering a transaction date earlier than today? Maybe instead of the validation logic prohibiting such an entry, it may simply warn the user (in the likely event it was a typo). Use a spinner control to encourage entry of “round lots” of an even 100, but still allow the user to enter any value, perhaps even a fractional value. Provide a way to turn off the usual protections (perhaps under Preferences or Options), at least for users at the rank of your domain super-expert.
Computer Experts
These are experts on the technical details of computers. They may or may not be familiar with the platform UI conventions, but they wrote their own compiler in college or built their own router in their basement. Not much you need to do for these guys, because the ideal UI is independent of the underlying technical implementation. Does your app run from object code or through a virtual machine? What protocol is use to communicate with the server? It really shouldn’t make a difference. A UI should be designed so that the user does not need to know such details to use the app. As a corollary, knowing such details doesn’t help much.
Such users probably want a lot of customization, which may or may not be a good idea to give them –do you really want them replacing the table indexes with their own? You can use terms like “dialog box” or “database” or “callback,” in the documentation, but probably shouldn’t unless it really clarifies things for those users. That’s about it.
Summary Checklist
Problem: What should a UI include to support expert users?
Potential Solutions:
Tasks Experts
- Support shortcuts such as accelerators, toolbars, drag-and-drop, context menus, and double-clicking.
- Minimize navigation and maximize awareness by designing a few large complex windows, rather than many small simple windows.
- Minimize text and labels in each window.
- Proportional design: easy to access commonly needed things, harder to access rarely needed things.
- Internal consistency.
Platform Experts
- External consistency. Follow platform standards and conventions.
- Support usual GUI capabilities, such as multi-tasking, and maximizing, minimizing, and resizing windows.
- Avoid inventing new controls.
- Provide Help.
Legacy Experts
- Design for user performance superior to the legacy system.
- Provide equivalents of time-saving features of the legacy system.
- Remove inefficiencies carried over from the legacy system.
- Legacy consistency, where possible. Consider “legacy mode” or help for migrating users.
Domain Experts
- Use an object-centered UI structure.
- Provide use-for-anything general-purpose commands on the periphery.
- Make these commands potentially powerful (e.g., by supporting multiple selection, scripting, and saving).
- Provide overrides, such as by using sanity checks rather than hard validation.