One practice, three organisations
I have led design-system work across Canonical, Mention Me and Lansweeper. Each organisation needed a different starting point; each needed design and engineering to take responsibility for the same product language.
Led design-system definition and delivery across enterprise cloud, IoT and embedded-product work.
Kickstarted the design system in collaboration with Engineering while expanding the design and research team.
Led the working group, product UI redesign and migration, with adoption tracking and internal enablement.
Two organisations, two starting points
Canonical and Mention Me made the same underlying problem visible in different ways. A component library could create surface consistency, but it did not automatically create shared ownership, a contribution model or a product language that included the people using the software.
From an engineering framework to a product system
Vanilla provided a strong technical foundation, but the work was largely engineering-driven. Consistency followed implementation, designers did not share clear ownership, and a system created primarily for websites had to stretch across complex cloud, IoT and embedded-product applications.
My role was to help move the conversation beyond visual reuse: product designers needed to shape the system with Engineering, and interaction decisions had to work across technical products rather than a collection of pages.
From a React library to a shared practice
Mention Me had reusable code, but not yet a functional design system. The React library primarily served engineers, bespoke implementations still appeared and responsibility was distributed across teams without a clear contribution path.
I initiated the design-system work with Engineering while growing the design and research practice. We explicitly reframed the system around three audiences: designers, engineers and, ultimately, the users who experience every decision those teams make.
Turn contribution into an operating model
The response was not to centralise every decision in UX. We revisited the working group so Brand, UX, visual design, development and project leadership could contribute through one visible process. A proposal moved from triage into working-group validation, ownership, readiness for development and documentation.
Documentation had its own quality path. UX specification, visual specification and implementation were checked for completeness and accessibility; work could be published when ready or remain explicitly in progress while it was tested and refined. This made the state of a component visible instead of relying on informal knowledge.
Make progress measurable — and keep the process adaptable
I helped the working group focus on the most important outcome, act on lead measures, keep a visible scoreboard and review progress at a regular cadence. Together, we closed roughly 700 issues through triage and defined an initial programme of ten components.
We also set a target of making design and implementation three times faster. That was a programme ambition, not a measured result, and gave us a direction for testing efficiency.
The operating rhythm also changed when the first version proved too narrow. A two-week design-system sprint became a six-month cycle with allocated system time. The lesson was important: involve the whole team in shaping the practice, demonstrate the behaviour you want, and make the process helpful rather than restrictive.
The Lansweeper chapter
I led the cross-functional work behind a design system that gave Lansweeper a shared language for product design and front-end implementation. It became the foundation for a new UI across the product: more coherent for customers, more accessible by default and easier for teams to extend without reinventing established patterns.
The goal was never a prettier component library. It was to make the right product decisions easier to repeat.
The situation
As the product expanded, teams were solving similar interface problems in different ways. Components and patterns could take too long to design and build. Visual and interaction drift increased customers’ cognitive load, created rework and made accessibility harder to guarantee consistently.
Figma, React and Storybook needed to describe the same product language - not three approximate versions of it.
Building a system people could use
Room to grow.
Reusable foundations connect design decisions to the product teams that ship them.
System architecture · schematic<Component
state="ready"
/>ImplementationAudit · define · review · document · adopt
A working group with real ownership
At Lansweeper, I established the design system as a cross-functional product rather than a UX library. The working group brings UX together with front-end and QA engineers. Regular working sessions, a dedicated collaboration channel and visible requests give product teams a route into the system instead of asking them to work around it.
The group owns both decisions and follow-through: what enters the system, how it behaves, how accessibility is reviewed, how the component is represented in Figma and React, and how teams learn that it exists.
Start with real product use cases
We begin from the product rather than an abstract catalogue. For each component or pattern, the group audits existing implementations, maps prominent and edge use cases, checks Figma and Storybook, and asks whether a new component is really needed.
Use one definition of done across disciplines
The workflow moves through audit and use cases, definition and benchmarking, wireframe exploration, visual design, documentation and implementation. Peer review happens throughout. Accessibility is addressed while the interaction and visual behaviour are being defined, not added as a final compliance pass.
Close the Figma-to-code gap
Design-side and code-side components are aligned so that a component has the same name, anatomy and intent in Figma and React. Storybook makes implementation and states inspectable; documentation covers composition, constraints, edge cases and accessibility rather than presenting only a happy-path visual.
The decision before the component
The workflow starts by collecting the versions already in the product and asking what problem each one solves. The group examines prominent and edge use cases before deciding whether to add a variant, combine patterns or avoid a new component altogether.
This turns a request for “another component” into a shared product decision. The library grows around useful distinctions, rather than every local preference.
Review the uncomfortable states
The documented workflow asks the team to stress-test a component before visual sign-off. Anatomy, composition rules and edge cases come first. Visual design then brings in accessibility review, followed by reviewed documentation. The same component needs to make sense to the designer selecting it and the engineer implementing it.
Migrating the product, not just the library
The system became the basis for UI 2.0 across Lansweeper. I led the UX side of the redesign and coordinated the migration through adoption tracking, enablement and collaboration beyond the core working group.
This was wider than reskinning screens. Navigation and information architecture were reorganised around clearer groupings; interaction patterns and controls were standardised; accessibility requirements were carried at component level; and a modern front-end foundation supported performance, scalability and dark-theme behaviour.
The working group remained the connective tissue during migration. Product teams could raise needs and edge cases, the system team could distinguish reusable patterns from local exceptions, and adoption work made gaps visible. Enablement sessions and shared channels helped the organisation understand not only which component to use, but why the product was changing.
What changed
| Before | After |
|---|---|
| Similar UI problems were often solved locally. | Reusable components and patterns gave teams a common starting point. |
| Figma, React and documentation could drift. | The working group aligned design, code and Storybook around one shared language. |
| Accessibility was vulnerable to feature-by-feature variation. | System-level standards and review made it more repeatable. |
| New UI work depended heavily on individual interpretation. | Teams could use documented constraints, patterns and components with more confidence. |
What the system made possible
The concrete result was a shared Figma and React/Storybook foundation supporting the Lansweeper UI redesign. My role extended to coordinating migration, tracking adoption and running enablement sessions with the wider organisation.
The system also changes where teams spend their attention. Reusable, tested foundations reduce repetitive design, implementation and QA decisions; UX can invest more time in problem framing and validation, while Engineering can build on known interaction and accessibility patterns.
That foundation also enabled Code-Native UX: component semantics and usage rules could become context for AI-assisted front-end generation. Consistency had to exist across design and code before generation could reliably use it.
What I learned
Design systems succeed when they reduce decisions without reducing judgment. The strongest system is not the one with the most components; it is the one teams trust enough to use by default, and customers experience without noticing it is there.
That trust comes from solving real product problems with teams, giving Engineering a genuine role in the system and treating documentation, governance and accessibility as product work.