If you’re in Product & Tech, chances are that you’re quite familiar with the term ‘tech debt’. You may also have heard of its lesser-known cousin ‘design debt’.

The truth is …

Debt of any kind can be a real threat to delivering genuine user and business value in a product.

What is Design Debt

If a product has become fragmented with inconsistent UI, poor information architecture, unclear copy and fractured UX, we know that it’s plagued with ‘design debt’.

In 2020, I led the design and rollout of a brand new design language, in talabat — the biggest online food delivery service in the Middle East. The project was delivered in just over a quarter. It was an incredible achievement for the entire team. We felt pretty awesome. Well … not for long.

2020–21 have been the years of tremendous scale for talabat and our product has matured fast with lots of new features, capabilities and verticals.

When a product is maturing this fast, it is natural for some design debt to creep in, but when it becomes too obvious you know that you’ve got a problem.

5 Common Reasons Behind Design Debt

When our design debt grew to an undeniable presence, it became a part of our DesignOps mission to ‘reduce the design debt in the experience’.

Tackling the design debt problem in a large organisation with distributed teams, could be overwhelming. My immediate response was a massive audit and creating and socialising a debt backlog. Our teams started taking those Jira tickets in their sprints and we saw a slow decrease in the backlog.

But something alarming was happening. As we were paying the old debt, we were fast accumulating the new one. This is when I ran an investigation and came to understand that:

Design debt is not a problem in itself, it is rather a symptom of a bigger and much deeper issue, rooted in the way we design and build products.

In my analysis, I uncovered the 5 common reasons behind why products accumulate design debt.

1. Designing for features — not journeys

I evolved from a time when everything was waterfall, to the world of agile. I’m a big believer and practitioner of iterative design and today it’d actually be hard to name a successful product company that isn’t leveraging rapid iteration, experimentation, and tactics like A/B testing and hypothesis-driven experiments. They’re quite powerful.

When we apply these tactics over time with a focus on specific features and outcomes, we tend to overlook how it impacts the entire customer journey. We’re trying to move so fast that designers/PMs simply take a bunch of hi-fi screens and start iterating on them — losing sight of the full journey. With each iteration, there’s a small friction that’s introduced. Over time, these iterative changes result into a disjointed, inconsistent, and patched-together experience. That’s design debt.

2. Not solving real user problems

In today’s product world, everyone talks about being ‘user-first’, ‘user-centred’, ‘user-obsessed‘ and all those other clichés that start with the word ‘user’.

Despite having the best user interest at heart and in the company vision, most companies go about building products without really understanding their users AND their problems.

They either don’t focus on user problems at all, or mistake business problems for user problems, or worst, they invent problems users don’t have.

Here are some common examples of how a team could jump from an insight to a solution — skipping the ‘why’.

The pointless redesign: “We’re redesigning our homepage to increase conversion.”
Team jumps on a full redesign solution without understanding why conversions are low and fixing only what’s broken.

Make it stand out: “Widget A’ is getting 75% of CTR. Only 35% of it goes to view more, How might we bring ‘Widget A’ up front to users?”
Don’t you wanna know why the traffic is dropping before you zero down on a solution? A missed opportunity to discover a real user problem here.

The entry point sprinkler: “Feature X has a really low CTR. To increase the usage, we’re adding more entry points.”
Shouldn’t we first understand why Feature X isn’t getting enough clicks. Sprinkling it all over the experience isn’t gonna make users notice it. Instead they’d further develop blindness to it.

When a design is failing to meet user and business needs, or if it’s exhausting too much time and resources, it’s most likely because the team is building solutions without understanding the ‘Why’ of a user problem. This results in incorrect assumptions, forced decisions, skewed requirements, and an end product that’s unfit for user purpose. Such solutions tend to have an IA that can’t be explained, a UX that’s unintuitive, a visual design that’s inconsistent.

And that’s how design debt is born.

3. Siloed ways of working

In a typical product development cycle (Discover>Define>Develop>Deliver) the first one and half of the diamonds involves the entire team working together to reach a solution they’re going to build. There may be some focus on a particular role, e.g. PM would help drive business goals, designer would be the guardian of the user goals and engineers could safeguard the feasibility aspect. However, until the team reaches a certain point in the process (e.g. UI design or code the logic), they work together to discover, define and develop a solution.

But in the real world, that’s not how most product teams work. Product managers are defining and driving business goals/logic without involving designers or engineers. Designers are designing in their own bubbles, without consulting with their product or engineering peers. Engineers are usually brought in when hi-fi designs are ready.

Solutions that come out as a result of siloed working are mostly reduced to an MVP that’s not valuable and usable. This happens due to realising too late in the process that the design was not feasible or not viable — hence needs to be reduced to an MVP that’s actually possible to build and works for business. Such solutions are not a good user experience and tend to land in the design debt pit.

4. Design hand-off

If you look at the live version of a digital product, chances are that it looks quite different from what the designers created in Figma.

There could be many reasons behind that. However, one of the key reasons is also the transition from Design to Build. This is when designers hand off design assets to engineers and walk them through the solution — the famous design hand-off. Traditional design handoffs are metaphorically positioned as a singular event marking the end of the ‘design process’ and the beginning of the ‘engineering process’.

The problem with this approach is that it leads to involving engineers only at the design hand-off stage. This lack of early collaboration between design and engineering could translate into missed edge-cases, ignored empty states, and unnecessary or impossible features making it into final designs. As a result, engineers may have to deviate from design due to feasibility issues or gaps they have to fill with logic without a design reference. Hence, we see production slowly drifting away from design with each iteration. These gaps over time become significant and end up as design debt in products.

While design hand-off is, no doubt, an invaluable step, it is important to remember that hand-offs aren’t a moment in time, but a process and should be baked into the end-to-end process early on.

5. Design alignment and skills

Alignment and consistency in design is the biggest challenge for designers that are embedded in squads with their attention focussed on solving specific user problems. When there’s no intentional effort to guide and align the work of distributed design teams, the experience gradually moves away from its original, cohesive roots — leading to design debt.

Another subset of the problem could be design team skills gap. Product takes a direct hit if the design team is lacking in design competencies. Especially when product designers own their areas, across the full spectrum of design capabilities — from discovery, to ideation, to hi-fi prototyping. Having these gaps for too long can also lead to design debt.

Many brands with distributed designers have faced this challenge and have written about how they tackled it. They found the solution in supporting product designers with a central design team responsible for aligning the entire Product org around design guidelines, building design systems, ensuring consistency and quality — essentially working as a connecting tissue for the whole Product org.

Apart from design skill gaps, we can’t ignore that design debt usually occurs in code. Therefore, it’s equally important to address skill level issues in front-end and back-end engineers.

Wrap up

In this story, I’ve highlighted the 5 common reasons why products have design debt:

1. Teams design for features — without understanding how a feature would impact the end-to-end customer journey
2. Teams don’t focus on user problems, they jump from insight straight to solution
3. Lack of collaboration within squads — everyone is running their own show
4. Designers don’t involve engineers early in the design process. This leads to missed edge cases, feasibility issues that could’ve been caught early on. Pushed for time, engineers have to improvise and compromise on quality
5. It is a big challenge for distributed designers to align on their work, unless there’s an intentional effort through a design system or a central design team. Sometimes, design/dev skills gap also lead to design debt in product.

In talabat, we’ve come a long way since I compiled this report on the analysis of our design debt. In addition to creating awareness, we’ve taken many actions to tackle these challenges:

1. We built a design system that brings cohesion and consistency to the product. We continue to invest in this initiative by scaling the team and growing our library of reusable components, helpful design guidelines and much more
2. We’re building a central design team to bridge the design competency gaps, such as visual design, motion, illustration and system design
3. We’ve established several avenues for our designers to share their work for greater visibility and alignment including a well-structured design critique, jamming sessions and a monthly design showcase
4. We’ve killed our design had-off as a single event in time. Our designers now evolve their hi-fi prototypes with their engineers — not in a silo

For further reading, I recommend these stories.

• The what and why of design debt
• How to tackle design debt
• Why addressing design debt may be your biggest payoff

I hope you’d find some of these insights useful in tackling the design debt in your product.

Until the next story, ciao!