Process doesn’t have to be boring.
A bit of context.
When we set out to build Expo, our design system, we chose MUI (Material UI) as our foundation. This decision gave us a solid, well-maintained component library but also came with its own set of challenges—like keeping up with MUI updates, managing a growing component backlog, and ensuring smooth adoption of new system changes.
To bridge the gap between design and development, we rely on Chromatic, Storybook, and Figma as our key communication tools. This case study explores three key processes we’ve put in place to keep Expo evolving:
Keeping Up with MUI – How and when we update Expo to match MUI’s latest versions, and how we get product teams to adopt updates.
Managing the Component Backlog – How we handle situations where developers use MUI components for speed instead of waiting for design system versions.
Evolving the System – How we introduce updates, additions, and changes to Expo while keeping everything consistent and scalable.
Each of these processes helps us maintain a design system that’s both reliable and adaptable—supporting teams without slowing them down.
This case study will address the first process. Please reach out to learn about the others.
Initial questions
-
It it important for us to maintain parody with MUI?
-
What is the definition of a need for update?
-
Who is responsible for the the library update?
Parody
After many discussions with designers and developers, we decided that maintaining constant parity with MUI isn’t necessary. Since MUI updates frequently, not every change is critical to the success of Expo. Instead, we focus on updating strategically—prioritizing improvements that add real value or would be expensive to hold off on.
Definition
Now that we know staying fully in sync with MUI isn’t necessary, we need to determine which updates require immediate action and which can be bundled into the next release.
-
How critical is this to the success of our products?
Does it fix bugs that are blocking us?
Does it provide more components or efficiency that would be immediately beneficial?
-
How long do we think this change will take?
What does it mean for products to update to this version
are there breaking changes that will required rework?
-
What dev and design resources are available to make the library change
What do the product roadmaps look like?
Responsibility
The idea behind Expo is that the responsible developer is the one from the product team that initially needs the component or change. However, since library updates affect everyone, we had to determine who takes ownership of these updates. Should it be a single point person, or do we need a clear process for assigning responsibility?
Conversations are still in the works
The Process
Implementation & Feedback
We’ve received initial feedback on the overall process and plan to begin implementing it in Q2. I’m looking forward to learning and iterating as we go.