2

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?

2

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.

Framework for the Elements of Technical Debt Management

  • 1
    +1 I think there are many overlapping elements when comparing technical debt to design debt. Even coding involves some element of design, and design involves some element of implementation, so I think this framework is not a bad starting point. UX debt is a little bit more complex as I think there is also an organisational change management aspect, as well as an integration into software development lifecycle and/or agile ways of working aspect to it as well (which is why I am leaving it out of the question). – Michael Lai Oct 17 '18 at 12:31
  • good luck, it would be great if you post updates in case you make progress on this one i don't think anyone has tackled this formally before – UX Labs Oct 17 '18 at 13:12
  • These are often the most interesting questions to tackle :) – Michael Lai Oct 17 '18 at 22:23
  • Just out of interest, why is technical debt not something popular on the tech side, since it does have a large impact on the time and resource for IT projects. – Michael Lai Oct 20 '18 at 22:56
  • 1
    my guess would be regarding the size of the organization, it's probably more popular in larger organizations as they might invest more in management to ensure higher security, whereas small to medium might skip it and hope they are in the right direction, i'm also guessing it shares the same answer with why do small-medium organizations invest proportionally less resources in strategic management when compared to large organizations just a speculation though – UX Labs Oct 21 '18 at 9:56
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).

1

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.

  • So in this case, how would you have 'quantified' your design debt in this example? Just the fact that you are having to do anything between 1-2 times the work that would otherwise be required? – Michael Lai Oct 20 '18 at 23:50
  • 1
    Great question, I was actually able to quantify two issues: I added 25%-est LOE for any mockups effort related to this screen and ensured that team understood the unfulfillment of maintaining two mockups at all times. However the issue itself the input field was actually finished. It increased conversion rate by 1.2%. Using my analytics I did a retroactive analysis of how many users we lost due to this and multiplied this by the value of a user. I subtracted the cost of building the solution and informed the team the loss of revenue. Now were given more consideration due to these insights – Bromox Oct 20 '18 at 23:55
  • 1
    So is this process or assessment applied to the other UI patterns? If you can update your answer with this analysis I think it would provide a nice and complete response :) – Michael Lai Oct 21 '18 at 0:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.