Adopting a new design system without losing data density
Client
Soundmouse
Year
2024
System
B2B SaaS
Timeline
Q1, Q2, Q3, Q4
Role
Product designer, implementation
Focus: Adapting a company design system to a dense, highly configurable product
The challenge
Soundmouse is dense by design - clients work across complex metadata and wanted as much visible at once as possible, without scrolling. The base font sat at 12pt for exactly that reason. The company's design system, newly rolled out across every product in the portfolio, assumed more room everywhere: a larger base font, bigger form fields, more generous spacing throughout.
That gap wasn't something I could negotiate away. The design-system team's defaults applied in full, across every product on the system. The real work was making those defaults hold up on the densest, most configurable screens in the company's portfolio - the sections where the system's assumptions got tested hardest.
The most diffucult patterns
Cue view - the hardest case
The system's fields and spacing are larger across the board. That's manageable on its own. What makes it hard is that SoundMouse's cue fields aren't fixed - each workspace configures its own set. One client's cue view might need 2 fields; another's needs 20. At the old, tighter sizing, that variability was absorbable. At the new sizing, an inline layout would have produced wildly unpredictable page lengths depending on which customer was logged in. Splitting into tabs (Common / Uncommon / Identifiers) wasn't a tidiness choice - it was the only structure that keeps a variable-length, multi-tenant form usable once every field took up more room. The action buttons went through the same pressure: five always-visible buttons at the old size became one primary action (Issue) plus an overflow menu at the new one.
Production headers
Built for manual entry, with many fields organized into sections. Frequently-used fields stayed on the default tab; Version Details and Uncommon fields (used less often) moved to their own tabs. Additional Production Titles became a dedicated tab rather than living inline — the same "tab what's used less" logic as the cue view, applied to a simpler page.
No images provided
Connect CMS Image fields (Image 1–10)
Connect CMS Image fields (Image 1–10)
Add Episodes
Previously an inline row sitting directly above the episode table, part of the page's main scroll. Moved into a dedicated drawer, with every field now carrying a help sentence beneath it ("Which season are you adding episodes for?"). The drawer bought back exactly the room the larger fields needed, without it permanently competing for space with the dense table underneath it.
Add Transmissions
Previously an inline third column on the main page, with tabs for Linear, Social, and Non-Linear usage all present at once. Split into two drawers - one to add an entry, one to review the existing list - and validation was upgraded from plain inline red text to a styled callout block around the invalid field. Same information, same tab structure, just given room to breathe once it stopped competing with the rest of the page.
Productions list
Previously had no filtering built into the screen itself — it relied on a separate sidebar panel — plus two separate title columns (Series Title, Production Title) and a single edit icon per row. Now carries a filter-chip row directly under the tabs, one merged "Original Production Title" column, and expanded row actions (three icons plus a toolbar "Actions" dropdown for bulk operations).
Filters
A genuine win! The old pattern was already broken on its own terms — over 20 filters, 100+ options, nested in a scrolling accordion that had to be manually expanded to find anything. The new system's searchable multiselect chips solve that regardless of field size: pick the filter you need, when you need it, search within it instead of scrolling a static list.
Navigation
The old rail was icon-only, built to stay as narrow as possible. The new sidebar defaults to labels and expandable sections, but collapses back to that same icon-only row on demand — so a user who prefers the old density still gets it, and one who wants the labels gets those instead. Since navigation is a fixed-width persistent element rather than space competing with page content, it cost nothing on the density budget either way.
These are the sections I've walked through in detail because they're the most complex, highest-metadata parts of the product — the places where a shared design system's assumptions get tested hardest. They're not the whole migration. The rest of the product moved onto the new system alongside them, without needing this level of structural rework.