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.
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.

2022-2023
Product Designer
Product Strategy
UX Strategy
UX & UXR
UI & Design Systems
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.
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.


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.


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.
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.
Within one sprint, we delivered a new component to the library without slowing squad progress. This success became our precedent for scaling.

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.

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.
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.


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.

2022-2023
Product Designer
Product Strategy
UX Strategy
UX & UXR
UI & Design Systems
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.
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.


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.


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.
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.
Within one sprint, we delivered a new component to the library without slowing squad progress. This success became our precedent for scaling.

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.

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.
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.


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.

2022-2023
Product Designer
Product Strategy
UX Strategy
UX & UXR
UI & Design Systems
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.
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.


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.


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.
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.
Within one sprint, we delivered a new component to the library without slowing squad progress. This success became our precedent for scaling.

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.

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.
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.

