How is design debt measured or calculated?

Question

I think designers can probably relate to 'design debt' in the same way that developers relate to 'tech debt', and there are even examples of UX debt which is probably some combination of the cost incurred from doing research, design and develop work.

Rather than making this an overly complicated question, I just want to focus on design debt in particular, as it is probably easier to quantify compared to research debt, but less easier compared to tech debt.

Are there examples of ways in which organisations have been able to not only measure the benefit of a change in design practices, but also calculate the cost of less than ideal design changes that create design debt?

Answer 1

I hope your question will be strictly answered from a UX position, although i'm a bit skeptical as technical debt is barely popular in the tech side.

I have found a paper named

An Analysis of Techniques and Methods for Technical Debt Management: A Reflection from the Architecture Perspective

written by Carlos Fernández-Sánchez, et al.

It enlists many debt types, one of them is called Design & Architectural Debts i'm not certain if the word design is referring to product design or code design.

Design and architectural debt: architectural debt could be the result of sub-optimal upfront solutions, or solutions that become sub-optimal as technologies and patterns become superseded

Anyway even if it does not refer to our "Design" i truly think that the debt management framework provided is abstract enough to be used as well as in our domain, while it might not be perfect for ux, i'm guessing it's as close as it gets, so if you agree then you should give the paper a shot.

Answer 2

Based on the effort and process required in the design phases of UX projects, I would suggest that a simple way to estimate the amount of design debt can be calculated as follows:

Human resources

• time taken to recruit (if done externally) the designer or allocate (if done internally) staff to the task
• time spent on the initial design tasks/activities by the resource

Design complexity

• time spent creating new designs to meet known requirement changes (i.e. initial design was not flexible enough to be adapted to new requirements)

• time spent realigning existing and new design to keep consistent look & feel or improve user experience

Miscellaneous

• any other time incurred as a result of foreseeable requirement changes that have not been accounted for during the initial design

If you convert all the time spent on these activities into their $ value equivalents, and just add up the cost excluding the time spent on the initial design task/activities that should give you a rough estimate of the design debt.

Note that design debt should not flow onto any technical debt (at least if the workflow from design to implementation is ideal), or at least should be clearly defined even if it is the same resource doing both tasks (as in the case of a full-stack designer/developer).

Answer 3

An Example

Overview

I worked on a website where my goal was to increase conversions in an registration process. There was an input field that I wanted to alter "Date Picker" as my analytics and observations showed this did not provide a good experience

The issue

The date picker input field was used for entering your date of birth. The problem in Canada is we say our birthday and possibly think about our birthday in order of month/day/year. However the interaction the user had to make with the date picker was year/month/day. My observations was that users couldn't figure out how to change the year let alone efficiently (switch to decade view). This ultimately lead to slow registrations, incorrect birthdays (which was crucial to be correct), and users giving up.

The Design Debt

This improvement recommendation sat in our backlog for over a year. I had a hard time keeping mockups updated as mine showed the new date of birth input field but whenever we created mockups for client sign off, we had to show the way it would look as upon delivery not as the way UX wanted. This often leads us to maintaining two mockups at any given time.

Measuring Debt

When the input field was finally implemented we observed a 1.2% increase in conversions. We were able to retroactively analyze how many users we would have gained had this UI pattern been implemented a year ago. We then took this number and subtracted the development/design effort to make it a reality. moving forward the UX team is now given more klout when it comes to UX/UI recommendations.

Summary

Although this is one example, there were and are many UI patterns that the UX team has requested to be updated as part of various changes to the product however only some are implemented. We spend a lot of time maintaining the UI mockups as we would like to see it (design debt) and mockups that are what we will actually deliver to client.