Unifying 23 microsites into one scalable design system
Publix needed a faster way to launch microsites for campaigns and community groups without sacrificing consistency or accessibility. I lead the design of a headless design system that streamlined design and development, reduced time-to-market by 40%, and gave Publix a flexible foundation to scale across audiences and teams.
The Challenge: A Fragmented Microsite Ecosystem
Publix was managing 23 independent microsites for campaigns and community groups, each designed and developed in isolation. This fragmentation created duplicated work, inconsistent design, and longer launch times. The challenge was to build a headless design system that could unify these microsites, accelerate launches, and support diverse audiences while maintaining brand trust.
Working with the design and engineering teams, we identified:
Fragmentation: 23 microsites each with their own design, workflows, and technical debt
Inconsistency: No shared components or tokens, leading to uneven experiences across sites
Inefficiency: Template changes required 2-3x more engineering time without reusable foundations
Scalability: New site launches were slowed by lack of shared standards and governance
The business impact: Maintaining separate sites required two to three times more engineering effort, slowed time-to-market for campaigns, and risked inconsistent brand experiences that could erode customer trust.
Project Details
My Role: Lead Systems Designer
Team: UX Researcher, 4 Product Designers, Engineering Teams (Front end, Backend), Product Manager, Marketing Stakeholders
Scope: Design System Architecture, Component Library, Tokenization, Governance & Contribution Model, UX Foundations, Documentation
Timeline: 2.5 years (Discovery & audit: 3 months, Foundation & pilot sprints: 9 months, System rollout & adoption: 12 months, Ongoing maintenance & evolution: 6+ months)
Scale: 23 microsites unified, 40+ reusable components created, 60% reduction in design effort, 40% faster time-to-market
Process & Solutions
This section outlines the steps taken to unify the microsites into one scalable design system and the decisions behind them.
Audit
This section outlines the steps taken to unify the microsites into a single, scalable design system, as well as the decisions behind these efforts.
This revealed more than a dozen redundant patterns and provided a clear map of where consolidation would yield the most significant time savings.
Rather than auditing only high-traffic pages, we chose to review every microsite to ensure unique requirements weren’t overlooked, a slower start that paid off with smoother adoption later.
The audit also established the baseline business cost, showing leadership that maintaining separate sites required two to three times more engineering effort.
Technical Collaboration & Adoption
Working closely with engineering, I translated design requirements into clear component specifications—defining states, variants, and behavior rationale that informed implementation. We established a "brownfield-to-greenfield" migration strategy: new sites launched on the system immediately, while existing sites adopted components incrementally during planned updates.
Overcoming Resistance: The biggest challenge wasn't technical—it was cultural. Teams worried about losing creative control or that "their site was too special" for a shared system. We addressed this by:
Involving resistant teams in component design to ensure their needs were represented
Building flexibility through tokens and variants rather than rigid, one-size-fits-all patterns
Documenting clear contribution processes so teams could propose new patterns
Foundations
We defined foundation layers that made the system predictable and themeable across microsites. Using design tokens, we organized color, type, spacing, border, shadow, and motion into semantic tokens (e.g., brand/background, content/primary, action/hover) mapped to primitives for easy theming. This approach allows teams to swap brand palettes without modifying component logic.
These foundations reduced duplication and established a clear design language, making cross‑site updates more efficient.
The trade‑off was front‑loading time to define and test variables rather than patching issues microsite by microsite, a choice that saved significant effort later.
By quantifying and standardizing these foundations, leadership could see the business value: fewer design inconsistencies, faster engineering implementation, and stronger brand trust.
Created semantic tokens themed by surface color, applied consistently across text, icons, borders, forms, and other UI elements for scalability.
Defined color primitives as raw baseline values to support mapping into semantic tokens for theming and scalability.
Documented colors and accessibility, mapping background colors to tokens for reference outside variables.
Clear roles were defined for brand vs. neutral surfaces, accessible foreground/background pairs, and state tokens for hover/focus/active/disabled states, ensuring compliance with WCAG 2.2 AA accessbility.
Color & theming.
Typography
A responsive type ramp with named roles (Display, H1–H6, Body, Meta) plus guidance on line length, scale steps, and usage. Tokens for size/weight/line-height keep headings and body consistent across pages and devices.
Documented typography in a type ramp, mapping semantic tokens for organization and reference outside variables.
Created semantic tokens for font sizing across breakpoints to ensure responsive typography.
Spacing & layout
A consistent spacing scale and grid rules for gutters, columns, and component padding. We documented minimum interactive target sizes and touch spacing to improve mobile ergonomics.
Documented spacing tokens in the base file — including inset, stack, inline, and page — to create predictable layout rules and ensure consistent alignment across components.
Created semantic spacing tokens themed by breakpoint to support responsive layout and consistent alignment across components.
Components
We built a reusable library focused on editorial and marketing needs while supporting utility UI.
Structure & documentation.
Each component includes:
Properties & variants (what changes, what doesn’t)
States & behaviors (hover, focus, error, loading, disabled)
Responsive rules (stacking, truncation, reflow)
Content guidance (character ranges, image ratios, alt-text)
Well documented Documented form components—including inputs, checkboxes, radios, toggles, and listboxes—with clear states and accessibility guidance.
Documented components with variant properties and in-component guidance, including character counts and quick links to Storybook.
Component Impact
The component library created consistency across microsites, reducing design and engineering duplication and allowing for the faster rollout of editorial and campaign content. By investing time upfront to define detailed states, behaviors, and guidance, rather than leaving them implicit, which slowed initial builds, we ensured smoother scaling and fewer one-off fixes.
Finally, clear documentation built trust with engineering, cut down on handoff questions, and accelerated launches, directly reducing the time-to-market for marketing initiatives.
Storybook Documentation
To ensure the design system was not only built but usable, I created documentation directly inside Storybook.
Authored Markdown-based docs from our component anatomies, best practices, and usage guidelines, making Storybook a living catalog.
Provided a component catalog for quick access, reducing the time editors and developers spent searching for guidance.
Enabled inline content testing, allowing editors to experiment with copy directly in Storybook before publishing.
Maintained Figma ↔ Storybook parity, ensuring what designers saw in Figma matched the working coded components.
This approach transformed Storybook into more than an engineering sandbox — it became the central source of truth for design, editorial, and development teams.
Example of Storybook Connect in Figma, enabling components to be tested directly in Figma with live Storybook data.
Component Impact
This approach transformed Storybook into more than an engineering sandbox — it became the central source of truth for design, editorial, and development teams.
Storybook became the single source of truth, giving both design and engineering confidence that components would behave as expected in production.
It required extra upfront work to align every component spec with Storybook, slowing early progress but paying dividends later.
Reduced misalignment cut rework cycles and QA issues, saving engineering hours and accelerating launches while reinforcing accessibility compliance.
Pilot Approach
Before scaling, we validated the system through targeted pilots. These allowed us to:
Test component flexibility on selected microsites
Prove cross-platform usability (web, mobile, internal tools)
Collect feedback from editors and engineers in real use cases
Pilots reduced risk and demonstrated component flexibility, building confidence for system-wide rollouts. The added coordination slowed scaling in the short term, but ensured smoother adoption. By validating with real teams, we reduced resistance, proved ROI, and prevented costly rework across future launches.
Workshopped goals, objectives, and user journeys with stakeholders before launching new sites.
Governance & Adoption
To embed the system long-term, we focused on adoption practices:
I facilitated breakout sessions with the design team to test system usability and gather feedback
We roadmapped upcoming microsites using the system as the foundation
Annual onsite sessions helped teams explore “big ideas” for evolving the system beyond current needs
Governance practices were documented, ensuring consistency while allowing flexibility for future growth
These efforts ensured consistent adoption and reduced resistance across teams, preventing fragmentation and reducing costly rework later. By investing in governance and adoption early, the business gained confidence in long-term scalability, lowering maintenance overhead and ensuring smoother, faster launches.
Governance workshop to define roles and responsibilities between Publix and 10up designers.
Annual onsite roadmapping workshop, later translated into FigJam for ongoing documentation and alignment.
Designing for Publix wasn’t about producing a single library, it was about building a living system that could flex across microsites, serve very different audiences, and keep growing alongside marketing and design needs.
The work proved that a design system can be both efficient and adaptable, cutting overhead while supporting unique community-driven microsites.
Reflection
23 sites
Launched using the design system of 1 year
60%
Reduction in upfront design effort.
40%
Faster time-to-market for new microsites.