Absorbing departmental complexity into component contracts without forcing an engineering refactor or content author churn.
One Structure, 46 Departments
Where it started
We needed to redesign websites across the City. It started with smaller departments and scaled to 46. We could not build or maintain 46 bespoke websites. We needed a shared structure that supported radically different content needs, while remaining simple enough for departmental authors to manage independently in the CMS.
The tension between design and engineering showed up immediately:
Design and Product (Departments) wanted enough flexibility for departments to surface what mattered most without flattening their civic purpose.
Engineering needed strict constraints to prevent CMS configuration bloat, layout degradation, and high maintenance overhead.
My instinct was often to preserve more flexibility, while engineering pushed to simplify configuration. The solution lived between those two views.
Three patterns, built before the design system
Before we had a formal design system, our front-end engineer and I co-designed three workhorse patterns live in code to see how much variation a single component contract could absorb:
The Calendar Module: Architected to flex from one event a month to ten events a week, using the same underlying CMS data schema. The dense end held up. The single-event case didn't, and it left awkward empty space. The design system version fixed it with a compact card.
The Hero Module: A modular 3-tier container capable of surfacing emergency alerts, priority civic programs, or routine transactional links depending on departmental urgency.
The News & Resource Grid: Configurable between a single featured release and a multi-card media archive without requiring custom templates or manual CSS overrides.
Every time I pushed for an open-ended layout option, engineering showed how it introduced configuration bloat in Sitecore or created awkward whitespace when content was sparse. They were right: unbounded flexibility in the CMS wasn't empowering authors—it was leaving them to solve layout problems on their own.
I adjusted variables and properties in Figma while engineering tested breakpoint behavior and Sitecore field constraints directly in code. The critical decision was decoupling content schema from presentation: the CMS only cared what the data was, not how it was displayed.
The payoff: Bringing the new design system to web
A major redesign often stalls because backend migrations are expensive and risky. When the citywide rebrand and formal design system were ready to roll out, this architecture paid off:
Frontend Code Swap: Engineering didn't rebuild the CMS or refactor database schemas. They only replaced legacy page templates with our shared, tokenized frontend components and wired existing Sitecore data fields into the new component properties.
Zero Author Churn: Content authors didn't have to migrate data, rewrite articles, or learn a new CMS schema. The fields they already knew remained identical.
Dynamic Rebranding: Applying semantic theme tokens allowed departments like Public Works, Police, and the Library to take on their assigned brand color palettes automatically without writing custom CSS.
One news pattern, 46 departments' worth of needs
The same news component absorbing very different content: a department posting once a month and another posting daily; items with rich imagery and items with none. Authors control the content; the pattern holds the structure, spacing, and accessibility.
A sample news component used by Transportation to show Street Closure
A sample news component used by Human Service Programs to show young family programs
A sample news component used by Police to show Police Logs
Built-in civic access: Layout flexibility with mandatory equity
In the design system, content authors can choose between featured hero layouts, multi-card grids, or text lists based on their story. However, civic access is not optional: the Multilingual Resources block and accessible heading hierarchy are locked into the template structure, guaranteeing that non-English speaking residents have immediate access to translated materials across every department.
Composable Template Contract: Authors choose storytelling layout and media density, while multilingual wayfinding and semantic landmarks remain structurally enforced.
Hero image options
Multi Language support bar design at the bottom
Where the structure flexes
A shared system breaks down if it either forces everything into one shape or allows unlimited customization. We established clear boundaries:
Fixed & Immutable: Information hierarchy, interaction states (hover, focus, active), keyboard navigation, responsive breakout behavior, and WCAG AA contrast compliance.
Flexible & Configurable: Content density toggles (compact vs. expanded) and brand theme tokens.
One resource section, three department themes
The same component in the City, Sustainability, and Public Works themes, each shown in expanded and compact density. Only the theme tokens and density setting change.
What changed in how I work
Earlier in my career, I assumed flexibility meant giving authors more options. Now I see too much flexibility in the CMS as a failure of component architecture. The job is deciding what authors should never have to decide.