Today, I want to talk about design debt. We often hear about technical debt and not so much about design debt. They are in fact different from one another but let’s start with technical debt first. The lean and agile management styles promote fast feature and product deployments. After all, startups are especially notorious for shipping often. Although there is nothing wrong with that as these strategies can be great for learning and growing, they do often lead to technical debt. It’s the nature of iterative development approaches.
Product cycles often produce experiments and experiments on top of experiments. Quick turnarounds require engineers to build temporary infrastructure that doesn’t scale or hold up well against the rest of the code base. That’s why engineers practice refactoring. Once a product experiment has been proven successful, it’s time to go back and make sure the code base can support it. That’s how technical debt works and refactoring, although often tedious, is an excellent way to tackle the technical debt. What about design debt though?
Product cycles and design debt
With product cycles also comes product design. The experiments here often include adding new features. However, they also include adapting the design for best possible optimization to help potential customers convert. Again, there is nothing wrong with experimenting, learning and growing. The issue here arises when the design is pushed to its limits with no check on the user experience. Adding a feature on top of a feature, or a landing page on top of a landing page will get cluttered and messy for the users.
You also need to refactor the designs, albeit it product design or landing page designs, if you want to make sure the user experience is excellent once again. Even adding buttons here and there can clutter a page or a screen. Over time an unchecked page will no longer be scalable. After all, a messy page means a poor user experience. But, when you refactor the designs the user experience can be significantly improved. You can refactor a design in many ways, but mostly it boils down to redesigning, reorganizing or decluttering.
How does design debt creep up?
In both, technical and design debt, it can be hard to see the debt pile up till it’s too late. Often the changes are very small and one at a time. It takes time to notice the effect these small changes have individually, and you don’t always see them till they are starting to raise concern. For design debt, a design simply begins to be confusing or look sloppy. It can be as subtle as the colours or typography not matching throughout your app. It can also be as detrimental to your users as them no longer being able to do the tasks they use your app to accomplish.
Small vs large companies
It’s interesting to note that small companies such as startups are not the only ones susceptible to design debt. It’s true, startups move very quickly and may not notice the good things they break right away. That gets them into design debt. However, larger companies get into debt too. If you have multiple teams, and no coordination between them debt will start to pile up because no one is keeping track of the big picture.
Additionally, design debt will also begin to pile up if there isn’t a team that’s specifically tasked with looking over the state of the design and watching over what other teams to do it. This is where startups have an advantage.Often in a startup, there is a person or two specifically tasked with looking over the product holistically. If there is someone, albeit a team or a single individual, who is responsible for the whole product, less design debt will creep in over time.
What causes design debt?
There are many things that lead to design debt. Sometimes it can be unintentional such as putting an unfamiliar or under skilled employee on the project (more on that later). However, in the iterative approach of so many agile and lean companies, the debt creeps up in different ways.
For example, it could be that your team was too focused on building a new and potentially excellent feature without paying attention to how it fits into the product holistically. Another example is wanting to put the new experiment in front of as many people as possible. Now, instead of figuring out where in the user journey it best fist in, you just place it directly within the most trafficked area. Here is another one: wanting to improve the user experience, or wanting to consolidate some of your design debt but being too scared of the results. For instance, this is common when a company is also worried about a temporary traffic dip after launching a new redesign.
All three of these examples have a similar theme. They all point to a lack of recognition of the current state of the user experience and how it will be once the new feature or experiment is implemented. When you’re “moving fast and breaking things” it’s difficult to sit down and think through the user experience holistically and as a big picture. And that’s why design debt is user experience debt because it’s the user experience that suffers here.
Of course, there are plenty of other reasons that cause design debt. However, they all tie into lacking the perspective of the big picture of the product’s user experience in one way or another.
Are some companies more design debt prone than others?
The short answer is that yes, some companies acquire design debt quicker and in larger quantities than others. It’s often companies who want to do it, from peer-to-peer messaging to hotel reservations to buying a pet rat. You might think I’m exaggerating or being facetious but I’m not. Platforms like Yahoo, MySpace or MSN have gathered so much design debt. Social networks, news or classifieds and all-in-one-go-to platforms will be most susceptible to design debt for two reasons. First, they might need to run a lot of experiments to keep pushing features that will keep their users coming back. Second, all four of these companies typically need to have a certain amount of features in order to attract the type of traffic they are aiming to attract.
Another two industries that might need to watch out for is retail and online games. For retails it’s often about selling as much as possible which often leads to many ads on its own website. Games, on the other hand, might be tested to keep on making small additions to expand the gameplay. Although well intended, many small expansions here and there will often lead to clutter all around and take away from the enjoyment of the game’s experience.
What about AB test?
Andrew Chen said that “Show me a site that has great visual appeal, and I’ll guarantee that they don’t A/B test.” He is right. AB tests are a useful and insightful tool if you want to learn and optimize. It’s a horrendous tool if you want to address your design debt; that’s because AB tests are a common design debt culprit. What Andrew means is that companies who are no longer experimenting and instead have learned enough to stand their ground, stop experimenting. Instead, they go with what they know. This, in turn, leads to amazing and beautiful aesthetics and user experiences. Established companies don’t need to experiment, so they don’t. They invest their time in crafting the best possible experiences with what they already have.
I want to mention one more type of scenario which will lead design debt. This one is mostly unintentional but it will still add plenty of design debt. It will probably add other debts too like technical debt, but that’s neither here nor there. When the managers or founders are inexperienced in running a product based business they won’t be able to help to prevent it. Sometimes, they might be even responsible for creating it. If they are inexperienced, they don’t know what they don’t know yet. That’s why it is unintentional. With time, of course, they will get the hang of it and take design debt seriously.
Additionally, junior product designers will fall into the same traps. Again, they too don’t know what they don’t know yet. On small and new teams that don’t have senior staff yet, it will be hard for inexperienced workers to pay attention to design debt as it collects. It’s also hard to watch out for it is there is no senior staff as they would cation the junior designers, for example, about how much design debt they are creating.
Design debt happens. All in all, it’s something to be expected. However, there are ways to address design debt and watch out for it – the same ways engineers do with technical debt.