Context

As Coherent matured and we began to refine the product, inconsistencies in our interface started to become more noticeable. Similar components had different visual identities, styles were duplicated throughout the codebase, and updating our UI took longer than it should have

Even small UI changes required effort - developers would need to search for styles and I would need to confirm these against scattered documentation in Figma. We needed a single source of truth for design decisions so that everyone could work with more confidence

It became clear that we needed a system that could

• Bring consistency back into the product
• Reduce duplicated CSS
• Establish a clear source of truth for UI foundations
• Improve speed and confidence in frontend development

I led the design and implementation of a new design system from the ground up - defining tokens, establishing naming conventions, and building a component library that could scale as the product grew

My role

As the lead designer and decision maker on the project, I was responsible for defining the vision, principles and structure of the design system. I worked closely with a frontend developer to ensure that design and code remained aligned as decisions were made

My responsibilities included

• Defining the long-term direction and goals of the system
• Researching and building upon best practices
• Establishing token structure and naming conventions
• Designing core tokens including colour, typography and spacing
• Working with frontend to maintain alignment between Figma and the codebase
• Designing and documenting reusable components
• Setting standards for how the system would be adopted and maintained

This role was both strategic and hands-on. I needed to look at the product and team from a bird’s-eye view to make long-term decisions, and then jump into Figma and code to execute them

Principles & strategy

Before defining foundations or components, I established a set of principles that I could refer back to ensure the system remained coherent, and maintainable as it evolved. As the sole designer, staying within scope was crucial if I actually wanted to ship anything

I focused on building a system that was:

• Token-driven - expressing design decisions as reusable variables rather than hardcoded values
• A single source of truth - keeping Figma and code aligned to reduce ambiguity and duplication
• Accessible by default - ensuring colour, type, and interaction decisions met WCAG 2.1 standards
• Built for long-term maintainability - making decisions that would scale as the product and team grew
• Consistent but flexible - providing clear standards while supporting real product needs
• Documented as part of the system - treating guidance and rationale as primary outputs, not afterthoughts

I also started work on perhaps the hardest part of this project, choosing a name for the design system! I wanted something abstract but on the theme of coworking, so that it felt connected to Coherent. I didn’t have plans to make this a publicly accessible design system, so didn’t need to worry too much about the marketing benefit of the name

After throwing around a few ideas, and generally just testing for vibe, Hotdesk was born.

Foundations

With principles established, I defined a structured set of design tokens, creating a shared language between design and development. I introduced a layered token model - separating primitive, semantic, and component tokens - so that clear decisions could be made whilst still allowing for easy evolution of the system in the future

Tokens were defined across:

• Colour - establishing a refined palette and semantic roles for surfaces, borders, text, and patterns
• Typography - defining a clear type scale and hierarchy to support readability and consistency
• Spacing - introducing a consistent spacing system based on an 8px grid, to bring rhythm and predictability to layouts
• Radii and elevation - standardising shape and depth across components

Early colour palette exploration presented a challenge with sprawl. My initial colour set was broad, which made the interface feel visually busy and distracting during testing. By simplifying and rationalising the palette, I was able to create a clearer, more cohesive visual language

Token sprawl also emerged as components evolved. To address this, I introduced clearer categorisation for component tokens - for example defining shared tokens like $input-border-color-default that could be applied consistently across similar components like text inputs, dropdowns, and text areas. This drastically reduced duplication and made for a much more manageable system

Token architecture and design–code alignment

To ensure tokens could be reliably used in production, I worked closely with frontend to define how they would be structured and applied in the codebase. After researching existing design systems and emerging standards - including the Design Tokens Community Group (DTCG) specification - I proposed storing tokens in JSON as a way to create a clearer bridge between design and implementation. This helped translate decisions made in Figma into a format that could be consistently referenced in development, regardless of the device we were developing for

We aligned on naming conventions and set up a consistent, human-readable naming pattern where information becomes more granular with each level

Introducing JSON tokens helped speed up the development of new components and reduced back-and-forth between design and engineering. Because token names clearly expressed intent, frontend could apply them with confidence without needing constant clarification, improving both efficiency and trust.

Component library

With tokens in place, I started building a component library that could support real product needs while establishing consistent patterns across the interface

Each component was designed with clearly defined variants covering size, state, and behaviour, allowing teams to solve common problems without introducing new patterns unnecessarily

Rather than attempting to replace large areas of the existing UI, we introduced new components incrementally - allowing the system to grow naturally as features were developed. This approach reduced disruption while steadily improving consistency

By grounding components in shared tokens and clear naming, we created building blocks that felt predictable and easy to apply - reducing decision overhead and making future development more efficient

Adoption and rollout

Hotdesk was launched into production alongside a piece of work that added clarity to booking details - we created new drawer and key-value table components that became the test subjects for our new token library

Launching the system as part of new feature development allowed frontend to adopt tokens and patterns organically and put us in a good position for 360 degree feedback - design system developments would inform component updates, and new component development would highlight shortcomings in the design system

Impact and outcomes

The impact of Hotdesk was felt almost immediately. New UI components were being built more quickly, and interfaces were being assembled by developers with much more confidence. With each release, the benefits compounded — more tokens enabled more components, which unlocked new areas of the interface to refactor

Key outcomes included:

• Reduced duplication across design and frontend, with shared tokens replacing one-off styles
• Faster development of new components, supported by clear naming and reusable foundations
• Improved consistency across new features as patterns became easier to reuse
• Less back-and-forth between design and development, as decisions were easier to interpret and apply
• Increased confidence when making UI changes because updates were built on a stable foundation

Reflection

The biggest surprise for me was how quickly the benefits of this system became visible. Within just a few pieces of work, I could see frontend building with greater confidence and needing less clarification

Token and palette sprawl proved to be a natural part of the process. Catching this early allowed me to step back, simplify, and refine the system before complexity became harder to manage. This project also highlighted the importance of shipping early. Releasing the system alongside real feature work helped avoid getting stuck in a cycle of refinement and ensured the system could grow through practical feedback rather than speculation.

Leading the work largely independently was both challenging and clarifying. Having a clear set of principles to refer back to helped guide decisions, maintain focus, and ensure the system remained aligned with its goals.

This was a massive project for me and felt like the culmination of 7 years of design learning and experience. I’m very happy to finally see Hotdesk putting in the work and laying the foundation for the future of frontend development at Coherent