OVERVIEW
Meet Magpie! 🐦
Magpie is the custom design system I built retroactively for HanAir, a conceptual flight planning experience centered around booking flights within South Korea and Japan. I originally designed HanAir screen by screen until it looked finished, but nothing was actually scalable. Magpie is the result of asking what would it take to scale HanAir beyond a set of finished screens.
The Problem
HanAir's designs existed as a set of finished screens, not a system. Every new touchpoint meant rebuilding from scratch.
The Solution
Magpie, a scoped component and token library that turns HanAir's visual language into reusable, decision-backed building blocks.
psst…
Magpie is named after the national bird of South Korea, which HanAir's branding is built off of!
CONTEXT
Why build retroactively?
I didn't start HanAir with a design system because that's not how I design. I need to work in the canvas first, testing what actually looks and feels right, before I can turn any of it into a rule. Especially since I was building the brand from scratch.
Exploring different styles and directions
However, starting in the canvas meant a super messy file (as always!). Components would be made then left floating around, impossible to find later. I would create swatches on the canvas of the colors I wanted to use so I could eye-drop them when needed (instead of just making them styles). In the end, this meant none of the designs had consistent components or tokens.
A super disorganized canvas
PROCESS
Auditing finished designs
Before I could build Magpie, I had to go back through every existing screen and actually catalog what I'd made. Which colors, spacing values, and components repeated? Which were near-duplicates of each other, and which were true one-offs that didn't need to be systemized at all?
Variables and token architecture
In Figma, I documented all colors, text styles, and spacing so all property values across the designs could be assigned back to variables in the design system library. This was an essential step because having it meant if I ever needed to change a hex code or font size, I could now make changes at the source rather than hunting down each instance and editing manually.
For naming conventions, I built color as a two-tier system rather than one flat palette. The first layer is a raw color library defined by hex value, things like Primary, Accent, Dust White, and light-blue. The second layer is a semantic UI color layer that references those raw values by purpose instead of by name, so color-primary points to Primary, color-active-button-fill points to light-blue, and so on.
Component logic
For the component library, I mainly focused on organizing existing components created during the design process for HanAir and then breaking them down into smaller atoms and molecules for scalability. Some components exist solely for the purpose of prototyping in Figma and involve variable logic, but are still documented for future use or editing.
Documentation and guidelines
Beyond tokens and components, Magpie also serves as a source of truth for brand guidelines. None of this was about making the system bigger for its own sake. It was about making sure anyone using Magpie, including future me, would know not just what to use, but when and why.
SOLUTION
View Magpie!
View the Magpie Figma file with all the variables, styles, components and more!
OUTCOME
What I learned!
Before this project, my only design system experience came from using an existing system to pull from and build new components / designs. Working retroactively and building a system based off finalized designs was a challenge. Auditing my own inconsistencies was uncomfortable in a useful way. It forced me to actually name my own patterns instead of assuming I was being consistent just because everything shared a vibe.
It also reframed what a design system is for. I used to think of one as a finished deliverable, a component library you hand off. Building Magpie made it clear a system is really just documented decision making. Tokens and components are just the artifact of decisions I was already making inconsistently, made consistent and legible to someone other than me. That's a more useful mental model going forward than "make a component library."
Future steps…
Magpie is still a very small and limited system. However, I'm treating that as scoped rather than incomplete. It has exactly what HanAir's flight planner needs and not much beyond that, which means the next real test of it is scale. If I were to continue to add to the system, I would work on expanding for other touchpoints.