Werk
Design System
Building a design system that grows with the product.
Werk is an all-in-one business platform for independent dance teachers. Over thirteen months, I helped evolve its design system alongside the product. My work spanned component design, interaction patterns, and engineering collaboration, before I eventually took ownership of the system’s documentation and direction.
Redesigned Werk product screen, light and dark side by side
01 / THE PROBLEM
Every new feature started by re-deciding what Werk should look like.
Werk brings the business side of teaching into one place: classes, bookings, events, payments, and the people a teacher works with. When I joined there was a UI kit in Figma. Werk already had a UI kit, but it lacked a cohesive system connecting its components, visual language, and interaction patterns. As the product grew, that gap became increasingly visible.
The UI kit
Photoshop designs translated into Figma, then extended component by component as needs came up. Nothing tied the additions together, and it was hard to keep current.
The visual direction
Never settled. The founders were not satisfied with the look, so designers kept exploring instead of building inside one language.
The screens
Components and treatments varied from one experience to the next.
The build
Developers worked from several different approaches at once.
01 / CONTEXT
I was brought in to help make Werk better. Working out what that actually meant was the first thing the product lead and I did, and a proper design system was a large part of the answer.
Choosing a foundation was the quick part. Making it fit Werk took the rest of my time there.
Ticket selection and payment on one surface.
A second take on the same job, built differently.
Summary layouts that each solved hierarchy their own way.
Werk before the design system work. The brand was already there in the yellow and the dark surfaces. The patterns underneath were not shared.
02 / APPROACH
Building on an existing foundation, not starting from scratch.
Rather than building a system from the ground up, we started by evaluating existing UI foundations. The product lead led the evaluation and selected Untitled UI as our starting point. It gave us a solid component library and support for both light and dark themes. From there, we adapted its foundations and components to better fit Werk’s product and visual identity.
Werk was primarily dark mode. The founders liked how it looked. The product lead and I found light mode easier to navigate, so instead of picking one we supported both.
We kept much of Untitled UI's component structure and adapted its typography, color and styling to Werk. As features came up, individual components were modified where the styling felt dated or the behavior did not fit what the product needed.
OWNED BY PRODUCT LEAD
Led the adoption of Untitled UI and the visual direction. Owned the Figma foundations and the component library.
WHAT I OWNED
Designed component variants and interaction patterns for the product. Established the design review process with developers. Applied and evolved the system through feature design and implementation review.
Most design decisions were worked out together with the product lead. What follows is the part I contributed inside the system, and what it took to keep it holding together in the product.
03 / FOUNDATIONS
A shared visual language, documented in Figma.
The foundations were adapted from Untitled UI and owned by the product lead. They became the reference I designed against every day, and the thing developers and I could both point at.
Primitives were Figma variables and were never applied directly. Semantic tokens carried the meaning.
Grey, Brand, Red, Amber, Green and Teal, each defined across text, stroke, icon, fill and background.
Surfaces
Sunken, base, raised and overlay. Light mode used shadows for elevation. Dark mode used progressively lighter backgrounds instead, because shadows barely register there.
Type
Inter Tight, with separate desktop and mobile scales. The larger sizes stepped down on mobile.
Spacing
A 4px scale running from 0 to 256.
Layout
12 columns at 24px gutters on desktop, 8 at 16px on tablet, 4 at 16px on mobile.
Icons
Phosphor, on a 24px grid with a 2px stroke, flattened so they could be swapped inside a component while keeping color and stroke overrides.
Type scale
Spacing scale
Responsive grids
Themes
Because the themes were semantic variable modes, the same frames switched between light and dark without duplicating screens and recoloring them by hand. I designed in light mode, which made it easier for me to judge clarity, then switched to dark to check that what I had made still held up.
04 / COMPONENTS
Variants that carry the states a real product has.
I designed variants and interaction states for the components my features needed: modals, dropdowns, selection patterns, form layouts, tables and data displays, navigation, and the booking interactions. Some were adaptations of what Untitled UI already offered. Others were patterns the product asked for and the library did not have.
Werk let teachers customize a lot, so some workflows genuinely needed several decisions in a row. The goal was never to strip steps out. It was to keep each one obvious, including for teachers who were not especially comfortable with software.
Eight statuses, two densities, and a wider layout, held in one documented component instead of eight separate cards.
How a feature usually went
04
Walk developers through what changed so they could implement and reuse it.
Not a formal workflow. Just how the system kept growing, one feature at a time.
05 / IN PRACTICE
A review step teachers could jump back into.
Setting up a booking meant working through a lot of configuration: time zone, minimum notice, available days and availability, refund policy, a toggle for whether refunds were allowed at all, and the policy text itself.
On one page that would have been a wall. We split it into steps, each with its own progress indicator, to keep the setup digestible. The founder's reference was Airbnb's listing creation.
At the end, teachers reviewed what they had entered. I designed each review section as a clickable container with an edit affordance, so a teacher could go straight to the step they wanted to change instead of walking backward through the whole flow, then land back on the review. This pattern was mine. It was not something Untitled UI gave us.
01 Configuration, broken into steps.
02 Everything entered, in one place.
03 Each section is its own way back in.
04 Edit there, then back to review.
Selecting edit takes the teacher to the corresponding step. Nothing is edited inline on the review screen.
06 / REUSED
I reused the pattern in booking modification. When a teacher changes the date, time or hourly rate on a student's request, the review that follows works the same way, adapted to the situation: it shows the proposed values, with green, already part of the system, marking what changed. It does not sit the old values next to the new ones.
05 The request as it stands.
06 Change the date, time or rate.
07 Review the proposal, changes in green.
One pattern, two workflows: setting something up for the first time, and changing something that already exists.
06 / MORE APPLICATIONS
The same system, two very different problems.
AUDIENCE MANAGEMENT
From lists inside events to one directory.
Students used to live inside individual events, so a teacher only ever saw the people attached to one thing at a time. The redesign brought everyone they had interacted with through Werk into a single directory, split across All, Subscribers and Students, with segments that are allowed to overlap.
Each person carries what a teacher actually needs: events attended and how many, tickets purchased, total paid, join date. From there a teacher can email the whole audience or just one segment.
Before
After
WAIVERS & CONSENT
One place to say what's required.
Liability waivers and media releases were being handled separately. Werk supplied a generic version of each, so the job was not document management. It was making it clear what a teacher was asking of people.
Teachers could preview both documents and turn each requirement on or off independently, with helper text appearing to explain what it means when one is off. The documents were fixed, and nothing was signed or collected here.
The modal changes shape with the configuration, compact or expanded.
07 / BEYOND FIGMA
Taking ownership of the system beyond Figma
After the product lead left, I took ownership of the design system’s ongoing direction. That meant formalizing decisions that had previously lived mostly in Figma and making the system easier for engineering to reference during implementation.
I created a token file containing the system’s values, a Markdown document defining components and their usage, and a set of instructions outlining the standards developers should follow. The developer incorporated these files into their AI-assisted coding workflow, giving the AI a shared reference for how Werk’s interface should be built.
Figma remained the visual source of truth, while these written resources provided a more explicit reference for the rules behind the interface.
03 Each section is its own way back in.
03 Each section is its own way back in.
03 Each section is its own way back in.
Figma stayed the place to see what something should look like. These were the record of what it actually was, and what the rules around it were.
08 / WHERE IT LANDED
A direction everyone could build on.
Untitled UI gave the founders something clean and professional they were comfortable with, and once we had adapted it to Werk, the question of what the product should look like was closed. I could design inside an agreed language instead of reopening the aesthetic every time a feature came up. That is the part that made new work faster, more than the components themselves.
The product became noticeably more cohesive than it was when I joined, and new features got quicker to design because there was always something to build on.
Both light and dark themes shipped to Werk users. The visual language reached past the product into the landing page and marketing material.
By the end of my engagement, the design system had grown beyond a Figma component library. It included documented components, design tokens, and implementation guidelines that the engineering team could continue referencing as the product evolved.
One set of components, one set of semantic tokens, two themes in production.
09 / REFLECTION
The system grew faster than its documentation.
I was moving between features quickly, on limited hours, and maintenance happened alongside delivery rather than as its own responsibility.
Components scattered
They ended up across separate Figma files. I sometimes rebuilt one because I had forgotten an equivalent already existed.
Designers felt it most
Developers could carry on once they were told a component had changed. Finding things was the designer's problem.
No time to consolidate
Shipping came first, so an audit never got scheduled.
Ownership came late
The tokens, the documentation and the rules came together in the months I had left.
What would I do differently?
One central library, instead of components spread across project files.
The rules written down early, while the system is still small enough to hold in your head.
Regular passes over what already exists, so nobody rebuilds what is already there.
A way to see what changes in code when a component is redesigned.
The lesson for me is the timing more than the work. The system did its job, it supported a product that kept growing, and it gave design and engineering a shared vocabulary. Organizing it was the part that never got its own time until the end.