Turning a design system constraint into a shared way of working

The problem was bigger than a component library

ReVolve began with a delivery problem. Product teams were solving similar interface challenges independently, using different patterns, definitions and handoff practices.

There was no formal design system, no central source of truth and no dedicated engineering allocation to build one. Although there was executive support for the initiative, adoption depended on earning the trust of individual project leads and engineers.

The real challenge was not creating components. It was creating a shared way of working under real delivery pressure.

The core challenge was organisational as much as visual: I had to create adoption before I could create scale.

I diagnosed before I designed

Before defining the system, I looked for the recurring problems behind the visible inconsistency.

I mapped where teams were repeating decisions, where handoffs became ambiguous, which patterns created the most friction and which upcoming releases could benefit from shared solutions.

This helped separate symptoms from causes. The issue was not that teams lacked discipline. They lacked a shared language, a reliable decision framework and enough evidence that changing their process would make work easier.

I treated the design system as an internal product with users, adoption barriers and measurable value.

The constraints shaped the strategy

• No dedicated developer was available to complete the system.

• Components had to be delivered alongside active product work.

• Project leads had different priorities and release pressures.

• Engineers were initially cautious about changing established workflows.

• Adoption could not be assumed or mandated.

I prioritised problems, not components

Rather than designing a complete library in isolation, I prioritised work based on five questions:

1. Is this solving a real product problem?

2. Can the solution be reused across teams?

3. Will it reduce repeated decisions?

4. Does it improve accessibility or quality?

5. Can its value be demonstrated quickly?

This shifted the conversation from “Which components should we build?” to “Which recurring problems are expensive enough to solve once and reuse many times?”

The first priorities came from active product work. Each implementation became both a delivery contribution and a test of the emerging system.

Building the system through live product work

Every component had to prove itself in context.

I used upcoming releases as opportunities to create reusable patterns while still meeting immediate delivery needs. This made the system practical from the beginning: teams could see how a shared pattern solved a problem they already had rather than being asked to adopt an abstract future framework.

The process was iterative:

• Identify a recurring product problem.

• Explore the underlying causes and constraints.

• Design a reusable pattern.

• Validate it in a live product context.

• Improve the documentation and implementation guidance.

• Reuse the pattern in the next project.

This approach allowed the system to grow from evidence instead of assumptions.

Making the value visible to engineering

Engineering adoption improved when the system reduced effort in real work.

I focused on clarifying component behaviour, states, accessibility requirements and implementation expectations. Better definition reduced ambiguity during handoff and made the relationship between design decisions and technical implementation easier to understand.

The system helped create:

• Fewer repeated UI decisions.

• Clearer component states and behaviours.

• More predictable handoffs.

• More consistent implementation guidance.

• Reusable patterns that reduced future effort.

Adoption improved when the system reduced engineering effort in real work, not when it was presented as another set of rules.

Winning adoption one project lead at a time

Without formal ownership, adoption had to be earned.

I connected system priorities to work that project leads already needed to deliver. Instead of asking teams to pause their work and adopt a separate process, I positioned ReVolve as a way to make their current work clearer, faster and more consistent.

This meant adapting the adoption approach to each team while keeping the underlying principles consistent.

• Build relationships with project leads individually.

• Connect system priorities to upcoming releases.

• Create early advocates through successful delivery.

• Use evidence from one project to support adoption in the next.

• Make contribution and ownership easier for teams to understand.

The system became more credible each time a team experienced a measurable improvement.

Creating a foundation for consistent decisions

Once recurring patterns were understood, I established the foundations that would help teams make better decisions independently.

These included:

• Design principles and decision criteria.

• Typography, colour, spacing and layout tokens.

• Accessibility requirements at component level.

• Naming and usage conventions.

• Documentation standards.

• Rules for extending the system responsibly.

The goal was not to standardise every design decision. It was to make the important decisions clear, repeatable and easier to scale.

From personal advocacy to shared ownership

Initially, ReVolve depended heavily on my involvement. I had to explain the value, support implementation and resolve uncertainty directly with teams.

Over time, successful implementations changed that dynamic. Project leads began endorsing the system, engineers saw the practical benefits and teams became more confident using shared patterns without direct supervision.

The transition was gradual:

1. Initial resistance and local constraints.

2. Pilot components connected to active releases.

3. Visible improvements in speed, consistency and accessibility.

4. Project-lead endorsement and continued reuse.

5. Engineering adoption through demonstrated value.

6. Shared ownership of the system and its future direction.

Measuring the outcome

ReVolve created value beyond a more consistent visual language. It improved how design, product and engineering worked together.

The measurable impact included:

• More than 60% faster design execution.

• 25% faster development.

• Reduced duplication across design and engineering.

• More consistent product experiences.

• Improved accessibility across shared components.

• Greater confidence in cross-functional delivery.

The most important result was not the library itself. It was the decision-making system that formed around it.

Reflection: designing the conditions for better decisions

ReVolve reinforced that design leadership is not only about creating solutions. It is about creating the conditions for teams to make better decisions consistently, even when time, resources and formal authority are limited.

The work required diagnosis, prioritisation, negotiation, experimentation and communication as much as visual design.

Design leadership is measured by the quality of decisions a team can make without you in the room.

For me, ReVolve became a proof of how I lead as a Product Designer: by setting direction, working through constraints, building alignment and turning design strategy into measurable improvements for both teams and products.