According to usability industry leader Jakob Nielsen, usability failures in software and apps are usually because the software:
- solves the wrong problem.
- has the wrong functions for the right problem.
- makes the right functions too complicated to understand.
Nielsen’s last point reminds me of what a product manager once told me: many users of highly specialised software think of themselves as experts, but only few of them actually are. He believed elaborate sets of functions are too numerous or complex to learn fully. As user researchers and interface designers we can help solve that.
More than users could chew
One of my projects involved software for dieticians and nutritionists. The software allowed these professionals to enter a recipe. The software would then calculate the nutritive value per portion. The dieticians and nutritionists, who described themselves as experts in their field, learned only the basic settings needed to get an adequate result. They ignored the extra functions that factored in various complex chemical interactions between the recipe ingredients to get a more precise result. In research sessions, some users described the extra functions as “clutter” and “unnecessary”. I hypothesized that the constant presence of the extra functions in the user interface made the main screen too complex. “It seems hard to learn” confessed one of the nutritionists. During my initial usability test sessions, some dieticians and nutritionists avoided or dismissed the extra functions, with some saying: “I don’t need that.”
When the product was developed, each extra function seemed a good idea to the sales team. Individually, the extra functions may each have made it easier to sell the software to the healthcare managers who bought the software for their teams to use. But, good idea or not, user research with customers who used the software revealed that those extra functions made it harder to learn and use the full product. The extra functions had to be either removed, hidden from the majority of users, or redesigned.
Resolving an “extra functions” problem
Software functions typically have some (or many) controls that let people use it—controls such as text boxes, lists of choices, toggles, buttons, sliders, and more. The more controls a function has, the more complex its interface.
There are prescriptions to help interface designers make a complex, hard-to-learn and hard-to-use product easier. Here are several.
- If the extra functions are superfluous, remove them. Usage data and logs can help identify seldom-used functions. Especially cloud services (SaaS, or software as a service) are capable of collecting usage data. This reveals which functions are used seldomly or used by few people. However, removing a seldom-used part of an existing function is a complex decision, and one for the Product Manager to make. The difficulty lies in determining whether a function would be used more if it were simpler to use. In that case, it may not be superfluous.
- If the data shows the extra functions are used only seldomly by relatively few users, then hide them deeper in the user interface. The suggested treatment in the user interface for seldom-by-few controls is to expose them only in the context of a related task. It may take many taps or clicks to navigate to these controls. Do not clutter the main screen with controls for seldom-by-few tasks. Hiding the controls for an seldom-by-few task is supported by the Isaacs-Walendowski frequency-commonality grid:
- If the extra function is to be a core function, but the data shows it’s not well used, then simplify it. I’m talking about a function that the Product Manager, supported by user research and market research, believes would be used often or by many if users could figure it out. Hiding such functions down a long path of taps or clicks isn’t the answer. It should take at most a few taps or clicks to navigate to these controls. You need to find ways to reduce complexity by designing well. This is not a task for novice designers. You’ll need these skills:
- interaction design—to choose the right controls.
- information design—to choose the right formatting and layout.
- information architecture—to choose the right organisation and navigation, or labelling and click path.
| Function is used | by many | by few |
| often | Make it: • Visible. • No taps. |
Make it: • Suggested. • Few taps. |
| seldom | Make it: • Suggested. • More taps. |
Make it: • Hidden. • Many taps. |
How do you decide which functions are superfluous (the functions to omit), which are seldom-by-few (the functions to hide), and which are anticipated to be used often or by many users (the functions on which to focus your biggest design effort)?
Nielsen recommends basing your decisions on user research, by testing early designs with users. He says: “People don’t want to hear me say that they need to test their user interface. And they definitely don’t want to hear that they have to actually move their precious butts to watch real people do the work the application is supposed to support. The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.” Source.
Making a bite size interface
After considering the Isaacs-Walendowsky grid, my project’s team decided to initially hide and then progressively disclose the extra functions as the dieticians and nutritionists step through entering a recipe. Follow-up testing with customers showed that the dieticians and nutritionists could discover, understand and use the extra functions when these appeared in the right context. One nutritionist said: “I’ve been waiting for you to provide this” [software function], adding: “It’s essential because it lets me do my job well.” Ironically, the function had always been there, but in a different location, where all it did was add “clutter”.