UX Smells
Design better products by knowing the signs of bad UX
After I got past the “how do I get this to compile” stage of software development and started to actually build real products, one of the most useful static references I encountered was Jeff Atwood’s list of code smells — a list of the little things that pop up on the surface of codebases often indicating broader architectural problems. Code smells are great because once you learn to recognize them, you can save a ton of time by quickly refactoring code before the faulty architecture becomes too entrenched and a massive effort is required to do anything about it.
As I became more experienced in product design and made lots of UX mistakes in the process, I came to realize that the same concept can be applied to designing interfaces. Some product and UI features should almost never be used in well-designed products. Seeing them, or implementing them, should be a warning that deeper problems exist in the product’s user experience. And by learning to recognize them, you will be able to build better products that are less costly to implement.
Here are the top three that I’ve come to appreciate for being common, immediately remediable, and non-obvious:
1. Documentation for “power users”
Teams have come up with many different ways of implementing “power user” documentation in apps of varying complexity. Here are a few examples:
- Separate documentation portals with “FAQs” and user guides (i.e., the Microsoft help page for Excel above)
- Community driven support portals that organically emerge to help users use your product (i.e., the large number of online forums like TuxRadar above dedicated to helping users use the shell language Bash)
- Tips and guides interfaces built in to existing software (i.e., the Tips app that Apple introduced in June 2014 with iOS 8)
- Tour features that introduce your interface as part of an on-boarding process for new users (i.e., using projects like Bootstrap Tour)
WHAT IT CAN BE A WARNING OF
These strategies are all different ways of guiding users through an interface. Why is that bad? The best interfaces don’t need guides—they’re obvious.
When users ask you to build guides for your product, they mean that your product is HARD TO USE, for them.
WHAT YOU CAN DO ABOUT IT
In my own experience designing and maintaining products, struggling with interfaces generally falls into one of three categories:
- The UI is designed using non-standard idioms for the platform. This especially common among apps with “universal” interfaces that look similar on different platforms, or in products with too-creative of designers who spend time customizing core UX/UI elements that should be platform-specific rather than product-specific. (Look for this in everything from icons to content navigation.) Once you’ve identified this problem, the solution is generally obvious: use platform-specific components and flows that your users will be able to understand without needing to read a guide. I promise you that users and the guys looking at your KPIs will both be much happier.
- The product is being used by many different kinds of users, for many different purposes. Excel is like this: everyone from financial analysts to personal users to statisticians to product managers use some subset of Excel’s features to track data, but each group uses a different subset. Because there are so many different use cases, the interface is not optimized for any single one, and thus confusing for everyone. To fix this, if at all possible, break your product into separate products focused on specific user groups. (To prioritize, pick the one or two most important markets for both current and future growth.) By focusing, you’ll be able to make your interface simpler, your roadmap more focused, and everyone will be happier.
- The interface isn’t structured in a discoverable way. Often this stems from navigation that either has isn’t visible or gives the user too many options without providing a reasonable, simpler structure. To fix this, provide easy-to-use navigation based and structured on real usage behavior—navigation that doesn’t need documentation to navigate.
Of course, it may be true that your product is doing something complex and entirely novel and genuinely requires a complex, novel interface. While this is very rare, if this is really the case, then you need to build the most intuitive interface possible and may still have to rely on some guides.
2. Hard-to-implement layouts
In projects that I’ve been personally involved in, there have been a couple of common hard-to-implement layouts when it comes to actually building the interface:
- Scroll-specific content on websites. Sometimes it seems like a good idea to have, for example, a sidebar that changes its content depending on where in the page the user has scrolled to.
- Complex, layered navigation. Sometimes it seems like applications need to have a lot of custom navigation logic for dealing with transitions between and within views.
- Complex, non-standard animations. Most UI platforms have a standard set of animations that are used throughout—sometimes it seems like a good idea to make your own.
In general, though, think about this whenever a substantial programming effort needed just to create the layout and standard UI components (rather than the product’s value-adding core interface).
WHAT IT CAN BE A WARNING OF
A hard-to-implement layout is generally going against the grain of the platform’s UI/UX conventions and thus is probably going to confuse users. Plus, it’s often going to break in unexpected ways. The platform’s built-in layouts and idioms have been tested to work in non-obvious and weird screen orientations, content widths, devices, and more—can you really afford to spend that much time testing and adjusting non-essential application components?
This problem is especially common with ported or cross-device layouts like WebView-based mobile apps, but the instinct is easy to find everywhere.
WHAT YOU CAN DO ABOUT IT
Whenever possible, use platform-specific, standard UI/UX components. If they don’t quite fit your brand, customize them slightly — but customize, don’t re-invent. And if they don’t fit your design, 0r “aren’t as good” as what you’ve created—well, think long and hard from your users’ perspectives about how true that really is.
3. Excessive Iconography
Quick, what do I do to count how many words I have in the document?
I use the app pretty regularly, and I have absolutely no idea. Here is the ribbon with the (to be fair to the Office team, included by default) labels under the icons:
WHAT IT CAN BE A WARNING OF
But, wait. If the icons are largely meaningless without labels, why are they included in the first place? Here’s a hint:
Look at that UI mess! There are so many different features that they had to make the font small just to show them all!
Icons, especially in main navigation menus, can often be a way of using UI to make poorly structured UX look more appealing. The core problem with this menu in Word is not that the icons are hard to understand—it’s that there are too many different functions being exposed to the user at any given time.
Here’s another example:
Xcode is exposing lots of highly complex functionality to the user—and even though the actual user experience is unstructured and thus difficult to use, it looks more appealing because of the UI iconography. Imagine what that interface would look like if every icon was replaced with an equally small text label.
WHAT YOU CAN DO ABOUT IT
Simplify your product by structuring core activities into sets of interactions that are small enough to comfortably display using text-based operations. Often, this means thinking deeply about how users use your product and crafting the navigation-layer of your interface so that different use-cases are properly structured. Sometimes this means splitting off parts of your product into entirely new products. There aren’t hard-and-fast guidelines here, but you’ll know when it finally feels right.
As with code smells, there are always exceptions to the rule. But if you learn to weed out documentation, tough-to-implement layouts, and excessive iconography from your designs, almost always your products will be significantly better for everyone.
Aaron Yodaiken is currently a John Jay Scholar of Economics at Columbia. He previously founded Upward and RealityStep, worked at Earlybird VC in Berlin, and volunteered with Battleground Texas.
