002
Baukasten: Rebuilding a Design System Through Crisis
Projects
Baukasten: Rebuilding a Design System Through Crisis
Three months after joining Workpath, the company underwent a reorg. The newly formed design systems team was dissolved, leaving Baukasten (our design system) in limbo.
Year
2022
Client
Workpath
Role
Senior - Staff product Designer
(Impact)
Q4 '22 - Q1 '23
Metric | Before | After | Result / Notes |
|---|---|---|---|
Component contributions | 5 | 28 | +23 components added across squads |
Fully documented components | — | 21 | ≈75% of contributions documented |
Squad satisfaction | — | — | 3/3 squads reported smoother collaboration and clearer standards |
TL;DR: From 5 → 28 components with ~75% documented, Baukasten shifted from a stalled asset to a living system that accelerated delivery and improved cross-squad consistency.
(Context)
Three months after joining Workpath, the company underwent a reorg. The newly formed design systems team was dissolved, leaving Baukasten (our design system) in limbo.
Early-stage system, not robust enough for team needs.
No clear ownership or accountability.
Product teams still expected to ship at full speed.
(Challenge)
Without ownership, components became bottlenecks. My attempt to deliver a modal component highlighted the dysfunction:
Collaboration was strong, but delivery took weeks.
The component languished in the pipeline, passed between squads.
No squad wanted the “extra” work.
Baukasten had become the Bermuda Triangle of design systems, where components went to die.
(Course Correction)
1. Build a team
To succeed with the decision I had to course correct. I had to do things differently than my first attempt. So first and foremost, I figured why not leverage what I already have?
I was in the lucky position to have the former design systems lead (Leo) end up being the tech lead on my squad. Given that he was already an expert on the topic, he had the nuanced understanding of the domain and the deepest knowledge, it didn't take much to convince him of the benefits and to do a trial run within our squad.
2. Build foundation for the long term
We still had to get product buy-in as well. So Leo and I drafted a simple plan, and ran it by Simon, the PM on team. We reframed design system contributions as squad-enabling work, not side projects:
Included DS tasks in sprint planning.
Improved async documentation to reduce overhead.
Broke work into smaller increments to maintain velocity.
3. Test and prove value
Within one sprint, we delivered a new component to the library without slowing squad progress. This success became our precedent for scaling.
(Next steps)
Growing into the role
In the meantime, given that design systems is a personal passion of mine, and a common frustration amongst designers and developers alike. I spoke with my manager, and we agreed to tie in the design system work to my career growth plan.
I took the first steps to taking the initiative to the next stage, and started tying everything to the bigger picture.
Formalizing the process
The first decision was to keep the voluntary model we already had in the design team but extend that to the devs as well.
Secondly, since we were able to replicate the success, Leo and I agreed that we would formally announce on relevant slack channels that we would be the main stakeholders and communication points on design system needs.
Change how the org viewed design & show why what designers do matters.
I worked with the other designers on educating our internal staff across the org on our functions, explaining and simplifying design terminology and practices.
This of course was not exclusive to design systems, but for the sake of giving a tangible example, I've attached these screenshots from a recorded townhall spotlight session where I presented to roughly 80 employees an explainer on Design principles and our Design system and how they work together to ensure we have a consistent product.
