Establishing a strategy for tackling UX Debt

Working alongside the development teams and other UX leads, I helped create and socialize a new strategy for cataloguing and addressing Design Debt across the Collector product.


In addition to working with teams to break down the different categories of design debt, I created a structured process for collecting, triaging, and tracking design debt. I socialized the new strategy via an internal blog post, a post for the company's Medium publication, and hands-on training with UX leads and product owners. Finally, I created custom dashboards in JIRA for tracking UX Debt in the backlog, and Trello boards to triage and evaluate issues before they were selected for development.


As one of athenahealth's oldest products, Collector had accrued its share of design debt. Individual issues, taken on their face, can seem trivial and not a priority to fix. Taken in aggregate, these issues can lead to frustrated customers, inefficient workflows, and eroding trust in the product if not addressed.

That said, all UX debt is not created equal. We needed a structured way to:


The universe of design problems can range from seemingly trivial fixes (fix some spacing, improve some system messaging) to entire workflows that require redesign. In most conversations, teams will take a one-or-the-other approach; UX debt is either a minor fix to specific UI elements, or it’s the need to redesign multiple entire workflows. This typical framing of UX debt creates problems with prioritization. The problem is either too small/trivial to prioritize, or it’s so big that the team doesn’t want to risk working on it.

Through discussions with the team, we organized our definitions around two fundamental characteristics: scope (how hard/easy it is to fix) and locus (global vs. local). Each of these types of debt can then be treated in different ways, making it easier for teams to prioritize the work against the larger product backlog.

Then came the question of storing and tracking it all. Spreadsheets were easy to lose track of, or get cluttered with too much information. Adding every single issue to JIRA was a sure-fire way to torture the development teams. We ultimately decided on an approach that involves two key streams:

This allows the development backlogs to stay focused on issues that are workable, while the UX team can keep track of the other issues, pulling them into the development queue as they’re shaped. We use labels within our Trello cards and JIRA issues to keep track of the various types of debt, and can run JIRA reports on those labels to see how we’re tracking against paying it down.

We use a customized JIRA dashboard to track how we're paying down the design debt.

Key Contributions