This post is part of the series Explain Like I'm Five, which aims to make tech concepts and terms easy to understand. In this two minutes read, we'll explain what is design debt.
What is Design Debt and Why is it Important?
Design debt is a common yet rarely discussed problem startups face in iterative and incremental software development. Learn what it is, where it comes from, and why it is so important to prevent it.
Many apps today suffer from design debt, a rarely discussed downside of iterative and incremental development. The reason behind design debt is that startups quite often trivialize the role of design verification in their pursuit of a faster time to market.
What is design debt?
The term design debt is based on the more popular concept called technical debt, coined by a renowned American programmer Howard Cunningham. Cunningham compared shortcuts and the lack of a proper verification process during development to taking a large loan that you would later have to repay at a considerable interest rate.
So if technical debt is the result of rushed decisions and poorly written code that affects the integrity of your codebase, design debt is the outcome of hasty implementation, compromises, and postponed or skipped UX/UI verification that can all damage the integrity of user experience.
Where does design debt come from?
A faster time to market may be a tempting goal but it should never be achieved at the cost of design verification. Otherwise, the usability and consistency of your design will naturally start deteriorating. Minor flaws and deviations will accumulate with each sprint, ruining the structural integrity and eventually turning your design concepts into an inconsistent, disjointed UI that delivers a disappointing experience. To make it more relatable, here are some common causes of design debt:
Lack of research and user testing during the planning and design stages led to floating specifications and poor user journeys.
Designers had no unifying plan directing the project and conceptualized features following their own ideas. This led to lack of cohesion in design.
With new features added, the design gradually became stretched beyond its original intent. Elements were forced into layouts without due consideration.
Your team was trying to revolutionize a feature without paying attention to whether it fit in well with your general design direction.
Designers weren’t involved in implementation processes, which caused deviations to be left unnoticed until the last moment.
What bad design can cost you
When left unchecked, design debt can sometimes cause a lot more trouble than a bad first impression or hurt user satisfaction. And the problem is not nearly limited to software development. Here’s one amusing real-life example for you.
Constructed in spring 2014, London’s commercial skyscraper (nicknamed The Walkie Talkie for its distinctive design) is a great example of complete disregard for design verification and its consequences. And while the building’s appearance is rather debatable, it wasn’t the visual aesthetics that made it so notorious back in the day.
The building was designed to expand towards the higher floors, turning it into a huge curved mirror. During its construction in the summer of 2013, the building started reflecting concentrated sunlight of up to 243 °F (117 °C) onto the streets below for about two hours each day. This led to numerous reports of parked vehicles being horribly distorted with paintwork completely melted off. Shortly after, several parking bays in the area were temporarily closed as a precautionary measure.
Even though the scorching problem was later fixed with a series of vertical fins installed on the higher floors of the tower, in July 2015, another issue related to the very same concave design revealed itself. When strong gusts of wind collided with the curved facade of the Walkie Talkie head on, it created a severe downdraught effect. The wind, redirected downwards at incredible speed and pressure, started blowing people over and ripping signs off nearby buildings.
Following all the distress caused by the building’s flawed design, the City of London Corporation has even started demanding independent assessment and verification of construction design reports at the planning stage. Royal Town Planning Institute described the building as “a daily reminder never to let such a planning disaster ever happen again.”
Conclusion
Putting design verification at the very bottom of the to-do list is a common problem among today’s software development companies.
Designers shouldn’t just hand off features to developers and move on to designing the next one. Instead, they should actively participate in the implementation and QA processes, verifying the results. Without timely verification, UX/UI flaws get addressed in the last place.
Thus fixing them costs a lot more than if a designer was involved in the process from start to finish, checking the implementation during each sprint to see if there were any deviations from the design.
