Design System & B2B Experience

As the product grew, the same decisions started appearing in four different contexts. The consumer app needed motivation, habit-building, and polished mobile flows. Growth pages needed speed and reusable conversion blocks. SDK screens needed theming and predictable behavior inside another product. The partner portal needed dense, role-based operational UX.

Designed screen by screen, every new surface drifted: slower to ship, harder to hand off, inconsistent within a quarter. Which decisions should be made once — and which have to stay per-context?

I treated the design system as product infrastructure, not a component library: reusable where the decision repeats, flexible where the user context changes.

In practice that meant four layers — foundations, components, patterns, templates — each answering a bigger question than the last: what things look like, how they behave, how a flow works, how a whole surface assembles. A new landing page or a partner dashboard started from a template and inherited every decision below it, instead of starting from a blank frame.

B2B SDK pushed the system further. The same product experience had to support Zing defaults and partner-branded versions without redesigning every screen.

We moved the system from visual styles to semantic tokens — an action, a surface, a text role — so a partner rebrand became a token swap. The brand layer changed hands; layout and core behavior stayed ours.

The partner portal flipped the unit of design: instead of one user completing one workout, multiple roles manage many users — locations, payouts, reports, permissions.

The system grew a second register for that density: predictable tables, filters, role-aware navigation, and empty states that say what is missing and who can fix it. Operational screens earn their keep by being scannable and comparable — the opposite bar from a paywall.