This is an excerpt from the Eliminate UX Debt ebook, written by Jack Moffett, and originally published on UXPin.com.
A Few Quick Words
When Adobe wanted to expand beyond photo editing and join the page layout market in 1994, it acquired the company Aldus and its product, Pagemaker. They repeated this strategy in 2005, acquiring Macromedia and its numerous software applications — including Flash, which had become a very successful web platform.
They were following a tried-and-true method for increasing a company’s value, but think about the product consequences. All of a sudden, Adobe had several products designed and built by others, all following different visions, different aesthetics, and different behavioral philosophies. When a new product is suddenly dropped into a team’s collective lap, it doesn’t take long to uncover residual issues with the product.
Whether it’s a poorly-worded confirmation message that slips out the door or strange behavior that fell through the cracks, it’s really easy for issues to slide by unnoticed. Before long, a product or three falls short of intended standards and develops an ever-growing list of “We’ll get to it eventually” problems.
In other words, UX debt.
More than likely, your UX team is already tracking and fixing scattered issues in your own products, as well as those that suddenly became your team’s responsibility due to acquisitions or outsourcing.
Fixing UX debt becomes considerably more complicated — and more critical — within a large company developing an array of products. You know this all too well.
Whether you’re part of an established team that is seeing renewed interest in your capabilities, a new team that’s been recently assembled to catch the UX wave, or a UX team of one, I’m sure you have a pile of debt to deal with.
I’m here to help you identify your debt, classify it for prioritization, and ultimately eliminate it. Even better, once you recognize the sources, you can prevent debt accumulation in the future.
Classifying UX Debt: An Overview
First, let’s define UX debt.
UX debt is an accumulation of design and development decisions that negatively impact the users of a product or service.
All UX debt is either intentional or unintentional. We should seek to minimize the intentional debt, while proactively avoiding the unintentional debt.
Reasons for intentional debt include:
- Time to market — A company might release a product with design debt to meet strategic timelines. For example, Series B startup might release an imperfect mobile app to better position themselves for a faster Series C investment.
- Focus on new features — A company may decide a “critical mass” release of robust features for a new product is required to gain market share. The team will then schedule design debt cleanup for later sprints.
Reasons for unintentional debt include:
- Separation of design and development — When UX is treated as an island, design debt is inevitable.
- Design by committee — When design leadership needs to satisfy everyone’s requests, the product becomes convoluted. The inconsistency creates UX debt.
- Lack of access to end-users — If the product team can’t test concepts with end-users, the design is educated guesswork at best.
Regardless of the reason, unaddressed UX debt will eventually lead to products that are so painful to use that customers seek out competitors. UX debt is particularly common in enterprise contexts due to product and organizational complexity.
The below overview of classifications will help you better weigh your options for intentional debt, and better identify and eradicate your unintentional debt. Even if you aren’t able to fix a particular issue yourself, understanding the concepts will help you better pick your battles.
Technical Debt
Stop and think about the times developers asked for compromises or shot down your designs citing technical limitations.
Perhaps they said that your requests were too time-consuming, wouldn’t perform well, or just weren’t possible. These cutoffs and bypasses alter the intent of your design, in ways that wouldn’t be necessary with a modern, well-maintained technology stack. This is technical debt.
Technical debt comprises two subcategories: Back-End and FrontEnd Debt.
1. Back-End Debt
Even minor changes in this part of your stack can irreparably undermine your product’s usability. Back-end debt segments into four key areas:
- Performance
- Hardware
- Database
- Security
All four aspects are deeply entangled; an issue with one typically pulls in others.
2. Front-End Debt
Your technology stack greatly impacts the types of debt you’re going to find here. Since I primarily work on browser-based web applications, I classify front-end technical debt as follows:
• Browser Version Support
• Outdated HTML
• Outdated/ Non-responsive Frameworks
• Poor Coding Practices
Functional Debt
Functional debt is usually the result of naturally-evolving shifts in requirements (i.e. technology changes, customers needing new capabilities, features added to attract a wider customer base).
You’ll primarily encounter four types of functional debt.
1. Scale
If we don’t regularly set new performance goals for our products and improve their UI in order to deal with scale, they will eventually choke. Our users also need efficient tools for managing data at increased scale. This means improving search capabilities, providing more sorting and filtering options, and making it easier to perform bulk actions once desired data is found.
2. Information Architecture
As hard as we try to account for future growth, we aren’t fortune tellers. Bolt-ons can turn carefully-planned architecture into Frankenstein’s monster. We are forced to make compromises to get the job done because we don’t have the freedom to rearrange content and navigation each time.
3. Old Features
Enterprise product teams are often loathing to remove features, just in case some customer still uses an obscure function. But these little-used tools may be harming users as a whole — interfering with features the majority are using.
4. Priority of Functions
Your customers’ priorities change over time, so don’t be afraid of reflecting those needs in the UI. Bring the most popular features to the fore, then move special use cases or anything needed for backward compatibility to a tucked-away spot that won’t clutter the UI. Regularly evaluate how functions are accessed, even if there aren’t features you intend to cut.
Behavioral Debt
Behavioral debt specifically refers to the behavior of the user interface. It’s often a symptom of functional debt, but worth categorizing separately to afford more granular prioritization.
1. Tool Time
As the UI gathers more functions, more cruft is created to contain them — more tabs, more toolbars, and more settings. A user may spend so much time fiddling with widgets that they run short on time to actually accomplish tasks with the tool.
2. Consistency
It’s easy for inconsistencies to sneak into the UI as a tool matures, and the effect can be much larger than you would anticipate. Inconsistencies cause confusion and erode trust.
3. Conventions
A convention is formalized consistency. You create a convention when you recognize intentional consistency (or unintentional consistency that is deemed valuable after the fact) and document it as a rule or guide. Be cognizant of this while classifying and addressing UX debt, keeping your conventions up-to-date alongside your UI.
Visual Debt
Teams with poor communication between developers and designers are especially prone to visual debt.
1. UI Chrome
The amount of screen real estate available for the content and important, interactive parts of the UI is frequently reduced as an application accumulates chrome. These static, non-interactive parts of the UI (the button bars, borders, title areas — essentially, anything that isn’t text and can’t be clicked) significantly cut away from your high-value space for functionality.
2. Iconography
Inconsistent iconography is arguably the worst visual debt infringement. Usually the outcome of pure laziness, someone might choose a pre-existing graphic to represent a function rather than design a custom icon. Unbeknownst to them, someone else has already used the graphic to represent a completely different function, sowing confusion across the product.
3. Consistency
Consistency again? Yep. Visual consistency in color, typography, layout, and style is imperative to a quality user experience. Regardless of how well it actually works, if a UI looks broken or unkempt, users will translate that into their perception of the product.
4. Trends
User interfaces are consumer products and likewise subject to trends, whether you like it or not. If your application falls too far behind, users will see it as “old” and “outdated,” regardless of how well it works. If your interface still looks skeuomorphic, expect some backlash in today’s era of Flat Design.
5. Branding
There should be a collaborative process between UX and marketing; when it comes to software, your interface is your brand. When your brand changes for marketing reasons, you should consider changes to the UI in support of the brand. Conversely, when changes are made to the UI for usability reasons, those that impact branding guidelines should be discussed with marketing.
6. Copywriting
This aspect of branding has implications for usability, particularly in terms of labeling and notifications. Copywriting debt covers everything from typos and grammatical errors to poorly-worded instructions and unhelpful error messages.
Documentation Debt
It is imperative that a team leaves behind a visual and written history of its thought processes. Otherwise, the only record of decisions is the final product.
Unfortunately, good documentation is a real struggle for many teams to create on their own; growing piles of poorly-maintained product specs can become indecipherable puzzles. Even a pure Lean UX approach doesn’t always translate well to enterprise environments.
As a middle ground, collaborative design platforms (like UXPin) can alleviate much of the documentation burden. There is less risk of design decisions becoming fragmented across different people’s desktops or cloud folders when you can create and house artifacts like user flows and prototypes in one central hub.
Never take documentation debt lightly — it can quickly lead to visual and behavioral debt as the project evolves. Unless teams synchronize all work around updated design artifacts, visual standards may disintegrate in the name of convenience. Even the best design system could be sabotaged due to behavioral inconsistencies.
Conclusion
Like a financial loan, UX debt should be proactively avoided and diligently reduced when possible.
Now that you’ve seen the common sources of UX debt, we’ll dive into tactics for spotting it in your products. [Go to Part 2.]
