Wherever you may be in the process of eliminating design debt, don’t get so caught up in your present situation that you blind yourself to new debt. It’s always out there, trying to work its way into your products.
The first key to avoiding UX debt is to understand where it comes from, which helps you spot trouble and guard against it. Here are some practices that will significantly lower your risk of acquiring unintentional debt.
Usability Research and Testing
To protect against UX debt, it is imperative to understand the intricacies of the work we’re supporting. The more you know about users, the less debt you’ll likely accrue. Unfortunately, it is common for enterprise UX teams to work without the benefit of user research.
You’ll find countless reasons to blame it on, ranging from costs and logistical infeasibilities to billing issues and customer stubbornness. The lack of testing is also a problem; how many times have you heard the phrase, “That’s a training issue”? Time to market, short deadlines, and a reliance on “customer acceptance criteria” can all mean zero usability testing. Some company cultures even believe that Quality Assurance is all that is necessary.
If you’re struggling to get buy-in for user research, try following Rian van der Merwe’s advice from the free guide Practical Enterprise User Research:
- Frame any user research discussion around revenue (e.g. $1 in design saves $6 in development and $100 after launch).
- Use case studies to support your point, like the $300M button story.
- Present a concise user research plan that shows a feasible budget and timeline. In the 1-page plan, give a brief background, list the testing methods and schedule, describe the research goals, and desired insights (e.g. “Product Marketing recommendations to overcome barriers to adoption).
When it comes to finding end-users for research and testing, try to form a relationship with the people who need to implement the software. Otherwise, going through the buyer can result in tons of red tape.
A well designed user interface, by its very nature, is consistent.
A button is represented in a very specific way; there may be variations, but the user will always recognize it as a button. By its very nature, a user interface should be modular, with reusable components.
Strive for a design system that is both modular in its design language and in code.
Modular UI design works a lot like modular homes:
- A home builder doesn’t design new doors and windows for each house it constructs. They standardize on a set of basic, pre-manufactured parts that they can then arrange in many different layouts. Similarly, we can identify an array of common elements used repeatedly throughout our products in varying contexts. For example, a sign-in form is composed of labeled name and password fields, a submit button, and typically a “forgot password” link.
- As those basic elements are assembled into components, a design language begins to form. Common UI patterns emerge and can be documented in a pattern library or style guide. You’ll want to explain the use cases and rationale behind the patterns, such as when to employ a card-based layout versus a list.
- Small components may be combined into larger ones, eventually forming screens. At this point, you have achieved an economy of scale in which the effort spent on the detailed design of one microinteraction is magnified many times over as the resulting value is realized repeatedly throughout a suite of applications.
To facilitate a universal understanding of your modular design among your team, start by identifying reusable components together. As you define the principles and patterns, make sure you employ a common vocabulary. As Alla Kholmatova reminds us, the name of your patterns will affect the perception of their function and reuse (e.g. “homepage header” is more restrictive than just “header”).
You can even introduce a bit of participatory design as you define your language and patterns. Again, as Kholmatova recommends, consider showing the patterns to users to get their feedback on perceived functionality.
While modular design helps reduce design inconsistency (and therefore UX debt), modular code helps streamline implementation and technical maintenance. With modular code, the team doesn’t need to change 100 different instances of a button for a small HTML tweak.
Instead, the change is made once within a single chunk of code, and every button in the application automatically exhibits the change.
Here are a few useful approaches:
- Object-Oriented CSS (OOCSS) is a modular, front-end architecture that keeps the structure of your UI separate from its appearance and separates the container from the content. In so doing, it makes your styles reusable and more maintainable. For more information on this approach, I invite you to check out my book, Bridging UX and Web Development.
- SMACSS stands for Scalable and Modular Architecture for CSS, a creation of Jonathan Snook. It’s similar in spirit to OOCSS, organizing styles into five categories: Base, Layout, Module, State, and Theme.
- BEM stands for Block Element Modifier. It’s basically a class naming convention that follows the OOCSS approach.
- Atomic Design is a methodology for creating design systems. Created by Brad Frost, the approach has you systematically identify the basic elements of your UI—the atoms—which then combine to form molecules, and finally become organisms. It’s a perfect metaphor to understand the modular structure of your product.
Ultimately, you’re creating a unified design system in aesthetics, interactions, and code—which is the most effective method for avoiding UX debt. It enforces the design, making it easier to build a new screen following the rules than it would be to do it any other way. And, if any debt does creep in, it is easier to address. Fix it once to fix it everywhere.
Be the champion of modularity in your organization.
People complain that design documentation takes too long to produce and maintain, much less read—but documentation is not bad. Bad documentation is bad.
Smart documentation helps drive good decisions and avoid UX debt:
- It helps developers avoid implementing a first-thing-that-comes-to-mind decision.
- When accurate, it is a trustworthy source for user guides, help documentation, and training material.
- The act of documenting causes you to think in more detail, and from a different perspective.
- It increases the probability that mistakes made during implementation will be caught and corrected before the product ships.
- It can become a reference that guides future design.
Prototypes are a great way to demonstrate behavior that is difficult or inefficient to describe in a static document. Employ them liberally as tests and exemplars. That said, they should supplement good documentation—not replace it entirely.
Enterprise software is complex, requiring multiple servers, databases, and integration with external, third-party systems. Strict security measures may be in place. You can’t rely purely on the live system as a reference. Smart documentation is much more convenient.
Autodesk’s AutoCAD 360 team, for example, creates their product requirements document as an information hub in UXPin. They describe technical and UX guidelines and include links to Zeplin and UXPin to illustrate the requirements. As the project progresses, the team continues to update the document to reflect new requirements and constraints.
Photo credit: AutoCAD 360 Product Requirements Document.
User flow created by Autodesk’s AutoCAD 360 design team. Links to their product requirements document.
Too often, documentation is done at the end of the process. Designers wait until the design is “done,” and then they document it. This is why such a negative view of documentation persists. It is seen as the chore that must be done before moving on to the real design work.
Documentation isn’t a separate task; it should be happening throughout the process, and indistinguishable from designing. Good documentation is a force field against UX debt. It acts as a filter, catching anything that shouldn’t make it into the product.
Be the champion of good documentation in your organization.
UX debt is a serious matter, and it often seems insurmountable.
I hope this quick guide gives you the perspective and confidence to avoid UX debt.
You now have a strategy for protecting your organization against future debt. Lead your team to a debt-free future in which you can spend more time enhancing your products with the latest advancements in technology and addressing the needs of your users, rather than making compromises, beholden to legacy deficiencies.
I’ll offer you one last word of advice: Don’t be disenchanted by the challenges before you. Take pride in your accomplishments. Celebrate your progress, and promote the vision you are working towards.
If you found this article useful, get more advice by downloading the free e-book Eliminate UX Gaps In Your Products.