Constant Contact recently released one of our first release planned and executed with the Scaled Agile Framework (SAFe), known externally as our Toolkit release.  There will  be a future post about some of the lessons learned from that experience, We see  major release as an opportunity to do a retrospective on our process. This post discusses how we should define and track work for Technical and User Experience (UX)  Debt.

In this post, I am joined in voice by Giles Phillips, Constant Contact’s Chief Product Designer.  Together we have been jointly discussing and comparing Technical Debt and UX Debt and how to best approach the scheduling and tracking of this work.

In our organization, the concept of debt represents an acknowledgement that we must continuously improve and upgrade our products, and that the shortcuts we may take to reduce the cost of delaying product delivery manifest as deferred costs to achieve optimal product quality.   Just as this is true in our technical infrastructure and implementation, this is also true of the cumulative User Experience that our products create. And so, we recently started discussing the idea of UX Debt as a counterpart to technical debt.

What Is Technical Debt?

While there are many technical debt definitions,  we started with Martin Fowler’s definition ().  At Constant Contact we have defined Technical Debt as:

• The platforms and tools that we are using need to be upgraded or swapped out for newer, better, supported tools.
• We want to implement new non-visible features to make future work more efficient (CD, Refactor)
• A poor, rushed, or otherwise  incomplete implementation is impacting customers (speed, defects, etc.)

Each of our teams maintains their own set of technical debt items as part of their backlog to work on.  Additionally new technical debt items are pushed to the teams backlog from the Program and Portfolio teams through Architectural Epics.  All of the above are tracked as SAFe Refactors.

OK, so What’s UX Debt?

UX Debt is created much like technical debt in the sense that tradeoffs are made for the needs of the project (time, complexity). It’s a recognition that you have incomplete information and want to “learn in” into a design, or that you need to refactor / update the UX design to align with other parts of the product, new patterns in user behavior, or new usage contexts.

We’ve also seen that Scaled Agile processes have illuminated UX debts across our suite of products. As autonomous teams are continuously moving forward in small increments, we experienced an emergent condition where different parts of our product used inconsistent patterns or designs.  As we looked towards a complete experience across an entire product (especially those built by many different agile teams) we found that each area of the holistic product experience needed to be more internally consistent.  In addition, as with many Agile projects, but especially in a SaaS model, you are constantly learning, innovating, and improving your UX.

Andrew Wright gives one of the best descriptions of UX Debt this blog entry( http://nform.com/blog/2013/05/user-experience-debt/).

Dealing with Debt

We have had a process to resolve the tension between feature work and technical debt in place for some time.  We have created a separate swim lane within our backlogs for technical debt.  We have always given the teams guidance that 15% of the total effort for the team should be used for technical debt.  Architects and Development leaders on each team are responsible for creating and managing their backlog of technical debt, including prioritizing it with their Product Owner (PO) for inclusion in sprints.  In reality, that 15% guidance is an average over the long term, with the actual amount being a bit lumpy sprint-to-sprint.  SAFe gives us a way to track and measure our success at achieving the balance that we want.  By moving to Epic/Feature/Story, we now have all of our backlogs tracked to either customer facing Epics or Architectural Epics, which is where we capture our Technical Debt.  So far this has been a good solution.  We have been able to get the right balance and deliver on both our customer-facing features while also keeping our house clean.

In looking at UX Debt, we tried to decide if we should approach UX debt the same way or if we needed a different way of thinking about UX Debt.  In situations where UX Debt is made up of implementation issues (new browsers, defects), it feels a lot like Tech Debt. In areas where UX debt is comprised of emergent patterns or learnings from customers, it feels a lot like new feature work.  And in areas where we know we have usability issues or workflow problems, it seemed very specific to UX.  Because UX debt is a newer concept for us, and spans so many different types of issues – we decided to start by identifying and categorizing UX debt work items as we discover them.  This way, we can track not only how much UX debt we are aware of, but also how successfully we are paying it off.  The PO and UX Designer should work together to prioritize these work items against other features and functionality. As we continue to learn in to our approach to managing UX debt, we are committed to evaluating our approach and changing it if necessary.

 How do you manage UX debt? Do you distinguish it from general Tech debt?   Leave your comments below to share your thoughts and experiences.

If you are an engineer or UX designer who is looking to work in a dynamic empowering engineering organization that cares about making itself great, check out our open positions at www.constantcontact.com/jobs.

Mike Adler