Town Web
2024
Building a Multi-Theme Design System for Scalable City Websites
Transforming separate city website styles into one flexible system that allows teams to launch distinct municipal experiences without redesigning or rebuilding the same interface every time.
Overview
One system. Multiple city identities.
Focus
Multi-theming · Design tokens · Figma variables · Component architecture
Contribution
System architecture, component standardization, themes, documentation, testing, and developer handoff.
Town Web creates municipal websites for cities and local authorities. Although these websites share similar content structures and functionality, every client needs a visual identity that reflects its location, audience, and brand.
The existing approach relied on separate templates and repeated customization. Designers restyled similar sections for each project, while developers repeatedly translated those visual differences into code.
The goal was to create a single scalable system that could support different visual identities through configurable themes — without rebuilding components or maintaining separate foundations for every website.
One shared website architecture expressed through three distinct themes.
The project was not about creating more templates. It was about making one system flexible enough to replace them.
The Challenge
Scaling customization without scaling complexity
The challenge was not simply to create another component library. The system had to balance two needs that usually pull in opposite directions.
Consistency
Components, interaction patterns, spacing logic, responsive behavior, accessibility, and implementation needed to remain standardized.
Flexibility
Each municipality still needed to feel distinct through its colors, typography, shapes, imagery, spacing characteristics, and visual personality.
How might we create one website system that can feel unique for every city without redesigning or rebuilding it every time?
Problem space
Repeated work was hidden inside every new website.
Repetitive design work. Designers repeatedly recreated or restyled similar website sections for different municipalities.
Fragmented templates. Multiple templates evolved independently, producing duplicated components and inconsistent design decisions.
Expensive customization. Visual changes required manual updates across many screens, states, and components.
Difficult developer handoff. Design values were not always represented in a structure that developers could reuse directly.
Limited scalability. Every additional city introduced another layer of design and front-end maintenance.
[Placeholder — replace with a visual of the fragmented template landscape.]
The Opportunity
Treat every template as an expression of one underlying system
Instead of maintaining several finished templates, we could identify what they shared, preserve the meaningful differences, and convert those differences into configurable theme decisions.
From templates to a master architecture
Existing city templates
Shared patterns
Master components
Theme variables
Design tokens
Multiple branded websites Airy spacing, teal-led color, softer surfaces, and a calm civic tone.
[Placeholder — replace with the architecture diagram.]
This became the foundation of the Town Web Multi-Theme Design System: one component architecture that could inherit different visual identities through tokens and variables. Stronger contrast, deeper blue-green surfaces, and gold accents for a more institutional identity.
Consolidating common patterns before defining themes
The first step was to compare the existing website templates and identify the sections, behaviors, and content structures that appeared repeatedly. Similar elements were consolidated into shared component families instead of being maintained as separate template-specific designs. Balanced teal and yellow accents with a practical, information-forward presentation.
Audit. Compare existing pages, sections, states, and responsive behavior.
Consolidate. Merge repeated patterns into reusable master components and controlled variants.
Abstract. Move visual decisions out of the components and into shared variables and tokens.
Components owned structure and behavior. Themes owned visual identity.
Architecture
A shared foundation with theme-controlled decisions
The architecture separated reusable decisions from theme-specific choices. Components referenced semantic variables rather than fixed visual values. Each theme changed the values behind those variables while keeping the component logic intact.
Layer | Responsibility | Examples |
|---|---|---|
Foundation | Raw reusable values | Color scales, font families, spacing scale, radii |
Semantic tokens | Context and intent | Background, text, border, action, emphasis |
Components | Structure and behavior | Navigation, hero, quick links, cards, calendar, footer |
Themes | Brand expression | Country/city colors, typography, density, shape treatment |
Illustrative theme-switching logic
:root[data-theme=coastal] {
--color-brand-primary: #0a6f78;
--color-accent: #f28c28;
--radius-card: 20px;
}
:root[data-theme=civic] {
--color-brand-primary: #0b4155;
--color-accent: #e2c01b;
--radius-card: 8px;
}
This is an illustrative representation of the theme-switching logic, not a claim about the exact production variable names.
The same experience can speak in three visual voices
The three themes use the same website structure and core components. Their identities change through controlled decisions such as primary and accent colors, typography, corner treatment, spacing feel, imagery, and emphasis.
The same architecture rendered as three distinct municipal identities.
Theme 01 — Coastal. Airy spacing, teal-led color, softer surfaces, and a calm civic tone.
Theme 02 — Civic. Stronger contrast, deeper blue-green surfaces, and gold accents for a more institutional identity.
Theme 03 — Regional. Balanced teal and yellow accents with a practical, information-forward presentation.
These are portfolio labels used to explain the visual differences, not official production theme names.
Workflows
Designers configure a theme instead of rebuilding a website
The system limits unnecessary one-off decisions. Designers work inside a defined architecture and change the properties intended for customization, while shared component behavior remains protected.
Choose the shared page and component structure.
Select or duplicate a predefined theme mode.
Update controlled brand variables and content imagery.
Review responsive states and accessibility before handoff.
[Placeholder — replace with the designer workflow diagram.]
Theme decisions move from Figma to reusable code
Figma variables → design tokens → JSON → CSS variables → shared front-end components → themed website
The handoff model gives design decisions a reusable technical structure. Developers do not need to manually interpret every visual difference from individual screens. The same front-end components can inherit a new identity by consuming another theme configuration.
Change the theme values, not the component implementation.
Validation
The workflow should be tested on a small set of representative components before being extended across the full website. The hero and quick-links sections are useful pilots because they combine typography, color, imagery, spacing, content hierarchy, and interaction states.
Visual parity. Confirm that Figma theme values produce the intended website appearance.
Component resilience. Test long content, different images, states, and responsive breakpoints.
Token export. Verify that exported variables retain clear names and usable value formats.
Developer feedback. Refine naming and structure based on implementation needs rather than design assumptions alone.
Outcome
A repeatable foundation for distinct municipal websites
Key decisions
Flexibility needed boundaries.
Merging different templates. Preserve real structural differences as controlled variants, but remove differences that existed only because the templates had evolved separately.
Avoiding component overload. Use variants for meaningful changes in layout or behavior. Use variables for visual properties that themes should control.
Keeping themes usable. Offer predefined, tested configurations instead of exposing every low-level property to every designer.
Connecting design and code. Use naming and token structures that make sense in both Figma and front-end implementation.
Protecting accessibility. Treat contrast, focus states, text legibility, and interactive states as system requirements for every theme.
The final direction replaced the idea of separate finished templates with a shared system. Town Web could maintain one component architecture while expressing different city identities through controlled themes.
[Placeholder — replace with the final outcome visual.]
Shared foundation. One source of truth for recurring municipal website patterns.
Faster customization. Visual identity changes happen through theme decisions rather than page-by-page restyling.
Clearer handoff. Variables and tokens give design decisions a structure developers can reuse.
Easier maintenance. Improvements to shared components can benefit every website built on the system.
A scalable design system is a shared operating model
The strongest result was not the number of components or variables. It was the agreement between design and development about which decisions should remain consistent, which could change by theme, and how those changes should move from design into production.
Start with the repeated workflow problem, not the token taxonomy.
Validate design-to-code behavior on a small pilot before scaling.
Flexibility becomes useful only when the system makes its boundaries clear.
