Loading Blueprint Design System

BLUEPRINT

DESIGN SYSTEM

I developed a comprehensive design system that improved design consistency and cross platform efficiency by 27% across multiple projects with 200+ users.

View the final library here.
PROBLEM —
There is a need to create an interactive component library to increase collaboration between developers and designers working on the Sereberus suite of projects within PNNL.

The solution needs to simplify the handoff from design teams to development teams. And the library should enable a seamless creation of mockups and wireframes that can be translated into functional tools.
GATHERING CONTEXT —
ONE — FAMILIARIZATION + READING
— In order to inform the creation of the component library, I immersed myself in literature.
— Read about atomic design principles and design tokens.
— Studied existing protocols for creating a design system.
— Researched tools that facilitated design system creation.
TWO — COMPETITIVE ANALYSIS
— Researched Material UI, Apple HIG, Shopify Polaris, AntDesign, IBM Carbon, and Microsoft Fluent (Web).
— Created wireframes using said libraries to understand how component libraries and design systems work.
— Following the user journey of my target user, I edited and combined components to identify areas of opportunity that could be addressed in my solution.
— From this, I learned that strong design systems and component libraries utilize properties to quickly edit prototypes. This reduced the amount of time spent clicking into nested components.
THREE — USER INTERVIEWS
— Hosted workshops, interviews, and ethnographies surrounding interactions with current solutions.
— Spearheaded the synthesis of data via qualitative coding and thematic analysis to see what systems were most effective.
— This revealed that designers held disdain towards monotonous tasks (such as creating a similar button repeatedly). The component library for this design system should allow users to quickly recreate elements.
— Presented findings to higher-ups and users to solidify design directions.
What did my process look like?
DESIGN PROCESS —
ONE — CSS
— I utilized the CSS behind each design element to accurately inform size, color, state, and intent.
— This information was then translated into Figma, and then completed using the prototype tool.
— By maintaining the terminology used by developers within the component library, there was now a standardized language used between designers and developers.
TWO — TESTING
— I extensively tested each state and intent with the goal to "break" it and find bugs.
— This was followed by user testing. I was able to locate issues with nesting, scaling, and inaccurate design decisions through these workshops.
— Before pushing any final changes, I combined and individually checked each property to avoid any errors.
THREE — DELIVERABLE
— Final components are populated in a sticker sheet, allowing developers and designers to copy and paste components into their designs.
— Iterated and tested various sticker sheet designs with the goal of having an easily scanned component.
— Collected documentation and resources for each component to provide designers and developers with the intended context behind each element of the design system.
Now let's look at the final design and some design decisions.
DESIGN DECISION ONE — CUSTOMIZATION
— This component library is designed to enable accurate and customizable designs within Figma.
— Properties follow the original CSS, allowing users to easily edit the component without the need for replacement.
— Following CSS classes assists developers in quickly recreating wireframes and mockups into responsive products.
This feature streamlines system-wide edits and the hand-off from designers to developers.
DESIGN DECISION TWO — RESPONSIVE PROTOTYPES
— Although static within the editor, the components within my library come to life in Figma's prototype mode, replicating the animations and states of a fully implemented version.
Mockups and wireframes support responsive buttons, loading screens, text fields, and other inputs.
— Prototypes can accurately reflect the final product. Now developers can ensure their work adheres to the guidelines set by designers, and easily communicate potential issues with the designers work.
DESIGN DECISION THREE — MODULAR
— Components can be nested and combined to create complex building blocks within a UI.
— Complex components can still be edited within the properties panel.
The sticker sheet provides a description including intended purpose and links to further documentation, leading to informed design decisions.
— Developers also have the agency to ensure that additions to projects adhere to guidelines set by Blueprint.
REFLECTION —
My experience with creating this component library for the Blueprint design system overall was challenging, yet positive. Most of my prior experience focused on creating wireframes and high-fidelity prototypes that conveyed ideas to developers. However, this rarely involved fully interactive components, inputs, or even spinners.

— Creating a successful library in the limited time frame pushed me to rely on previous skills in UI design and front-end development, while continually building upon my Figma skills.

— By the time the library was completed and ready to be released publicly, I was fully capable to use components and variants to their fullest extent.

— I also learned a lot about UI design during the process due to my mentor. I was appreciative that during our weekly check-ins, James took time to provide me with in-depth critique to improve upon not just my deliverables, but also future work.

This project was a good way to practice being receptive to feedback, and making adjustments to the final deliverable accordingly.