Part 3 of our series on design debt.
Now that I’ve identified design debt, what do I do about it?
The best way to think about handling design debt is much like any project – get on the same page with other stakeholders, get your list together, analyze it, and plan. Just remember, a plan doesn’t always mean a full redesign. It might mean leaving certain things as they are, making small changes over time, or it might (but not always) mean time for an overhaul.
The Opportunity
There are many ways to start projects, but the most successful projects start with everyone on the same page. In Agile, you always start with a definition of what constitutes “done” and a clear understanding of priorities for the release. Tackling design debt successfully starts out in the same way.
Define Design Debt as a Team
Much like the definition of done in Agile teams, you want to start by agreeing what you consider to be design debt and how much you are willing (and able) to carry without impacting the team, the business, or the customer. Teams can lump all design issues in as design debt, but design debt is defined as problems occurring over time through innovation, iteration, and the compromises made during design and product builds. Agreeing what is design debt is a good start. Determining how much design debt you can have without impacting delivery is the next step. From there, you have a place to start.
Define the Context
You have your list of design debt, what it is, and what’s acceptable to carry. Now you need to give it context so you can clearly evaluate the priorities. The list should include:
- A name and description of the debt
- Where it is located (e.g., PLP, PDP, checkout)
- Any dependencies (e.g., does it require a data set, additional research, or other teams).
Define the Priority
Next, you need to understand the priority of your design debt items. You need to ask:
What is the impact?
Understanding the level of impact this element of design debt has on customers, the business, desired outcomes, business processes, and internal stakeholders helps you understand how much positive impact addressing that item will have.
Ask your team:
- Does it impact all customers or is it just mobile customers on a little used mobile app?
- Does it impact our internal teams?
- Does it impact morale?
- Does it impact accessibility or inclusivity?
- Does it impact business results?
What is the effort involved?
Understanding the magnitude of each area of design debt allows you to understand the complexity. Is it a simple color change or a whole new design flow that’s required? High-Impact and High-Effort design debt might need to be a project while a Low-Impact and Low-Effort design debt may not be worth pursuing. Using t-shirt sizing helps with some of this classification; just make sure everyone is on the same page as to what each size means.
Ask yourself things like:
- Does it require a full set of new requirements and research?
- Is the solution known but wasn’t implemented because of timing or other factors?
- What is the total amount of effort needed to remediate the debt? (i.e., strategy, development, design, testing, etc.)
What’s the urgency?
Many things can factor into when you should address the issue, such as quantifying lost opportunities from not addressing the issue or the volume of customer feedback.
Ask yourself things like:
- What are the benefits and costs related to addressing this now vs. later?
- Can this be worked into our normal release schedule, or does this need to be addressed immediately?
- Based on the evaluation of the other elements, how important is this?
Fully understanding design debt by considering its impact, effort, scope, and urgency allows you to understand just how much it will cost to fix. Much like any other project, taking this step to understand the priorities helps you put your effort where it is best suited to make a real impact.