At ShipServ, the design system project was not a cosmetic tidy-up. It was an operating model for reducing delivery friction across a fast-moving maritime technology platform. The problem was familiar: fragmented UI patterns, inconsistent component behaviour, duplicated design effort and a widening gap between Figma and production.
I had no interest in building a beautiful library that sat politely beside the real work. We needed a system that would improve speed, quality, governance and confidence at the same time. The result was Lighthouse: a shared language for design, engineering, product and delivery teams.
The measurable results were significant. Design time for new features fell by 75%, development time by 70%, and the effort needed for global design updates by 85%. But those figures only make sense in the context of what had changed operationally.
The real problem was design debt at product scale
ShipServ already had patterns, components and conventions. The difficulty was that they had drifted over time. Different teams had interpreted the framework differently, local workarounds had accumulated, and small inconsistencies had become structural debt. Buttons, colour usage, spacing, form behaviour and page layouts no longer expressed a single product language.
That debt showed up in predictable ways:
Designers spent time recreating common patterns because they could not trust the existing version.
Engineers had to reconcile ambiguous specifications and make decisions that should already have been shared.
QA cycles repeatedly surfaced visual differences, unsupported component states and inconsistent layout behaviour.
New joiners depended on tribal knowledge rather than documented standards.
Accessibility was harder to improve consistently because there was no reliable baseline to reuse.
The cost was not only aesthetic. It affected onboarding, delivery velocity and user trust. Every feature carried a small tax. No single tax looked alarming, which is exactly why they accumulated so successfully.
We built Lighthouse alongside product delivery
A common failure mode is to treat a design system as a large side project that competes with the roadmap. That often results in a long, expensive pause followed by a grand unveiling that teams do not have time to adopt. We took a different approach.
We built Lighthouse as an adjacent system. New foundations and components were created in parallel with live product work, then adopted progressively where they solved an immediate problem. The system had to earn its place in delivery rather than asking people to trust in a distant payoff.
Four decisions made that practical:
Audit first, rebuild second. We reviewed the live product, Figma files, variants, colour usage, accessibility issues and duplicated patterns before deciding what to standardise.
Treat foundations as product decisions. Typography, colour, spacing, interaction states and naming conventions were infrastructure, not a design-team preference.
Connect design and code early. We aligned Figma components with Storybook so the system could support implementation, not merely describe it.
Document use, not only appearance. Each component needed guidance on purpose, anatomy, behaviour, variants, accessibility and when not to use it.
What changed in day-to-day work
The biggest shift was behavioural. Designers stopped treating each feature as a blank canvas and started assembling from trusted patterns. Engineers had clearer expectations for component behaviour. Product managers could discuss interface options with a shared vocabulary. Critique became less about preference and more about system fit, accessibility and the user outcome.
That is where design systems create leverage. A mature system compresses routine decisions so a team can spend more energy on the genuinely hard problems: workflow design, information architecture, edge cases and domain complexity. Nobody needs a meeting to decide which of six almost-identical buttons is the “real” one.
Why the gains were measurable
The 75% reduction in design time for new features came from reuse. Teams no longer recreated common interface patterns or repeatedly made the same visual and interaction decisions. The 70% reduction in development time came from clearer specifications, reusable coded components and less translation between design and engineering. The 85% reduction in effort for global updates came from having a single source of truth rather than a scavenger hunt across screens and codebases.
We also reduced recurring QA problems related to visual inconsistency, unsupported states and ambiguous layout behaviour. The deeper benefit, though, was confidence. Designers could move quickly without lowering standards. Engineers could implement with fewer assumptions. Stakeholders could see that consistency, accessibility and pace were not competing priorities when the underlying system was strong enough.
What I would advise design leaders to measure
“We built a design system” is not a result. Treat the system as a product and measure whether it improves the work around it. The most useful measures will vary by organisation, but I would look at:
Design cycle time for comparable feature work.
Component adoption and the reuse of approved patterns.
Production parity between design and implementation.
Accessibility issues and recurring UI defects.
Time and effort required to make a global product change.
Confidence and friction reported by the teams using the system.
The final point is easy to dismiss because it is less tidy than a dashboard metric. Do not. If using the system is harder than copying an old component, people will quietly return to the old behaviour. Adoption has to be easier than avoidance.
A system is a platform for scaling judgement
Lighthouse worked because we did not position it as a visual refresh. We framed it as a way to improve the mechanics of product delivery: fewer repeated decisions, clearer standards, better collaboration and a more coherent customer experience.
For me, that is the real promise of a design system. It is not a library of components. It is a platform for scaling judgement—so the team can move faster without losing the quality that made the product worth using in the first place.
See more of the work in my ShipServ design-system case study.
