Turning a portal refresh into a shared design system.

The portal had fallen behind the brand

Coda's previous identity was bold, playful, and strongly associated with Codashop. As the company expanded beyond its consumer-facing roots, the brand team introduced a calmer, more mature direction.

The Publisher Portal still carried the old visual language. Side by side, the new Coda brand and the existing product barely felt like they belonged to the same company. Bringing them back into alignment became the initial brief.

Squads were solving the same UI problems separately

Before redesigning the portal, we audited key workflows and compared how recurring patterns were represented across design and implementation.

The issue extended beyond appearance. Squads were solving similar interface needs separately, leaving component behavior, states, and implementation to be defined again for each feature. The audit pointed to four connected problems:

• Visual and code drift: squads repeatedly created their own UI patterns, producing inconsistent experiences and duplicate implementation work.
• Framework barriers: the internal admin panel and Publisher Portal ran on different frontend foundations, limiting how much could be shared across products.
• Communication friction: designers and engineers repeatedly redefined component behavior, states, and interactions from ticket to ticket.
• Internal-tool mindset: functional delivery often took priority over consistency and polish, creating growing visual and technical debt.

Teams were concerned about active sprint commitments

Other product managers were hesitant to adopt centralized UI standards because they feared a design system would slow active sprint delivery.

Their concern mattered: building shared UI would take time away from immediate feature work. At the same time, working independently meant squads kept paying the cost of designing, implementing, and maintaining similar patterns. We needed to make that tradeoff explicit.

Reusable components became part of the brief

The refresh still needed to bring the portal closer to Coda's brand. We added a second goal: give product teams reusable foundations and components so consistency could survive beyond the redesigned screens.

That broader goal connected the publisher-facing experience with the way squads designed and built it. It also required a larger commitment than a visual reskin.

The team committed frontend capacity for the quarter

That reframing also changed the cost of the project. Building the system properly would require most of our frontend capacity for the rest of the quarter, deliberately slowing progress on other product initiatives.

My manager brought the tradeoff to the wider product and engineering group: continue optimizing for short-term delivery, or invest in a shared foundation that could reduce repeated work and make future development more scalable.

The team chose the second path. That buy-in gave us space to treat the work as a platform initiative rather than a visual refresh squeezed between feature sprints.

Storefronts and operational tools needed different behavior

Before deciding how the system should be structured, we first needed to understand what should actually be shared.

Codashop and Publisher Portal both represented Coda, but they operated in very different product contexts. Codashop needed consumer-facing flexibility, publisher-specific theming, and merchandising patterns. Publisher Portal relied on dense operational UI such as forms, tables, validation, and multi-step workflows.

Forcing both products into one component system would have created the wrong constraints.

Later Commerce Engine work reinforced the boundary

When we later built the Commerce Engine design system, its needs were fundamentally different from Publisher Portal. It had to support highly flexible branding and varied art direction across storefronts rather than a tightly controlled operational interface.

This later work reinforced the earlier choice: shared brand principles could connect the products while their components evolved around different workflows.

We continued exploring the portal's visual direction alongside the onboarding redesign. The system needed reusable rules that could support the current portal and adapt as navigation and product structure changed.

Early visual exploration was not yet reaching the quality bar we needed, so another designer stepped in to lead the visual direction and push the work closer to the new Coda brand.

At the same time, the onboarding work was rethinking how publishers discovered Coda's products, navigated between solutions, and moved toward launch. We were defining the foundation while both the visual language and the product structure it needed to support were still changing.

Once the system boundary was clear, we organized the Portal system from the most reusable decisions upward—starting with foundations, then components, and finally recurring product patterns. The goal was to centralize what should remain consistent while keeping higher-level patterns flexible enough for different workflows.

Foundations

The shared visual and behavioral decisions that should remain consistent across the portal: color, typography, spacing, elevation, radii, states, and interaction principles. These foundations gave design and engineering a common baseline and reduced repeated low-level decisions across squads.

Components

Reusable building blocks with clearly defined anatomy, states, and behavior—such as buttons, inputs, selectors, banners, and table elements. We focused on keeping the component model predictable across design and code instead of creating variants for every possible use case.

Patterns

Higher-level combinations of components that solved recurring portal workflows, including dense forms, data-heavy tables, configuration flows, and validation states. Patterns captured repeated product behavior without forcing every screen into the same layout.

Our principle was to standardize repeated decisions while preserving flexibility where product context genuinely differed.

To keep the system scalable without turning the core team into a bottleneck, we used a hybrid operating model: foundational decisions stayed centralized, while embedded designers and engineers could contribute patterns grounded in real product needs.

Recurring design–engineering reviews made this model part of the team's routine. We used those sessions to discuss system decisions, product needs, and proposed contributions together.

System co-leads maintained the core

Core tokens, accessibility standards, foundational components, and system-level decisions were maintained by the system co-leads and reviewed through recurring design–engineering governance sessions.

Product teams proposed reusable extensions

Product teams could bring patterns and extensions into the review when those solutions proved reusable beyond a single feature. The model gave us a stable core while allowing the system to evolve through real product needs.

First-rollout results

• Component-level delivery: engineering reported up to 80% fewer story points when implementing standardized UI components.
• System coverage: around 75% of active portal screens were migrated to the new system during the initial rollout phase.
• Multi-product adoption: newly launched internal admin tools began using the Portal design system as their default architecture.

Plan adoption alongside the library

We were building the library while the portal's visual direction and onboarding structure were still changing. Shipping foundations first created value before the library was complete, but it also meant old and new UI had to coexist.

On a future project, I would plan the migration sequence alongside the first system decisions: what can change immediately, what must wait for reusable components, and how transitional screens should work. A complete library is only part of the work; teams also need a practical route to adopt it.

Make sharing boundaries explicit earlier

Portal and Store represented the same brand but needed different component behavior. Separating their systems preserved the Portal's operational focus while leaving storefronts room for theming and varied art direction. The later Commerce Engine work reinforced that distinction.

I would make those boundaries explicit earlier in a future system: shared brand foundations, product-specific components, and the reason each belongs where it does. That gives teams a clearer basis for deciding whether a new need belongs in the system or in the product.

Define contribution guidance from the start

A centralized core could have become a bottleneck. Our hybrid model paired shared standards with contributions from embedded teams, supported by recurring design–engineering reviews.

For future work, I would define contribution and review guidance alongside the first components: who owns the shared rules, how teams propose an extension, and how we judge whether it is reusable. The system needs a clear way to evolve as well as a clear starting point.

The first rollout established a shared foundation. The next opportunity is to reduce the manual work involved in using and maintaining it.

We are experimenting with AI-assisted prototyping to help designers turn product intent into coded concepts using the system's existing components. This is an exploration, separate from the rollout results above.

Longer term, we want component and token updates to move more smoothly between design and implementation. Any connected workflow would still need review so changes stay aligned across the system.