3M / Mammoth Design System
All workFrom drift to
a shared language.
I noticed repeated implementation rework, made the case to leadership, and took ownership of the design system.
Design System Owner · Primitives + semantics · Phased rollout
Reported scope / 3M
40+
Teams supported by the system
Primitives → semantics
I rebuilt the foundations and introduced changes in phases around production work.
Reconstructed controls · Shared semantic roles
New conceptual artwork visualizes shared foundations. Scope and ownership are based on my account and résumé. The interface examples are portfolio reconstructions.
01 / Recognize the problem
The rework exposed
a system problem.
I was working on 3M’s business side, rather than being assigned to the design system. The same inconsistencies kept returning after implementation.
What I observed
Scattered values
Color values were repeated and inconsistent across the work.
What I observed
Token misuse
Tokens were applied inconsistently across design and implementation.
What it meant
Repeated rework
We spent extra time with engineering correcting the implemented design.
My contribution
Make the problem visible.
I documented the recurring pain points, presented the case to leadership, and took responsibility for improving the system’s foundations.
02 / Rebuild the foundations
Give every value
a clear role.
My foundation work began with primitives and semantics: a shared value, a meaningful role, and a consistent use.
01 / Primitive
steel.600
One shared value
The value is defined once.
02 / Semantic role
action.primary
Aliases
steel.600
A role gives the value meaning.
Intent stays legible to the team.
03 / Component
Primary button
button.primary.fill
Uses action.primary
The interface consumes the role.
The decision
Move from scattered values to shared meaning.
A common language between design and engineering, introduced through a phased rollout.
Component behavior / Reconstructed examples
Default
Hover
Disabled
Illustrative token names, colors, bindings, and states. These examples explain the architecture without exposing internal implementation; they are not historical production components.
03 / Phase the change
Rebuild the system.
Keep delivery moving.
Production work was already happening. I introduced the changes in phases to avoid disrupting it. Enable, Apply, Evolve gave the transition a structure.
01 / Enable
Establish
the foundation.
Primitives, semantics, initial components, and shared guidance.
Strategy: involve development and accessibility in validation.
02 / Apply
Use it in
a focused context.
Bring the system into real work while legacy patterns still exist.
Strategy: capture usage guidance and test coexistence.
03 / Evolve
Improve
through feedback.
Refine the library and the way teams use and contribute to it.
Strategy: governance, training, feedback, and measurement.
A reconstruction of the documented rollout strategy, not a checklist of completed milestones.
What I owned
The system foundations, architecture, and rollout approach.
How we delivered together
I partnered with engineering on component delivery and implementation alignment while ongoing production work continued.
04 / Scope + reflection
40+
Teams supported
System reach at 3M, as reported in my experience and résumé.
A shared basis
for better decisions.
Mammoth connected the foundations, components, and guidance designers and engineers used to deliver together.
- Primitives and semantics gave teams a common language for visual decisions.
- Component standards and governance connected with Storybook for live documentation.
- In my experience, that shared language made collaboration and delivery smoother.
What I learned
A design-system opportunity can begin with a delivery problem. Recognizing the repeated friction, making its impact visible, and taking ownership of the foundation were as important as the component work itself.
The delivery improvement is a qualitative account. No percentage reduction or independently measured performance result is claimed here.