# UX Design
Why Building the Design System
A Design System for Dispersed Projects
The team (Visual Analytics, VA) I worked with primarily focused on UIX design. VA functions as an independent service provider, collaborating with another developer group (Software Directorate, SD) to tackle different project-specific challenges. As a result, the projects VA worked on were highly diverse. Of the VA-owned projects, only 1/3 of them shared the same branding. The branding of the remaining 2/3 projects were totally dispersed, with different clients requesting solutions tailored to specific tasks or purposes. Although these projects seemed dispersed, VA members noticed commonalities shared among these projects and believed the internal work efficiency could be improved.
Shared Elements Across Dispersed Projects
85% of these projects supported researchers of all kinds, including professors, clinical/medical workers, independent researchers, etc. - Design clarity and a professional look and feel were shared in common
80% of these projects involved aspects of data management, data visualization and interaction, map, survey, and project presentation. - We accumulated several legacy design practices along the way, which could potentially be reused in future projects.
77% of the solutions we developed were web-based, with minimal demand for responsive design. - The design system could potentially help us handle the responsive design extensively from the one design practice for web.
50% of these projects involved establishing initial problem solutions (0-to-1 development), we required fast iterations and efficient design processes. - Ideally we want to spend most of our time developing the UX, and would like the design system to simplify the UI works if possible.
In short,
Goal of the Design System
An Early Phase Design System Strategy
Since the design system project is still in its early phase, the developer group works independently, and VA group is a small team handling a large amount of projects, I suggested that the design system team focus on the minimal viable solution that we can do within VA for now, while encouraging more developers to join in and expand the solution to meet their needs in future stages.
The primary goal is to improve UIX design efficiency, freeing up more time for creative thinking and collaboration.
The secondary goal is to streamline communication with the dev team, enabling them to start faster and align more closely with the designs.
To Break Down the Goals
Efficiency: Offer reusable design elements for quick selection and use, covering the essential items designers need in common, and that of research-oriented projects share in common.
Flexibility: Provide enough flexibility for designers to customize components and reorganize design elements to fit each project's needs, which means to provide a rule of using root vs local component and a flexible token system.
Consistency: Ensure consistency within each project, serving designer-to-designer communication, and the initial designer-to-developer communication. This will result in the design system itself, file management methods, and an SOP for delivering a CSS token sheet to developers.
Reusability: Accumulate reusable components or other design assets for future use. Also landed in a rule of using root vs local component libraries.
Design System Implementation
TOOL
Color palette tools: OKLCH Color Picker & Converter, Huetone
Figma local variables (color and spacing)
MUI icon plugin (component base)
ChatGPT (UX writing)
TIMELINE
This is an ongoing project since I joined VA. I worked on it intermittently when there’s extra funding and time. Over the past 3 years, I also worked on another branding-focused design system and tried to integrate parts of it into this one for the VA group.
TEAM SETTING
Our design lead proposed the project, served as a consultant of actual implementation, and coordinated to get people involved in pushing the project forward.
All designers (6) and developers (4 frontend, 2 backend) in the VA group participated in the discussions.
I served as the lead problem solver.
MY ROLE
Led the design and implementation of the design system: designer kit and developer kit
Coordinated communication with the team, collected requirements from discussions.
Contributed to framing the project by:
Identifing and set boundaries for the problems the design system aimed to solve
Defining success criteria for the project
Shared approach to using the design system to onboard new designers
A representative to attend design system conferences and bring insights back to the group
PROCESS
Elaborated discussions and synthesized requirements, to frame the scope of the project.
Identified the frontend framework we use: React, MUI, and Tailwind
Since our developers primarily handled backend with React, thus designers primarily chose the MUI kit to simplify collaboration.
As a small team, we rely on a design library to avoid reinventing the wheel. However, to allow more design flexibility, we added Tailwind to customize MUI components.
Audited previous projects
Defined the design language based on the auditing.
Extracted essential components and commonly used VA specific components into a Figma file.
Extracted file management element, UX content creation process, etc. then documented them.
Created the token system and applied that to the component Figma file
Collaborated with one frontend developer to test the initial handoff process from design to dev
Documented everything
Design System Structure
The idea of the design system was built on a combination of Atomic Design and the team's specific workflow.
Since I previously worked on another design system project and developed a reusable structure for a clinical/medical branding-focused design system using PrimgNG, I was able to reuse some of it for the VA design system. This included the framework of the Foundation section, several components in the Design Pattern, and VA Research-Oriented Assets group. For the selection and content in the Foundations and Assets section, I drew on the rationale from the previous project but adapted it to align with MUI and relevant resources.
But besides this, I also audited each designer's workflow and created the Scoping, Design Language, Guidelines and Design System Operations, ensure better maintenance of the design system.
Detail 1: DataVis Palette
Context
This color palette was originally developed for a data visualization in a clinical/medical project. Recognizing its broader applicability, I incorporated it into our design team's system as it helps select colors for data visualizations across various genomics-themed projects. Even for the data visualization for other themes, designers can still choose from this color palette.
This color palette was for data visualization of the genetic classification only. It is separated from the website's primary color palette and theme color.
Step 1: Frame the problem
Actions
Organize the previous color palette and identify the inherent pattern
Find the problems to solve
Frame the problem
In the project context, there are 14 different colors in this palette to mark different genetic variants. Each hue represents a specific clinical classification of genetic variants, while different lightnesses of each hue indicate classification subtypes. It is a standard color palette in the genomics field, so it's crucial that any of my modifications maintain the cognitive colors to ensure that they are identifiable.
However, the original palette was not thoughtfully curated in terms of extensibility and could not easily accommodate new legends.
Additionally, some colors were too similar, overly vivid, or too muted, hurting visual harmonious.
Rationale
Therefore, I designed a color ramp then select the legend colors from this color ramp to address these issues, ensuring that each color remains distinct and visually appealing, while still adhering to the established color coding necessary for clear communication within the field.
Step 2: Find the baseline hues
Actions
To generate a color ramp, I found the baseline colors.
Choose colors that are representative to each hue
Put them on a color wheel
Set the saturations as high as possible, since I'll use these colors as the baseline colors to generate the ramp, which will be in the middle of a ramp, high saturation guarantees identifiable intervals between colors
Fit the colors to the closest precise hues, to make the hues as typical as possible (sit them on the standard grid and keep nearby colors far away as possible) while maintaining their cognitive hues.
Then we get the baseline hues.
Step 3: Align with the OKLCH color model
Rationale
Why not choosing colors from the color palette PrimeNG provided directly?
PrimeNG color palette doesn't provide the cognitive color Fuchsia.
The color lightness in PrimeNG is not evenly distributed, making the color usage hard to control as it's hard to tell the lightness level precisely.
OKLCH (perceptual lightness, chroma, and hue) is a color model designed to represent colors in a way that's more perceptually uniform than older color models like HSL, allowing easier adjustment and control by bare eyes.
Actions
I used OKLCH Color Picker & Converter (https://oklch.com/) to convert baseline hues into OKLCH hues.
Then turn all the lightnesses to a unified number. Since some color are naturally than others, like yellow, I used a lighter number (100%=lightest, 0%=darkest).
Some colors at 62.31% lightness falls outside the OKLCH color model, then I deferred to the color picking tool to find a fallback color.
I used Huetone (https://huetone.ardov.me/) to generate a color ramp.
For the gray color, I evolved it from the primary color, turning the lightness to the unified number, then turn down the chroma until I felt it is the right one.
Step 4: Generate the color ramp
Actions
When I checked the luminosity of the color ramp, I noticed the lightness levels weren't as consistent as I expected. The inconsistency was due to the software's automatic fallback matching. E.g. the colors with a red underline are on the same lightness level in the left image, but they're not in the same column in the color ramp.
I manually adjusted the lightnesses and chroma until the lightness and chroma curve become smoothy, which means the colors were unified.
Deliverable
Step 5: Finetunes
Actions
It's time to choose colors from the color ramp to generate the specific color palette for the genetic classification.
I tried choosing colors from the same lightness, but the colors are not identifiable enough in the color blindness test.
Then I tried picking colors around the most typical color of each hue (the color that has the highest chroma if you look back the curves). However, the colors are too dark, and it didn't pass the color blindness test.
Then I shifted all choices towards the lighter colors, as human eyes can distinguish colors more easily in lighter shades. I noticed something to be improved:
Conflicts in the color blindness test
Some colors are too light compared with other colors in the same column (each column represents for a lightness)
Some colors are too vivid
I manually adjusted several colors in the palette, tested the luminosity and color blindness, until the lightness looks unified, and the whole color palette passes the blindness test.
Deliverables
Here are the final deliverables:
The color palette
The design practices
Detail 2: Token System
Context
This is designed specifically for the internal design system, instead of reusing design system assets of other project.
Rationale
I noticed that the natural way of making design decisions is always based on the information hierarchy, which is different from the technical structure PrimeNG framework provides. So I created intermediate layers of tokens for designers to flexible manage reusable elements while maintaining flexibility of making adjustments.
Deliverables
I created multiple layers of design tokens that points to each others, allowing for a highly adaptable and scalable system.
Some are adopted from PrimeNG design system, I found ways to import them in Figma Variants.
Some of token structures could be reused, however, designers might want to adjust the parameters of variants while applying tokens to a new project.
Some are reusable.
Detail 3: The Component Library
Context
It was initially designed for a specific project that created a design system for a single brand, which would be used across 8 products, 6 of which were already in existence, and 2 that would adopt the system afterwards.
Step 1
Design review, for finding the components that are reused the most, and prioritize organizing those components.
Step 2
Organize top components that are used the most, and apply design tokens to the components. E.g. text field:
Step 3
I found some blocks (combination of components) are pretty customizable, so I summarized the anatomy of those blocks and gave design practices as examples.
Next Steps
My Reflections
Upcoming…
Upcoming…