Eliminate UX Debt — Improving Consistency & Usability — Part 3

This is an excerpt from the Eliminate UX Debt ebook, written by Jack Moffett, and originally published on UXPin.com.

Avoiding UX Debt

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

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:

  • 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.
  • 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 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.

In Design

  • 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.

In Code

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.

Smart Documentation

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. 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.

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.


I hope this guide has given you perspective and confidence in the knowledge that you can formulate an approach for identifying, prioritizing, and eventually eliminating the debt your products have accumulated.

Even better, 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.

UX Efficiency Case Study

The Challenge

To make the data actionable for customers, Sumo Logic invested heavily in its own internal UX team to bring a “consumer-grade” experience to the enterprise. In 2015, they hired their first UX team comprised of design leaders, interaction designers, visual designers, and UX architects.

The company had been using Axure for wireframing but Design Director Daniel Castro quickly found that the solution did not allow for easy design modification and did not encourage collaboration.

Tired of sharing PDFs back and forth, the company needed a collaborative UX platform that could scale along with their teams and processes.

The Solution

In a culture already used to collaborative tools such as Slack, this slow process of emailing thoughts on static designs was stifling. Castro had begun using UXPin at his previous job and knew it would offer his Sumo Logic team the collaboration tools they needed.

“We are constantly collaborating with engineering and product managers and it used to take a significant amount of time to work together going back and forth,” Castro said. “UXPin allows us to easily show the flow and main components of our projects. We can share a link and everyone can communicate with our key stakeholders, expanding on each other’s comments and allowing us to manage feedback contextually without redundancy. It’s like a visual version of our thought process. We can even make comments on a pixel level. This has made our review process three times as fast.”

“UXPin has played a vital role in creating a design-oriented culture at Sumo Logic. The team is great to work with, and I’m excited to see what we can do next.”

The Results

  • Design reviews are three times as fast and now contextual using UXPin to collaborate instead of emailing static PDFs.
  • UXPin is “like gold” when trying to get approval from stakeholders on projects, halving the effort needed to communicate with stakeholders.

The design tool for teams and professionals. From UI design and prototyping to collaboration and handoff. Speed it up with UXPin. • www.uxpin.com