Reducing Design Debt with a Design System

Since the start of the Jumbo Tech Campus, we’re starting to increase the number of touchpoints that our customers can interact with. In the past, we primarily focused on our e-commerce app and website. Today, we have more and more touchpoints focusing on both our digital and in-store customers.

Customers use multiple touchpoints in a single shopping journey. Therefore, at Jumbo, we believe all our touchpoints should look, feel and work in a similar way. Our products and services should be predictable and easy to understand. There should be no visual surprises whether the user is on our website or using the self scanner in the store.

The goal is to create a seamless omnichannel experience.

By having more touchpoints and teams operating these touchpoints, the obvious thing happens. Deviation. Design debt is real and starts to grow if not properly maintained.

Design debt

Design debt is similar to technical debt. It happens when teams make the decision to deliver quickly when there is a better solution at hand. There’s a benefit to this approach since teams deliver user and business value fast and we start to learn what solutions work for our customers.

Moving quickly comes at the cost of long-term quality. When choosing a quick solution there’s a risk to drift away from the omnichannel experience we are striving for as described above.

As with money, debt has an interest rate and you should keep a close eye on it to avoid a collapse. This debt will have to be repaid.

A small example

Let me describe a story about 2 scrum teams. The Check Mates are responsible for the Checkout and the Login Lords are responsible for the login flow.

Team Check Mates

The Check Mates are working on fixing a user issue. They solve this issue by building a new UI pattern. They release this pattern in a quick way. As a result, the solution isn’t scalable or re-usable for other teams but the issue seems to be solved for now.

Team Login Lords

The Login Lords are working on a different part of the customer journey and face a similar user issue. Due to the scale of the organisation the team isn’t aware of the solution implemented by the other team. They decide to create their own solution. This solution solves a similar issue but the interaction and the look & feel is different from Team Check Mates.

This is the moment when Design Debt starts to impact the omnichannel experience. Users start to face different solutions and interactions in a single shopping journey when this isn’t necessary. Now imagine this happening across multiple scrum teams and on multiple touchpoints.

Inconsistency starts to create pain.

What just happened

• Time and money is spent twice since the solutions are built in 2 teams
• Design debt is increased due to quick solutions
• Customer confusion leads to fewer conversion rates
• The teams are not aware of similar solutions out there

This inconsistency not only starts to create pain for our customers but also leads to frustration among developers and designers.

A need to align solutions across teams starts to grow.

The 3 stages of design alignment

Stage 1: Spare timers

Both of the teams are doing a retrospective. Problems are brought up the table and ideas on how to resolve their problems are explored. As a result:

• Designers start to collaborate and document their design rationale and create Sketch Libraries that other designers can use.
• Developers refactor their code so other teams can benefit from there code as well.

These are good efforts but aren’t a solid, future proof way of working since the teams are also responsible to deliver value for the checkout and login flow. As a result, only a small percentage of their work is spent on design debt.

Stage 2: Allocate time

In the meantime, the organisation keeps on growing making it even harder to keep track of what all the teams are doing. Due to the limited time that these individuals can put into making components re-usable the design dept keeps on increasing.

The organisation needs to think about a more constructive way of working. Usually, scrum teams allocate a percentage of their effort on technical debt. We should do the same for design debt. Individuals across teams start to collaborate and work on the re-use and guidelines of UI components and patterns.

In this collaboration, the scope of the problem starts to increase. It becomes bigger than just the login or checkout flow. To maintain the omnichannel experience individuals have to focus on all touchpoints.

Stage 3: The design system team

The Design Debt is starting to decrease and the performance of the teams is increased due to the reusability of the work. The organisation starts to discover the potential of this collaborative work but still lacks continuity. A small percentage of time is not enough to build and maintain an entire eco-system of components.

In this stage, it makes sense to create a Design System Team that is focused on building and maintaining the design system. This team cooperates like all other teams with rituals, a product backlog and even a product owner.

Conclusion

A Design System Team solves design debt that growing organisations struggle with. Investing in a design system team will result in

• Focus for teams on business and user value
• Saving costs since we don’t reinvent the wheel
• Building a seamless omnichannel experience
• A central point of contact for our components