In today’s lesson we’ll take a look at paths, and learn how we can improve our application UI paths so customers can more efficiently travel where they want to go (through your interfaces).
Paths describe the physical and mental effort a user must exert to accomplish a task in a user interface.
First, let’s compare two interfaces that get paths wrong (in two very different extremes).
The first, the phone call interface from a popular smart phone:
And the second, the Anchor property editor from a popular developer tool:
Before I dive into the issues with these two user interfaces, lets get a quick introduction to paths.
Paths are the sequence of steps people take as they accomplish tasks of interest.
Path steps have three properties: width, length (or time), and force (or steepness/strain).
Width reflects how easy or challenging the step is. Narrow paths require too much precision, and are prone to errors.
Length reflects how many tasks must be performed, or how long it takes to complete the step.
Force is the amount of effort required to perform an action. Here’s an example of a ridiculous user interface that requires the hands and arm to be held in a static position for the entire duration of your phone call:
So the force and strain for using this interface is unnecessarily excessive.
These three properties of a step, width, length, and force, are a measure of task complexity across three dimensions: precision (cognitive load), duration, and strain. For the best UI, we want to minimize all three of these properties.
The two examples from the start of this post focus on one of these properties: width. Width refers to how easy or how difficult the task is, and is often a reflection of the physical size of the interface element we need to interact with. The smaller the size (the narrower the path), the greater the precision required for interaction (and the higher the cognitive load). The larger the element (the wider the path), the easier it is to hit (with a lower cognitive load).
Of course, when traveling down any path, there are two categories of unintended actions that can occur. You can have unintended misses (because the target was too narrow), and unintended hits (for example, where a button you didn’t mean to press was hit because it was too wide).
These two possibilities are represented in this chart:
There is a theoretical sweet spot near the middle, where the path is sufficiently wide to allow for easy or even error-tolerant travel, yet not so wide as to result in unintended travel.
The importance of avoiding unintended traversal and misses, matches the severity of the consequences of that unintended action. For example, in the case of the smart phone’s “End Call” button, the consequence, the premature ending of that phone call, might be pretty severe in some cases. For example, if severe weather closes airports and you suddenly need to re-book a flight at the last minute, the phone line queues (to reach an airline representative on the phone) might be long. After waiting on hold for 15 minutes, unintentionally hitting that large End call button could be pretty painful (I know – it happened to me).
Years later the phone vendor updated their UI, correcting the overly wide path:
Which brings us to our second path problem, the Anchor property editor:
This property editor allows you to select which sides of a control will be anchored to the parent container. There are four sides, and any combination of these can be anchored. The problem is that the four buttons used to set these anchors are each 28 pixels long, by 10 pixels wide.
These buttons are really small. They form an unusually narrow path, especially in light of expected frequency of use (users will very likely hit one or more of these buttons when this UI is shown). On the surface, the consequences for an unintended miss appear to be low – you simply re-target the mouse and click again. But there’s another consequence to narrow path and that is higher cognitive load. When humans need to accomplish tasks that require a high degree of precision, our cognitive load goes up. If this happens while using software, we get pulled off task. Interrupted. Now, instead of trying to set the anchors, we’re trying to wrestle with the user interface. This is entirely wrong.
Going back to the unintended traversal/miss chart I showed earlier, I place these two paths (too narrow, and too wide) here:
By the way, if you purchase the Science of Great UI design course you’ll learn five strategies for widening the path and six strategies for shortening the path, and how to design interfaces that minimize unintended traversals. You’ll also get access to my Science of Great UI Case Studies mini e-book, which contains my redesign for the Anchor property editor shown above (fixing not only the width problem but also a few length problems as well), and you’ll also get to see my thoughts on this interesting user interface below: