Designed, engineered, and shipped. Solo.
MDDS. Digital Memory Design System. Now running 110+ live instances in production, a quarter of them shipped by other devs.
Three icon generations, directionless components. Zero system.
MDDS is the design system I built for ODILO's Archive & Preservation product. Before it existed, every screen defined its own buttons, notices, and icons: three generations of iconography coexisting, colors hardcoded in every stylesheet, and no shared visual language across modules. MDDS replaces all of that with a token layer, reusable components, and a unified icon library — now live in production.
But the most important change isn't visible on any screen: it's a new way of working. With solid foundations, every design decision stops being solved screen by screen and starts being solved once, in the right layer. That lets us tie the product together with more consistency for our clients, without repeating the same work in every module.
Tokens first, screens later
The order matters as much as the outcome. Instead of creating components and retrofitting them to a token system, I followed the reverse sequence: tokens first, component second, documentation in parallel, migration last.
Why that order.
Building a component before having tokens forces you to rewrite it as soon as the color or typography system changes. Starting with tokens forces you to answer the hard questions first — what's primitive, what's semantic, what depends on usage context — and ensures the component is born consuming variables, not loose values.
The Figma-to-code bridge.
Part of the work that isn't visible on any screen was connecting each token name in Figma with its CSS equivalent, so they would stop being maintained manually in two separate places. What's decided in design reaches code with the same name — no manual translation, no margin for error between tools.
How I approached each component.
I didn't design screens — I designed pieces the rest of the team could use without asking me for help. That meant accessibility and support for the application's six languages were built into each component from its first commit, not patched in later. And it meant documenting every variant in an internal playground, the team's working reference today, evolving toward a shareable internal product as the component set grows.
From Figma to production, without manual translation
The pipeline extracts Figma variables and processes them to automatically generate the three token layers in CSS. What Figma doesn't handle well — edge cases, fine-tuning — is managed directly in code, without forcing the design tool to do something it wasn't built for.
Four components built from scratch — button, icon button, button group, and message — with variants, states, and accessibility (aria-label, aria-hidden, roles) resolved within the component itself, not as an added layer. An icon library of 190+ icons unified into a single font, replacing three distinct icon generations. In production, used by public institutions with strict accessibility requirements.
Documentation as a working session
The playground isn't documentation written after the fact. It's shaped in continuous pairing with the company's senior frontend engineer: what variants a component needs, how it handles edge cases, how a decision travels from Figma into code without losing intent. That shared review is what makes the system safe for other devs to build on without asking first. We're now extending it with agentic skills and workflows, so consuming a token or component gets even simpler for the rest of the team.
Where the friction was
The hardest part wasn't technical. This product vertical had never had a design function. Early on, that meant defining acceptance criteria and handoffs from zero, iterating them with engineering as we went. As design engineer, the friction moved downstream: making each component robust enough to hold every variant a real screen throws at it, worked out directly with the senior frontend engineer before code ships. The value I add now lives in production, not in a handoff.
Work that multiplies itself
Of the 110 live component instances in the product today, one in four was placed by another frontend team member — using components they didn't build. Once a component exists and is documented, the interface keeps improving without me intervening on every new screen. That's the effect a design system should have: work that multiplies itself.
By the numbers
440
design tokens (color, interface, typography)
190+
icons in unified library, 60% originally authored
110
live instances from 4+ production components
24%
of instances built by the rest of the team, without direct intervention
What comes next
A brand or palette change now happens in the token layer, not screen by screen. Each new component builds on what's already there, so the next one comes together faster and lighter than the last. Table, navigation, and forms are next: they inherit tokens, icons, and a migration pattern already proven in production. Every migration also retires real technical debt, with a direct impact on both product velocity and the business bottom line. The system isn't finished. It's compounding.