Crystal Design System
The Design System, born out of a need for consistency, efficiency, and scalability.
As our product expanded, keeping design in check across various teams and platforms got pretty tricky. We aimed to create a unified design system that would simplify things, reduce visual inconsistencies, and make it easier for developers and designers to collaborate., born out of a need for consistency, efficiency, and scalability.
Role
UX/Visual Designer
Duration
November 2022 - Sept 2024
Client
Internal (ApplyBoard Inc.)
Methodologies
Responsive Design, Figma Component Libraries, Design Tokens, Design-Development Handoff, WCAG Accessibility Compliance
Tools
Figma, Atlassian Jira/Confluence, Storybook, Chromatic
.png)
Research phase
The foundation of the Crystal Design System 2.0 began with thorough research to point out the need for a unified and scalable design solution at ApplyBoard. During this journey, designers and developers teamed up closely to make sure we were all on the same page with our design goals and technical needs right from the get-go.
Collaborative Framework & Design Strategy
The process of selecting the right headless UI framework and designing a clear API structure were crucial in setting the design direction for the Crystal Design System. Both design and development teams collaborated to find a solution to make sure that the design system aligned with ApplyBoard's goals and made future development a breeze.
Deciding on the Headless UI Library for Crystal
After checking out with various headless UI library, we decided to go with Radix UI for Crystal 2.0. It really stood out because of its accessibility features, flexible APIs, and how well it works with React. This decision gives the design team full control over the visual style without being held back by pre-built themes. yet, we’re also looking at how we can recreate some handy Material UI components to keep our responsive design consistent.
Theming & API Design Alignment
For Crystal 2.0, we focused on building a flexible theming system while keeping the API simple and easy to work with. By using Material UI’s internal theming, we stayed in control of the design but kept things simple for developers.
On the API side, We created our own theming API to make future upgrades smoother and kept things user-friendly and consistent. For example, with our button component, we set clear options like size, intent, and content to keep the design uniform and easy to manage.
Design Approach & Research
With the above decisions made, our design team dove into various design systems to help shape Crystal'’s concepts & overall look and feel. Checking out Radix and Material UI gave me a clear picture of what flexibility and customization could look like, while exploring the Carbon Design System opened my eyes to some great guidelines and patterns. All of this gave me the insights I needed to create a design system that feels fresh, is easy to use, and can grow alongside our different teams.
Scope & planning
To kick off the Crystal Design System, we mapped out a clear plan. We started by creating a cohesive theme, ensuring everything looked sharp.
Next, we focused on layout components, following a clear plan and keeping accessibility in mind. We simplified all the needed action items by picking one reliable library and plan to make everything easy to explore in Figma and Storybook with useful examples.
Our aim was to keep the process organized and collaborative for the entire team.
Design phase
In the design phase, we took what we learned from our research and started considering sets of styles, themes, and guidelines to design each component. This way, we help ensure everything looks and feels consistent while also being user-friendly and accessible for everyone.
Define Design Principles
Before we jump into designing, it was important to set some core principles to help guide our choices and keep everything consistent and user-friendly in the Crystal Design System.
Accessibility
Accessibility is crucial for CDS. We want to make sure ApplyBoard's products are easy for everyone to use. From colour contrast to keyboard navigation, so that every part of the design creates an inclusive experience for all users.
Scalability
CDS is built to scale, supporting multiple teams and domains while keeping the user experience consistent, by creating reusable components, CDS easily adapts to every team’s growth and changing product needs.
Clarity
Clarity in design means having clear and consistent UI patterns, coherent colour systems, and well-defined variables. The name "Crystal" perfectly captures our focus on precision and transparency, making it easy to implement and maintain.
Build Design Components
We chose the Atomic Design methodology since it helps us organize our components in a way that makes everything easier to manage and scale. It breaks things down into a hierarchy—starting with simple elements like buttons (atoms) and building up to more complex structures like tables (organisms). This approach ensures consistency across the system while allowing us to easily make updates or add new features, keeping the design flexible as we continue to develop and expand Crystal 2.0.
Laying the Foundation: Atoms
These are the basic building blocks, like individual buttons, text fields, single checkboxes, and avatars. Each of these elements is simple and reusable on its own, forming the core foundation of the UI.
Bringing Elements Together, Molecules
Here, we combine atoms to create slightly more complex components, like notifications, file upload sections, tab bars, or phone input fields. These molecules show how different atoms work together to perform a specific function.
Shaping the Experience, Organisms
Organisms are larger and more complex structures, made up of multiple molecules and atoms. Examples include tables, dialogs, and navigation bars. These components play a bigger role in shaping the user experience across the entire UI.
Creating Figma variants
Once we nailed down our basic building blocks, we applied Figma variants to make each component more systematic. This feature allows us to create one component that showcases different options like intent, emphasis, size, and state. For example, for buttons, Intent refers to the purpose of the button and signals a different action or priority level, guiding users on what to do next. Emphasis affects how the button stands out in the UI to help users easily identify which actions are more important or urgent. State shows users how the button behaves as they interact with it, and provides feedback, for a smooth and intuitive user experience.​
​By using Figma variants, we keep everything organized and easily maintain consistency while allowing for flexibility to tweak things as needed. This way, we can create buttons that not only look great but also clearly communicate their purpose and function to users.
Set up a style guide
The next key step was to create a style guide to keep things consistent across the design system, which included Figma guidelines, overall styles like color and typography, and documented patterns for common user issues.
Creating a user-friendly guideline
We put together a simple, easy-to-follow guideline for designers on how, when, and what to use within the design system. I took all the Figma setup variants and turned them into one clear document that covers everything—intents, states, best practices, style tokens, accessibility, and how the components are built. This guide helps keep everything consistent while making it easier for designers to know what works best in different use cases. (click the top-right arrows above the image to see more)
Styles & themes
Next up is setting the overall styles and themes, including color, layout & spacing, and typography. This keeps everything consistent and on-brand, and covers components are used in different containers like cards or at the page level. We based this style guide on the marketing-focused brand guidelines but tweaked it to better fit web and product usage, prioritizing usability. We made sure layouts and typography are responsive, adjusting smoothly to any screen size. With these solid foundations in place, it makes the process of building templates easier and more streamlined down the road. (click the top-right arrows above the image to see more)
Patterns
While components are our go-to building blocks for quickly piecing together the UI, patterns outline the reusable ways we tackle common user issues. We figured it would be neccessary to document these patterns in writing. For example, a text input on its own is just a component, but when we add form validation, we establish a pattern that guides users in correcting their input errors. By combining these documented patterns with our components and design tokens, we create a smooth visual experience that users can resonate with. (click the top-right arrows above the image to see more)
Stay connected
Once we wrapped up the design phase, it was all about staying connected. Keeping designers from different domains in the loop with regular updates made sure everything stayed consistent. On the development side, staying synced with Storybook updates was key to making sure everything was implementation-ready. This ongoing communication between design and development teams helped keep things running smoothly.
Intake processes across domains
We kept domain designers and their dev teams in the loop to make sure their unique needs were addressed. It was about creating components that worked perfectly for their specific domain but still fit within the bigger system.For example, when a UI component was specific to a particular domain, the domain teams would handle it internally. But if the component was useful across different teams, it needed to be global.
In those cases, the process involved requesting the component to be added to the Crystal Design System. Designers would submit the request with details on how the component would benefit other teams, and the UIE team, along with marketing, would assess and approve its inclusion. This approach made sure Crystal remained flexible and scalable, supporting both domain-specific and global needs.
Align with UIE engineers
At the same time, the UIE engineers and designers made sure everything stayed consistent across domains. They kept the Crystal Design System tight and cohesive, making sure both global and domain-specific components followed the same design rules and stayed scalable.
Scope & planning
The first step was figuring out the scope and how we’d approach syncing Figma and Storybook. We started by identifying which components were missing or outdated, and what steps we needed to take to get them in sync. Each designed component was scored based on a few factors, such as, whether it matched between Figma and Storybook, if assets were properly exported to the library, and etc. This gave us a clear idea of what needed updating and helped us prioritize the work.
Creating micro tasks
Once we nailed down the scope, we broke everything into actionable micro-tasks and created tickets for each one. This made it easier for both designers and engineers to track which components, patterns, and documentation were still in progress. Each ticket required approval from core team members before being marked as resolved and closed, making sure everyone stayed aligned.
