Paying your product design debt
We leave small issues in the user experience that can gradually escalate. How to start attacking these debts?
Experimentation is one of the most common practices within the tech world, basically, every book you read about Startups or Agile will talk about what an MVP is or how to incrementally release a product.
Mathematically it’s not hard to see the benefits of iterative releases. Let’s say that throughout 2021 you will do 100 experiments, but to validate the tests you only need to develop 50% of the scope of functionality. Therefore, you don’t need to make the entire investment without understanding whether your experiment was successful.
If only 20% of your tests are successful, you will have invested only 60% of the development of those who did it the “right way” in all cases. Since failed experiments will be discontinued, so you won’t need to invest more time and resources in something that won’t be used.
But do you really go back to the experiments that were successful? Do you fix the architectural flaws or the “workarounds” made to be able to launch in the “messy” way?
Well, that’s where debts are born, as we’ve gone through the experiments and left behind a lot of choices we’ve made in order to grow incrementally. So we choose today and leave tomorrow for tomorrow.
However, this article is in no way intended to criticize technical or design debt. In the end, this is a super necessary tool for the functioning of several teams, but in order to instruct you on how to analyze your debts and finally start paying this bill.
What is a Product Design Debt?
Similar to the technical debt, we also have the product design debt. But instead of leaving behind problems in our architecture, scalability, database… we leave small debts in the user experience that will gradually escalate.
Product Design Debt can be easily identified as non-standard components, breaches of platform design patterns, or even holes in information architecture.
A closer example of my day-to-day life in a SAAS is the need to iterate quickly and often not plan where the actions will start and that’s why we ended up with a menu that will serve as a solution for all actions within an area.
Problems like this are not unique to today. Amazon 10 years ago had the same problem when using a top menu as a navigation bar. By treating as its main means of navigation, each new category added, the bar continues to grow until it takes up a good part of the screen, until the debt was finally paid, re-evaluating the means of navigation and changed to a sidebar and reducing the menu higher.
Although you will find other types of debts throughout the development of a product, the two most common are linked to the main limitation of any website, the visual space.
At some point during the product’s growth, adding new buttons, CTAs or menus will cease to be an option and if you still continue down this path gradually your screen will start to glow brighter than the streets of Tokyo.
However, the inverse of hiding the options in sub-sub-sub-menus will only push your options under the rug and at the end of the day it will become more complex to get activation in those solutions.
When should I start paying my debts?
Like any debt, as soon as possible to pay, less interest will be incurred at the end of the process. However, we don’t always have enough resources to pay all our debts at the same time, even more so with the product in full growth.
So there are some steps you’ll need to take and many of them are already in your Product Management process.
1. Create a Debt Inventory
In the same way that you have a backlog of the product’s future, keep well documented the problems and debts that have been left behind.
2. Understand which debt has the highest interest
Not all debt is the same, each one will have a different type of impact and evolution. In this case, I recommend using a GUT to have a better understanding of how interest on your debt will grow.
3. Prioritize and attack
Once you understand what the highest interest debts are, just go on the attack. Start dedicating space in your sprints or weeks to incrementally pay off your debts.
Further Reading
If you want to go further and understand even more in depth about Product Design Debt, there are two other articles that I highly recommend.
One is written by Andrew Chen and the next by Austin Knight.
Have you ever suffered from Product Design Debt? Leave your comment below and let me know how it went.
