2023–2025
Harmony Design System
Audius · Lead Designer
The app worked. It just didn't hold together.
When I joined Audius in October 2022, the product was live and growing. But the moment I opened the design files, the problem was obvious. Modal headers in four different styles. Buttons with inconsistent sizing and color across different parts of the app — not because anyone decided that, but because a stakeholder would lean over the only designer's shoulder and say "make that button bigger," and nobody ever went back to fix it. Typography was the worst of it: no clear hierarchy system, just hardcoded values everywhere, each screen a slightly different interpretation of what a heading should look like.
Engineering had a Storybook, but barely — a pill button, a few local components. Nothing you would call a toolbox. Design and engineering were working in opposite universes with nothing bridging them together. Trust between the two teams was low, and building it was slow and expensive.
Within my first week I told Julian: this is going to have to change.
Step one: understand what we actually had
Before building anything, I audited everything.
I went screen by screen through the app and mapped every text style in use — not by size or weight, but by role. This is a heading. This is a subtitle. This is a button label. I needed to understand what the product was actually doing typographically before deciding what the system needed to do. The audit made the problem concrete: we had dozens of one-off text treatments that could be collapsed into a handful of intentional, reusable styles.
[ARTIFACT: Typography audit screenshot — screens labeled with heading, subtitle, body, button, label, input]
From there I built a full component inventory. What did we have? What was missing? What was being rebuilt from scratch every time someone needed it? That list became the foundation for everything that followed.
Getting engineering in the room
With the audit done and a clear picture of what we needed, I brought engineering into the conversation.
In May 2023 I facilitated the first Harmony workshop — an offsite with the front-end engineering team. The goal wasn't to present a system I'd already built. It was to build a shared, prioritized list of what mattered most. What components did engineers reach for constantly? What kept slowing them down? What did they want to own?
[ARTIFACT: Workshop photos, May 2023]
We left with a prioritized backlog. Engineers knew what was coming and had shaped the order. That changed the dynamic entirely.
Building alongside feature work
We didn't have a dedicated design system team. What we had was a small group: mostly me, Julian, and our lead engineer Dylan — with others coming in and out. Waiting for a dedicated sprint to build everything wasn't realistic. So we built a different approach.
I created a decision framework in Notion for every design handoff: does this component exist in Harmony? If yes, use it. If no, do you want to build it? Engineers had the option to contribute components as they encountered them in feature work. If they needed a radio button and it didn't exist yet, they could build it and it would go into the library. Our head of engineering did exactly that.
Engineering bandwidth meant there was a gap between what existed in Figma and what existed in code. We named it openly and built a system around it rather than pretending it wasn't there.
This approach meant the library grew organically alongside the product. Components started in beta, contributed by whoever needed them first, and got pushed to stable as we had capacity to review and finalize them.
I ran a second workshop in March 2024 and a follow-up vibe check session to keep the momentum going, adjust based on what the team was actually running into, and make sure adoption stayed on track.
[ARTIFACT: Sticky note wall, March 2024]
The dedicated sprint: shipping harmony.audius.co
When engineering bandwidth finally opened up, we used it to push everything over the finish line.
Dylan and I worked closely to finalize the components that had been built but not yet stabilized, complete the documentation, and ship harmony.audius.co — a live, public-facing site where every component lives with its props, variants, states, and usage guidance. Engineers didn't have to ask what a button does. They could look it up, copy the code, and ship.
[ARTIFACT: harmony.audius.co welcome page] [ARTIFACT: Component documentation — Button variants, sizes, states] [ARTIFACT: Props table]
The site became the single source of truth for both design and engineering. When a new engineer joined, Harmony was their onboarding document. When a designer handed off a spec, Harmony was the reference. It removed a category of back-and-forth that had been constant before.
The moment I knew it had worked
The first signal came at a company hackathon. Engineers presented their projects and something was different — the interfaces looked genuinely good. Not "good for a hackathon." Just good. Julian pulled me aside afterward: they've never looked that good.
They didn't have to make design decisions. They just built.
The second signal came from Marcus, one of our engineers, after the button and input components had shipped to production:
"I was able to dev the entire change email flow and new change password flow in ~1 day. It's great to have a standard that conforms to the design, and know that when I use something I can be confident that either it's had a pass for Harmony or it will have a pass for Harmony and all I need to do is use it rather than trying to get it to fit the mocks."
And from Saliou:
"Harmony has genuinely made it easier to do my work when it comes to consistency of UI components and speed of development. The Figma properties make it super easy to know exactly what I'm working with. And it comes out looking 🔥"
[ARTIFACT: #harmony Slack channel — active engineering threads]
What Harmony unlocked
The immediate impact was velocity. Development time on component-heavy work dropped by roughly 50%. Engineers stopped making visual decisions they shouldn't have had to make. Designers stopped fielding questions about spacing and color that the documentation already answered.
The longer-term impact was bigger. When Audius began integrating AI-assisted coding into our workflow — engineers generating and shipping code at a pace we hadn't seen before — Harmony was already there. The system was ready. Components were consistent, documented, and reliable enough that AI-generated code could use them correctly. We hadn't planned for that. We'd just built something solid enough that it held up when the pace changed.
[ARTIFACT: Before — hardcoded Figma file with raw hex values] [ARTIFACT: Before — chaotic component library] [ARTIFACT: Before — Audius UI, August 2022] [ARTIFACT: After — harmony.audius.co] [ARTIFACT: After — Audius UI post-Harmony]
Live site: harmony.audius.co
Role: Lead Designer — audit, Figma library, token architecture, documentation site, workshop facilitation, adoption strategy
Timeline: 2023–2025