I led a zero-to-one shared design system build across two organizations with a kickoff workshop ran by Brad Frost, boosting communications, efficiencies, scalability and consistency across orgs.
Role.
Design leadership
End-to-end visuals
Teams facilitator
Team.
Product Design
Brand
Engineering
Duration.
8 week workshop
Ongoing build
one DS to rule them all
CoinDesk's initial design system was neglected, unscalable and ultimately abandoned on the engineering side. The CMS templates were rigid and in overabundance. Additionally, there were duplicate efforts building and maintaining design systems across CoinDesk and parent property, Bullish.
How might we create a scalable and efficient platform?
The CoinDesk and partnering Bullish design teams would rebuilt a shared design system from the ground up, prioritizing scalability—ensuring that our design solutions support rapid content creation and stay consistent across the org as well as individual brands.
supervised_user_circle
As a leader, I…
Pitched and secured executive buy-in for a shared design system across multiple brands
Led a distributed team of remote in-house designers and contractors
Collaborated with procurement on budgeting for new tools and training
Built alignment with Bullish’s product design director and creative VP to unify team dynamics
Rolled out new tools and formalized cross-functional collaboration channels
Co-led an 8-week design workshop—set agendas, facilitated sessions, and defined pilot initiatives
account_circle
As a contributor, I…
Designed assets and key flows for the initial pilot project
Created the majority of design modules and templates for componentization handoff
Defined foundational and mid-tier design system properties—from core elements like grid and spacing to brand-specific “recipes” for CoinDesk
Before diving into solutions, we needed a clear, shared understanding of the problems. Through stakeholder interviews, user research, audits, and analytics, we uncovered critical gaps in usability, content strategy, accessibility, and technical scalability. The site was trying to serve too many goals at once—resulting in a fragmented user experience, inefficiencies for internal teams, and missed opportunities to deliver real value. Our goal in discovery was to align on user needs, business priorities, and the foundational issues we had to solve before moving into design.
Design
The legacy design system was not atomic, scalable, nor utilizing design tokens or variables. Many components were being designed bespoke to any given project, creating more overhead and inconsistencies.
An example of inconsistencies through four sign up forms, all having different input forms, buttons, colors, positioning, sizings, messaging, etc.
Engineering
The legacy design system had long been abandoned on the engineering side as a result of ongoing site maintenance and lack of resources. Storybook component documentation did not match Figma files nor the live prooduction site, resulting in piece meal builds and upkeep, causing even more design/tech debt.
An example of the original (left) Storybook component documentation inconsistency with the (right) production site components.
Editorial
The editorial team was required to choose from a complex amount of rigid page templates in the CMS. Due to this and other CMS-related issues, the speed of publishing breaking articles was hindered, leading to missed opportunities to be the first to market with timely content and securing a position in Google’s Top Stories.
An example of Editorial's process of selecting through a long list of nuanced page template types just to publish a standard article.
Bullish organization
CoinDesk was acquired by Bullish and both design orgs were both at an entry point for new design systems. However, the teams were positioned to work more cross-collaboratively as many products and offerings were beginning to overlap. There was a lot of time being spent on each team solving for the same problems.
CoinDesk "Nomisma" Design System was specifically used for CoinDesk.com
Bullish "Cornea" Design System was specifically used for Bullish.com and their exchange product.
CoinDesk and Bullish design and engineering teams partnered closely to establish a set of guiding principles rooted in key opportunity areas. These principles became our north star, helping align cross-functional teams.
How might we create a scalable and efficient platform?
foundation
A shared foundation
Guiding Principle
Build a core system that unites teams across brands.
expand_content
Scalable solutions
Guiding Principle
Make components modular, tokens scalable, and the system adaptable.
brand_family
Flexible expression
Guiding Principle
Allow each brand to apply its own visual identity.
Approach
Though many of us had experience working with design systems, having a shared system between different brands/businesses raised a lot of questions.
Ultimately, to ensure the system could support both CoinDesk and Bullish without becoming bloated or brittle, we partnered with Brad Frost (the creator of "atomic design") and Josh Clark from Big Medium to run a series of working sessions. These helped us architect a foundation that balanced shared structure with brand-specific flexibility.
Brad and Josh joined us through eight weeks of Zoom, Figma/Figjam and Slack working sessions.
Ecosystem
We first mapped the full ecosystem: multiple brands, platforms, and end-user contexts. This gave us a clear picture of where consistency would add value — and where divergence was necessary.
Walking through the CoinDesk/Bullish ecosystem in Figjam for our first workshop session.
(Drag image to see more.)
Governance
We established a governance model that allowed for centralized ownership with distributed contribution. This ensured quality and alignment while empowering designers and engineers across both companies to iterate and evolve the system. Given our small design teams, we elected one "czar" from each design team (CoinDesk, Bullish and Global Creative) as the design system owner for their team/brand, while meeting weekly to ensure clear communications on publishing updates.
Having a working session in Figjam on design system governance across all design and engineering teams.
(Drag image to see more.)
Tokens, themes and recipes
We defined a semantic design token strategy to support foundational elements like color, spacing, and typography. Tokens were the connective tissue that allowed us to introduce themes — brand-specific expressions of a shared design language — enabling flexibility across products without compromising consistency.
To bridge the gap between system and product, we introduced a recipe layer: product-specific compositions built from core components. Recipes gave teams autonomy to move at their own pace while maintaining visual and functional cohesion. This approach helped us scale design across brands without bloating the core system.
Brad (Big Medium) laying out a strategy in Figjam for design tokens and their tiers/categories.
(Drag image to see more.)
As we moved into implementation, we began translating strategy into tangible tools and assets—establishing a functional foundation that could scale across teams. While the engineering team was aligned on the direction and had been key collaborators earlier on, shifting priorities pulled them into other business needs before the buildout was complete. As a result, design led much of the execution, focusing on structure, documentation, and usability across libraries. Engineering remained bought in, with plans to implement the system in code as part of a future phase.
Foundations design library
We defined the foundational styles that would serve as the shared default across all brand systems, creating a unified visual language rooted in clarity and scalability. These top-level design decisions were established using Figma variables, enabling consistency in core values like color, typography, spacing, and elevation—while still allowing downstream brand systems to layer on their own customizations.
Foundational color variables defined in Figma.
Shared viewport sizes for desktop, tablet and mobile across all brands and how it affects font sizes, defined in Figma variables.
Core components library
Built on top of the foundational styles, the core components—such as buttons, form fields, dropdowns, and other UI essentials—were designed to be shared across all brands. These components prioritized accessibility, responsiveness, and consistency, ensuring that teams could work faster with ready-to-use, reliable building blocks aligned to the system’s foundational design values.
Example of a few core components and their variants, such as drop downs, form fields, pagination and cards, created for scalability across brands.
Themes and "recipes"
Themes enabled each brand within the shared system to express its unique identity by customizing colors, typography, and other stylistic details—all without duplicating core components. This approach allowed rapid scaling and consistent brand experiences while minimizing redundant work.
Recipes, meanwhile, served as adaptable component compositions tailored for specific product needs or teams. They provided a flexible layer where product teams could innovate and create more complex, product-specific UI patterns, all while staying aligned with the core system’s foundations and design tokens. This balance helped maintain overall coherence while supporting the distinct needs of multiple brands and products.
An example of an account log-in form that can easily be rebranded between CoinDesk and Bullish by simply toggling the appearance theme in Figma.
A list of theme variables, enabling brand visuals to differ between brands without needing to recreate the core product. "Vanilla" was set as our default style, while CoinDesk, Bullish.com and Bullish Exchange were treated as three separate brand identities.
Documentation
For documentation, we leveraged Figma to provide light, accessible design guidance directly within the design environment, while engineering maintained component documentation and live examples in Storybook. To bridge the gap between design and development documentation, we began integrating Zeroheight as a single source of truth that could unify both perspectives. Although this integration was still a work in progress, it aimed to improve collaboration and ensure consistency across teams moving forward.
An example of design system documentation shown with semantic tokens, their roles and values for border foundations.
CMS components and templates
Specifically for CoinDesk, we developed predefined templates for standard page types—like the homepage and article pages—within the new CMS, Sanity.io.
These templates were built from a modular library of CMS components that empowered editorial and product teams to create or update pages using flexible, predefined building blocks. This reduced reliance on design and engineering, allowing teams to move more quickly without being blocked by sprint schedules.
An example of a timeline CMS component that can be used modularly across both an Events and Live Wire CMS page template.
