Angie

sebastian

Building Harmony

How We Crafted Our Crayon Design System from the Ground Up

team

Lead Product Designer

UI/UX Designer

1 Engineering Team

SKills

Design System

UI Audit

Cross-functional Team Collaboration

project duration

Initial Build (2023)Support (Q3 2024 - Ongoing)

backgrounD

When we set out to modernize our software, it quickly became clear that a simple UI refresh wouldn’t be enough. We needed a more consistent, scalable way to design and build—and that’s what led us to create our design system. We wanted a system that could bring everything together: a shared language for design and development, and a foundation we could build on for the long term.

 

This case study shares how we approached that challenge: from auditing our existing UI, to defining a new visual direction, to building a flexible system of components and tokens that could support our future roadmap.

process

Audit & Research

Defining the Foundation

Component Library

Documentation

Collaboration

Audit & Research

We conducted a full inventory of existing components and styles to identify inconsistencies, gaps, and opportunities for consolidation.

Screenshots from our legacy screens with inconsistent UI patterns.

Defining the Foundation

We established design tokens for color, spacing, and typography to create a consistent, scalable foundation across products and platforms.

 

Our token setup from Tokens Studio (third party plugin) that we migrated to Figma Variables (built-in Figma feature) later on.

Component Library

Using MUI as our base, we built and customized core components to match our design language. Clear naming, structure, and usage guidelines ensured consistency and ease of use.

Figma components for design use and Storybook components for developer consumption.

Collaboration and Feedback Loops

We worked closely with cross-functional teams and shared progress early and often. Feedback loops helped us iterate quickly and build trust in the system.

An example of a Component Testing Session where designers test the components for bugs and suggest ways for improvement.

Documentation and Handoff

Each component includes clear usage guidelines, states, and examples. Once documented, components are handed off and implemented in Storybook as interactive, developer-ready assets.

Example of a component handoff document

impact

Here’s how the design system has made a difference in how we build, ship, and scale our products.

Gave Designers the Speed to Focus on What Really Matters

Our Crayon design system significantly sped up the creation of high-fidelity mockups. With ready-to-use, consistent components, it allowed us, the designers, focus more on solving user problems and less on pixel-pushing or reinventing patterns.

Example of how a component can be customized to fit specific requirements.

Helping Developers Build More Consistently

As part of a survey to understand developer opinions on the design system, 7 out of 11 developers shared that it effectively supported their project needs. Several noted it helped them code more efficiently and maintain consistency across both UI and code. Despite limited resources, support from the design system team was rated as excellent and issues were consistently addressed when raised.

A quick snapshot of the Crayon Design System Survey I sent to developers to better understand how they feel about using the components in their workflow.

8.36/10

Improving UI Consistency

Average dev rating on the effectiveness of the designs system in improving UI consistency

5/5

Support

Developers rated the support for the design system as outstanding.

4/5

Overall Quality

Developers gave the design system high marks for overall quality.

A System That Allows Us to be Flexible and Continuously Improve

Our design system strikes a balance between consistency and flexibility. It helps teams move faster while keeping the user experience cohesive. Since it’s a living system, it grows and improves through ongoing feedback and real-world use. It continues to adapt as our products and team needs evolve. This flexibility also empowers us to build custom components when needed, without being fully dependent on MUI.

A notable example of a component we designed from scratch is the Thick Flood Bar.

Challenges

The design system is seen as strong overall, but like any evolving tool, it’s not perfect and there’s still room to grow and improve in a few key areas.

When Components Get Complicated

As components become more complex, Storybook implementations can sometimes drift from the intended design. Customizations, especially those that involve changing a component’s internal structure can be tricky for developers and often need support from the Crayon team. Some tweaks are more straightforward and quick to implement, but even simple fixes can introduce dependencies that create long-term maintenance challenges, which we generally try to avoid.

When Design Components Fall Short of Product Needs

While the design system aims to cover the most common use cases, there are instances where components don't fully meet specific product requirements. This misalignment can stem from unique functionality, layout constraints, or edge cases that weren't considered during initial design. As a result, teams needed to extend or work around the existing components.

 

mention: non-existent dev team to maintiain component

What I Learned

Finally you arrive at the ending of the article. This is a good place to wrap things up and conclude with takeaways. If you’re writing something for a more traditional publication, it can be nice to end on an anecdote that mirrors the theme of the piece. If you’re putting together some content for a company blog, you’ll probably just want to close out in a tidy way and include a CTA of some kind. Writers should take note: Usually, when you write a draft, you finally get to the main point at the end. An old editing trick is to take that idea and put it at the top of the piece. Consider whether that would work for you in this case.

Previous Case Study

Next Case Study

Let’s work together

Angie

sebastian

Building Harmony

How We Crafted Our Crayon Design System from the Ground Up

team

Lead Product Designer

UI/UX Designer

1 Engineering Team

SKills

Design System

UI Audit

Cross-functional Team Collaboration

project duration

Initial Build (2023)Support (Q3 2024 - Ongoing)

backgrounD

When we set out to modernize our software, it quickly became clear that a simple UI refresh wouldn’t be enough. We needed a more consistent, scalable way to design and build—and that’s what led us to create our design system. We wanted a system that could bring everything together: a shared language for design and development, and a foundation we could build on for the long term.

 

This case study shares how we approached that challenge: from auditing our existing UI, to defining a new visual direction, to building a flexible system of components and tokens that could support our future roadmap.

process

Audit & Research

Defining the Foundation

Component Library

Documentation

Collaboration

Audit & Research

We conducted a full inventory of existing components and styles to identify inconsistencies, gaps, and opportunities for consolidation.

Screenshots from our legacy screens with inconsistent UI patterns.

Defining the Foundation

We established design tokens for color, spacing, and typography to create a consistent, scalable foundation across products and platforms.

 

Our token setup from Tokens Studio (third party plugin) that we migrated to Figma Variables (built-in Figma feature) later on.

Component Library

Using MUI as our base, we built and customized core components to match our design language. Clear naming, structure, and usage guidelines ensured consistency and ease of use.

Figma components for design use and Storybook components for developer consumption.

Collaboration and Feedback Loops

We worked closely with cross-functional teams and shared progress early and often. Feedback loops helped us iterate quickly and build trust in the system.

An example of a Component Testing Session where designers test the components for bugs and suggest ways for improvement.

Documentation and Handoff

Each component includes clear usage guidelines, states, and examples. Once documented, components are handed off and implemented in Storybook as interactive, developer-ready assets.

Example of a component handoff document

impact

Here’s how the design system has made a difference in how we build, ship, and scale our products.

Gave Designers the Speed to Focus on What Really Matters

Our Crayon design system significantly sped up the creation of high-fidelity mockups. With ready-to-use, consistent components, it allowed us, the designers, focus more on solving user problems and less on pixel-pushing or reinventing patterns.

Example of how a component can be customized to fit specific requirements.

Helping Developers Build More Consistently

As part of a survey to understand developer opinions on the design system, 7 out of 11 developers shared that it effectively supported their project needs. Several noted it helped them code more efficiently and maintain consistency across both UI and code. Despite limited resources, support from the design system team was rated as excellent and issues were consistently addressed when raised.

A quick snapshot of the Crayon Design System Survey I sent to developers to better understand how they feel about using the components in their workflow.

8.36/10

Improving UI Consistency

Average dev rating on the effectiveness of the designs system in improving UI consistency

5/5

Support

Developers rated the support for the design system as outstanding.

4/5

Overall Quality

Developers gave the design system high marks for overall quality.

A System That Allows Us to be Flexible and Continuously Improve

Our design system strikes a balance between consistency and flexibility. It helps teams move faster while keeping the user experience cohesive. Since it’s a living system, it grows and improves through ongoing feedback and real-world use. It continues to adapt as our products and team needs evolve. This flexibility also empowers us to build custom components when needed, without being fully dependent on MUI.

A notable example of a component we designed from scratch is the Thick Flood Bar.

Challenges

The design system is seen as strong overall, but like any evolving tool, it’s not perfect and there’s still room to grow and improve in a few key areas.

When Components Get Complicated

As components become more complex, Storybook implementations can sometimes drift from the intended design. Customizations, especially those that involve changing a component’s internal structure can be tricky for developers and often need support from the Crayon team. Some tweaks are more straightforward and quick to implement, but even simple fixes can introduce dependencies that create long-term maintenance challenges, which we generally try to avoid.

When Design Components Fall Short of Product Needs

While the design system aims to cover the most common use cases, there are instances where components don't fully meet specific product requirements. This misalignment can stem from unique functionality, layout constraints, or edge cases that weren't considered during initial design. As a result, teams needed to extend or work around the existing components.

 

mention: non-existent dev team to maintiain component

What I Learned

Finally you arrive at the ending of the article. This is a good place to wrap things up and conclude with takeaways. If you’re writing something for a more traditional publication, it can be nice to end on an anecdote that mirrors the theme of the piece. If you’re putting together some content for a company blog, you’ll probably just want to close out in a tidy way and include a CTA of some kind. Writers should take note: Usually, when you write a draft, you finally get to the main point at the end. An old editing trick is to take that idea and put it at the top of the piece. Consider whether that would work for you in this case.

Previous Case Study

Next Case Study

Let’s work together

Angie

sebastian

Building Harmony

How We Crafted Our Crayon Design System from the Ground Up

team

Lead Product Designer

UI/UX Designer

1 Engineering Team

SKills

Design System

UI Audit

Cross-functional Team Collaboration

project duration

Initial Build (2023)Support (Q3 2024 - Ongoing)

backgrounD

When we set out to modernize our software, it quickly became clear that a simple UI refresh wouldn’t be enough. We needed a more consistent, scalable way to design and build—and that’s what led us to create our design system. We wanted a system that could bring everything together: a shared language for design and development, and a foundation we could build on for the long term.

 

This case study shares how we approached that challenge: from auditing our existing UI, to defining a new visual direction, to building a flexible system of components and tokens that could support our future roadmap.

process

Audit & Research

Defining the Foundation

Component Library

Documentation

Collaboration

Audit & Research

We conducted a full inventory of existing components and styles to identify inconsistencies, gaps, and opportunities for consolidation.

Screenshots from our legacy screens with inconsistent UI patterns.

Defining the Foundation

We established design tokens for color, spacing, and typography to create a consistent, scalable foundation across products and platforms.

 

Our token setup from Tokens Studio (third party plugin) that we migrated to Figma Variables (built-in Figma feature) later on.

Component Library

Using MUI as our base, we built and customized core components to match our design language. Clear naming, structure, and usage guidelines ensured consistency and ease of use.

Figma components for design use and Storybook components for developer consumption.

Collaboration and Feedback Loops

We worked closely with cross-functional teams and shared progress early and often. Feedback loops helped us iterate quickly and build trust in the system.

An example of a Component Testing Session where designers test the components for bugs and suggest ways for improvement.

Documentation and Handoff

Each component includes clear usage guidelines, states, and examples. Once documented, components are handed off and implemented in Storybook as interactive, developer-ready assets.

Example of a component handoff document

impact

Here’s how the design system has made a difference in how we build, ship, and scale our products.

Gave Designers the Speed to Focus on What Really Matters

Our Crayon design system significantly sped up the creation of high-fidelity mockups. With ready-to-use, consistent components, it allowed us, the designers, focus more on solving user problems and less on pixel-pushing or reinventing patterns.

Example of how a component can be customized to fit specific requirements.

Helping Developers Build More Consistently

As part of a survey to understand developer opinions on the design system, 7 out of 11 developers shared that it effectively supported their project needs. Several noted it helped them code more efficiently and maintain consistency across both UI and code. Despite limited resources, support from the design system team was rated as excellent and issues were consistently addressed when raised.

A quick snapshot of the Crayon Design System Survey I sent to developers to better understand how they feel about using the components in their workflow.

8.36/10

Improving UI Consistency

Average dev rating on the effectiveness of the designs system in improving UI consistency

5/5

Support

Developers rated the support for the design system as outstanding.

4/5

Overall Quality

Developers gave the design system high marks for overall quality.

A System That Allows Us to be Flexible and Continuously Improve

Our design system strikes a balance between consistency and flexibility. It helps teams move faster while keeping the user experience cohesive. Since it’s a living system, it grows and improves through ongoing feedback and real-world use. It continues to adapt as our products and team needs evolve. This flexibility also empowers us to build custom components when needed, without being fully dependent on MUI.

A notable example of a component we designed from scratch is the Thick Flood Bar.

Challenges

The design system is seen as strong overall, but like any evolving tool, it’s not perfect and there’s still room to grow and improve in a few key areas.

When Components Get Complicated

As components become more complex, Storybook implementations can sometimes drift from the intended design. Customizations, especially those that involve changing a component’s internal structure can be tricky for developers and often need support from the Crayon team. Some tweaks are more straightforward and quick to implement, but even simple fixes can introduce dependencies that create long-term maintenance challenges, which we generally try to avoid.

When Design Components Fall Short of Product Needs

While the design system aims to cover the most common use cases, there are instances where components don't fully meet specific product requirements. This misalignment can stem from unique functionality, layout constraints, or edge cases that weren't considered during initial design. As a result, teams needed to extend or work around the existing components.

What I Learned

Finally you arrive at the ending of the article. This is a good place to wrap things up and conclude with takeaways. If you’re writing something for a more traditional publication, it can be nice to end on an anecdote that mirrors the theme of the piece. If you’re putting together some content for a company blog, you’ll probably just want to close out in a tidy way and include a CTA of some kind. Writers should take note: Usually, when you write a draft, you finally get to the main point at the end. An old editing trick is to take that idea and put it at the top of the piece. Consider whether that would work for you in this case.

Previous Case Study

Next Case Study