Illustration by Jon Walter

Are You Leaking Usability? 2 Formulas to Avoid

Efficient. Effective. Satisfying.

The term “usability” might be defined differently depending on your source or whom you ask, but those three words tend to creep into most definitions in some way or another. Even if not explicitly written, they’re implied. But do you know what word isn’t likely to be found in any definition? “Friction.” That is, unless friction is stated in the negative, since friction is basically defined as resistance.

Nobody wants friction. Yet so many software applications are saddled with it. This leads to usability leaks, which ultimately hinder a user’s productivity. The root causes could be many, some of them being fairly obvious — like making an important call-to-action hard to find, or designing a workflow that strands users. Yet there are a couple of less obvious causes of friction that create leaky usability. How do I know this? I’ve been guilty of introducing these causes of friction without even realizing it. In fact, I think many other unwitting user experience practitioners have as well, since they can be fairly subtle. But they are also avoidable—and to understand how to avoid them, it helps to clearly define them. As such, here are two common, but subtle formulas that cause friction:

Look and Feel = Usability

and

My Way > Current User Knowledge

Look and Feel = Usability

We’re enamored with aesthetics, and at times, it seems as if look and feel is the horse pulling the usability cart. I’m not knocking look and feel. Users of your product will inherently trust it more if the look and feel is clean and aesthetically pleasing, thus suggesting high quality. It’s known that attention to a strong look and feel helps build affinity with your users, and it should absolutely be evident in your product. But not at the expense of usability.

Friction can occur when over-emphasis on aesthetics gets in the way of usability. After all, it’s not just about how it looks and feels. Steve Jobs summed it up fairly well:

“Design is not just what it looks like and feels like. Design is how it works.”

Does Your Design Solution Work?

Focusing too much on look and feel can inadvertently impact how something works. And at times, it can actually do harm to usability. Let’s say for example, you think certain native operating system or browser components are visually subpar for your user interface — and thus it makes sense to create your own custom versions that are more conducive to your desired look and feel. That could be a noble cause, so let’s pick on native check boxes for a moment. Go ahead and replace the native check box component of your target operating system(s) or browser(s) with your own custom version. The look and feel might have changed, but does it still work? Consider:

• Will the check box scale appropriately?
• If you have a web application delivered via a browser, what happens if you drastically reduce the size of the browser window — does the hit zone of the check box still feel adequate (will the checkmark icon respond as well)?
• Is it accessible for a screen reader?
• Can a user visually give the check box focus by tabbing to it, if using a keyboard?
• Does it work flawlessly across all major browsers and versions (if browser-based)?
• Most importantly, does it intuitively work in a way a user will expect?

While most native components could certainly benefit from some visual panache, they typically perform well, are bug-free, and will stay up-to-date with each OS or browser version update. Sounds like a pretty good user experience to me. Is your customization worth possibly risking some of these benefits?

Don’t get me wrong, this isn’t to say all customizations are evil. Nor are they all created equal. The bigger the change, the bigger the usability leak you risk, and this includes how a user expects something to work. As indicated with the dropdown examples in Figure 1, incremental changes that allow a component to look and feel in better alignment with the rest of an interface are probably okay in most cases… so long as they do not muck with how the component works.

As illustrated in Figure 1, the “MIGHT BE OK” custom example shows obvious changes, but it still maintains the same content arrangement of the Native example (text label and down-caret are in familiar spots). A user should still expect it to work like a native dropdown. However, the “DEFINITELY NOT OK” example completely rearranges the label and the down-caret. While I know this an extreme case, this change causes major friction since it literally modifies the component for the user — to the point where they may not expect it to work like a dropdown.

Figure 1: The“DEFINITELY NOT OK” version moves the down-caret to the left of the input. This could completely change a user’s expectations for how the component works. The “MIGHT BE OK” version features an incremental visual change.

Are You Even Using the Right Thing?

Making reasonable customizations to the look and feel of the correct component is one thing. But choosing to use an incorrect component solely based on its looks and not its intended use is another. For example, let’s look at an oft-confused neighbor of the check box, the radio button (Figure 2). It’s intended to indicate selection of mutually exclusive choices in a list — there can only be one choice selected at a single time. It’s not a checkbox, which is intended to allow any number of choices being selected at a single time. Yet these two components are constantly being misused, since well-intentioned folks simply choose the component they think looks the best without understanding its true intended use. This does happen.

Figure 2. When a user can choose multiple items at the same time (like a food order), a list with checkboxes makes sense. But you could always force them to order food items a la carte by using radio buttons. NO BACON FOR YOU!

If you’re like me, your mind probably doesn’t conjure up check boxes and radio buttons when pondering aesthetic choices. But focusing too much on appearance and not enough on intended use (and how it works) can cause major usability leaks — even when dealing with seemingly pedestrian components.

Key Takeaway

Just because you can visually change something, it doesn’t mean you should — especially if the change extends to how it works or is expected to work. These After all, depending on the magnitude of your change, not only will you pass friction directly on to the user, you could add to your own development debt and maintenance over time, since your customization might not gracefully update with newer OS or browser versions. At the end of the day, you’re not your user and it’s about how it intuitively works, not just about how it looks and feels.

My Way > Current User Knowledge

As the formula suggests, sometimes we think our way is greater — or better, than what users currently know. But we need a reality check. Unless you’re Apple or some other sovereign influencer of patterns, your software product is probably a small player in the grand scheme of your users’ daily workflow. Users are constantly being exposed to patterns, many of which they reflexively recognize, since they’ve become normalized over time. The current knowledge someone brings to your application plays a crucial role in how they assume things will work. Like it or not, it’s baggage — and you’re not immune to it. How so?

Equity

Take for instance the “Save” icon, which is usually represented as a floppy disk in many software applications (Figure 3). Think about it: save is being represented in modern software with an object so obsolete, many millennials have never seen it in use. The irony shouldn’t be lost on you. Not only is it antiquated, it isn’t the most equitable shape, especially when compared to the minimalistic look and feel of other modern icons.

Figure 3. “Who you calling antiquated? I’m Floppy Disk Save icon, and I’ll NEVER die. I’ll haunt your dreams…FOREVER.”

The solution many well-intentioned folks arrive at? “Screw it. I’ll use a checkmark icon to represent ‘Save’ or I’ll just create my own.” But the problem with deciding to create your own icon—or repurposing a different icon that doesn’t truly possess the same meaning, is that it ignores current user knowledge. It introduces friction since a user may not understand the operation you’re trying to represent. And now your experience isn’t efficient, probably not effective, and definitely not satisfying. A usability leak.

The floppy disk save icon lives on since it benefits from current user knowledge. And you can benefit from it. Like it or not, it has equity since it somehow gained traction in the past. Users have been routinely exposed to it for many years, despite the actual floppy disk being older than dirt. Now this isn’t to say you should stagnate and not look for ways to innovate or find other approaches — especially if your product has a unique need. But it is to say, if something has been around long enough, it shouldn’t be thrown out frivolously.

Location, Location, Location

For you iPhone users, you may or may not have noticed a significant change to the native photo app with the iOS 10 version update. Take a look at figure 4 which shows a comparison of the individual photo view before iOS 10 (at left) and then the individual photo view with iOS 10 (at right). What do you see? Hint: it’s not the flowers in the left view and the jack-o-lanterns in the right view. Notice how iOS 10 not only changed the visual representation of some of the actions, but also where they’re located.

Figure 4. Comparison of the photos app before iOS 10 (left) and with iOS 10 (right)

The change is probably inspired by the introduction of some new actions associated with the photo view: “Favorite,” (heart icon) in the fixed action bar at the bottom, and “Details,” located at the upper right. But did you notice how much “Edit” has changed from one version to the next? And did you also notice it’s now represented by the “Horizontal Sliders” icon to the left of the “Delete” icon (trash can)? Congratulations if you got this right away. But maybe you didn’t. Maybe you’re like many folks who were confused by this change. Not only is this a big change for how Edit is represented (now as a label-less icon instead of the previous verb text), it’s a drastic change to its location. It used to be a world away — on the upper right, and now it’s in the fixed action bar at the bottom. This drastic change in location is the biggest cause of friction here, which is going to affect a user’s ability to efficiently use this application, especially if they’re not prepared for it.

Location is critical because users develop muscle memory over time. It becomes second nature to reach for a familiar spot — which is especially important on a smartphone, since it’s usually a context in which folks are engaged with just one thumb and one eyeball at a time. When they can’t find these familiar spots immediately, they become frustrated. Perhaps Apple felt the drastic change in location of certain actions was offset by the benefits of squeezing in new features like details and favorite. And after all, they’ve put Edit in closer reach of the user’s thumbs with the change. A noble cause, and probably something users will learn fairly quickly. However, they could’ve labeled the icons across the bottom to reduce ambiguity. In subsequent version updates, they could’ve phased out the labels once users had enough run-time with the changes.

Sounds utopian right? In reality, Apple isn’t going to do that, because they don’t need to. They can absorb minor usability leaks and know their captive user base will tolerate them given it’s such a pain for users to completely switch operating systems. They won’t lose users over this. But you and I aren’t Apple, and likely won’t reap the benefits of captive user tolerance in this way.

To be fair, I’d argue Apple’s iOS 10 design is better. They’ve placed an important action in closer reach to a user’s thumbs on a smartphone. There’s a future-proofing benefit as well, since edit being represented by the horizontal slider icon is probably here to stay (hopefully). Suffering design choices of the past — like continuing to keep “Edit” on the upper right side simply because “that’s the way it’s always been done,” isn’t the point here. It’s to make location changes with caution and with good reason. Many times they are well-reasoned and necessary, especially if influenced by user feedback. But the more drastic and sudden the changes are, the bigger the usability leak you risk; especially if the decision wasn’t carefully calculated.

Usage Patterns

While ignoring equity and the value of location are decisions that can negate current user knowledge, there are certainly others. What about ignoring usage patterns? There are immutable truths that accompany recognizable components—users anticipate them working a certain way. Yet, these established patterns are often misused.

Take this example of a product configuration page from Amazon’s website when viewed on a smartphone (Figure 5). You may think I’m going to quibble over the right-aligned radio buttons. Sure, the location of these buttons is a little unexpected since users are familiar with them being aligned to the left of the text of each list item. And I did just finish ranting about location. But this isn’t all that drastic, and there could be a very good reason for them being slightly different. I’d surmise Amazon consciously made this decision in an effort to place the radio buttons within easier reach of the user’s right thumb, while not obscuring the left-aligned list text. There’s a heck of a lot of right-handed users out there, so it’s arguably a noble cause.

Figure 5. There’s more to those radio buttons than meets the eye with Amazon’s product configuration workflow.

But wait a second. What’s missing on this screen? Something pretty significant, actually. Radio buttons are intended only to indicate selection in a settings or configuration context. Where’s the command button? A command button (“Ok,” “Apply, or “Submit,” etc.) should be present so a user can capture their choices and then exit the view. Amazon is overloading the intended use of radio buttons by making them serve duel operations.

How so? Not only are the radio buttons indicating selection of the desired configuration (correct), they’re actually being used as navigation, exiting the view as soon as the user makes a selection (incorrect). This is jarring, since radio buttons aren’t intended to be used as actions, and thus the usage pattern of a radio button is being misused. Adding to the friction of this experience is the fact that the configuration step takes over the entire viewable area of the screen. Even though there’s a “Back” button available, it feels like another page — as if the user has been taken somewhere else entirely.

So what’s the big deal? Some may argue Amazon ignoring the proper usage pattern of radio buttons is harmless. Like Apple, they’ll absorb the usability leak without missing a beat. In fact, some may see their use of radio buttons (select + navigation) as accelerators, since they cut out the command step and get the user through the purchasing workflow quicker. However, their misuse of a well-established usage pattern ignores current user knowledge and adds unneeded friction to the experience. This affects efficiency.

When something doesn’t work or behave as expected, a user may think they made a mistake. In fact, I did, when first interacting with this workflow. I had to perform the configuration step a couple of times to really understand what had happened. It didn’t accelerate my progress. It actually slowed it down, since it trashed my current knowledge of how a radio button is supposed to work. And now, with subsequent interactions with Amazon’s purchasing workflow, I might stop and think when I see another radio button. A usability leak.

While Amazon is bending an existing usage pattern to its will, I’ll go as far as saying the Yahoo! Fantasy Football iOS application (Figure 6) has a more intuitive usage pattern for configuration. Even though it deals with “moving” players, the basic intent isn’t all that different from Amazon’s pattern — you’re just configuring a roster spot instead of a product.

Figure 6. Yahoo!’s Fantasy Football iOS application makes configuring a roster fairly intuitive.

Not only does this workflow not bastardize an existing established pattern for using radio buttons (which necessitates a command button), it feels transient since it doesn’t take over the screen’s entire viewable area. Notice how the modal dialog window occupies only a portion of the viewable area and shrouds the primary interface with a semi-transparent overlay. This well-established usage pattern helps reinforce the transient nature of the workflow, whereas Amazon’s is jarring, since configuration feels like navigating to a completely different page.

In the Yahoo! example, a user can simply select the left-aligned circle button (“RB,” “BN,” etc.) in the list row for the player they wish to use to replace the current starting player (top row), and the selection is made immediately. Furthermore, it’s satisfyingly reinforced with a subtle animation that shows the chosen player row moving to replace the current player row. The modal dialog promptly goes away without additional action needed from the user.

Unlike Amazon’s configuration workflow, a dual operation for selection is tolerable in Yahoo!’s case, since it doesn’t evoke the wrong usage pattern. A user simply chooses to edit their roster, a transient dialog pops up, they make their change, and the dialog goes away. Highly efficient, effective — and thus satisfying.

Key Takeaway

Amazon can absorb their configuration usability leak… because, well, they can. But this isn’t the same reality for most of us who design software applications. Little friction points can add up to bigger-than-expected leaks. So use the most suitable usage pattern for the job, and don’t bend the wrong pattern to your will.

As with the case of the floppy disk save icon, built-in equity is a critical aspect of current user knowledge. But the friction you introduce isn’t necessarily dictated by external forces. As with the example from Apple, if key interactions have been discoverable in certain locations within your application for enough time, they begin to influence muscle memory in users. Make well-reasoned changes with caution, and do so incrementally if you can. And of course, have users test them in advance.

Current user knowledge should be your friend. Don’t be ashamed to wield it to your full advantage.

Formulas to Abide By

The notion that look and feel is equal to usability gets you into trouble since it can negatively impact how something intuitively works. Belief that your way is somehow better than current user knowledge not only passes friction directly onto the user, it creates unneeded churn for you — in the form of costly development and maintenance of your product.

Alas, I didn’t want this entire article to be about what not to do, so here are two positive formulas to consider:

Look and Feel + N = Usability

A strong Look and feel builds confidence in users by suggesting quality and care in a product. It’s absolutely important — but it’s just one aspect of great usability. Don’t forget other crucial aspects, all of which should be informed by qualitative and quantitative user research:

• Discoverable and intuitive interactions
• Exceptional performance in all target environments
• Logical information architecture and navigation
• Graceful handling of errors and mistakes

This list is hardly exhaustive. Everything that feeds into great usability can go to the nth degree, which is why the formula includes “+ N.” But at the very least, be humble enough to know you’re not the user, and even well-intentioned visual changes may bring about points of friction you may not have anticipated.

Current Knowledge = Power

As user experience practitioners, we’re in the business of removing boulders for the user. The more granular obstacles shouldn’t be ignored, but they’re usually the ones that can benefit from current user knowledge the most. In fact, they may end up seeming less like obstacles and more like stepping stones for success since they can take advantage of what the user already knows and recognizes. View current knowledge and all that it encompasses (equity, location, patterns, etc.) as a shortcut. It can help you reduce friction and make your overall experience more efficient, effective, and satisfying.

Bottom Line

Our skills are in high demand, especially with how commoditized design has become, where anyone who gets their hands on Twitter Bootstrap or the Font Awesome icon library suddenly thinks they’re a designer. Unfortunately, there’s no formula that magically whips up a highly usable experience that’s efficient, effective, and satisfying. It takes hard work by someone who’s devoted to it — and who takes user feedback seriously. But as user experience practitioners, we should know that an airtight experience starts with sometimes getting out of our own way, resisting the urge to change things that may just end up causing usability leaks.

These formulas are just a couple of the ones I’ve encountered and I’m sure there are many more. What formulas are you aware of that create usability leaks? I’d love to hear your thoughts.