Very common terminology in tech is ‘tech-debt’ and over the years Engineering teams have established the term with product teams.
A less known term but a very similar one is ‘design-debt’ which for some reason has not been able to establish itself among its peer teams; please share any interesting blog posts if you think otherwise.
An example of design debt and ‘Quickfix’ solutioning
Let’s say there is a mobile application that has the following sections and the product or business wants to add another section that upsells the offers given by its partners. Assuming that the existing layout has not been thought-through and things have just piled up as and when the requirements came. This asks for rethinking the layout which in turn means one has to do card sorting in order to do a proper information design.
But, we don’t have time for that…and even if we have time, we don't have the budget to revamp the entire design. Even if we have time and budget to do the redesign of the entire layout, there is an overhead cost of educating the existing user who has been habituated to the earlier layout, and the designer has to orchestrate the transition to the new layout, which further adds to the cost of design and development.
Hence, the designer is forced to give a less than ̶i̶d̶e̶a̶l̶ correct design i.e. quick-fix solutions which actually adds more design debt to the product making it difficult for the product to scale in the future.
The problem is
- Removing design debt is costly as it takes time and effort
- Living with design debt is costlier as the quick-fix solution will not yield the intended results
The third problem with design debt is something that hides in plain sight and it takes a seasoned designer to bring them to the public discourse within the team
Building a product with scalable features is like the art of stone balancing
If we imagine building products as “stone balancing” and each feature as stones that are stacked one above the other, design debt would be the smaller unwanted stones/algae/dirt/grains of sand sticking at the bottom of the stones that can bring an end to the stone balancing activity by collapsing the stack altogether or limiting the height of the stack to a certain height.
I have tried to explain the analogy between product building and design debt with stone balancing in this image below
Pile of stones → Stone balancing → Pyramid building
Now let’s take this analogy a few steps further.
Stone balancing probably started after our ancestors found a leisurely purpose for the original activity — piling the stones above the dead — so that other animals don’t devour the dead.
One of the key things stone balancing artists do is choose the right stone with the right shape and weight in order to ensure the stone stack scales greater heights. In extreme cases, they may even chisel the stone to a particular shape so that the height of the stone structure touches the skies. One such passionate stone balancing obsession turned into the tallest building of its era — the pyramids of Giza.
The chiseling of the stones can be compared to thinking through the problem statements (also known as Design thinking) and productizing them while keeping the scale and scope of the business in mind.
Like there is only a limit till which stone balancing can achieve but with the right chiseling and hence shaping of the stones, the sky is the limit — the same applies to product building too.
Also, visit this case study of how I managed design debt for one of the most loved accounting products — QuickBooks Advanced — Role based access control feature casestudy
