ATA National Title Group Multi-Brand Platform & Design System

A modernization of eleven disjointed brand sites into a single governed WordPress Multisite, with shared design language where it matters and deliberate flex where it doesn't.

Role

Design, UX, Development

Platform

WordPress Multisite

Timeline

Aug 2025 - Mar 2026

Link

Website External link

Overview

One platform, eleven brands, one design system

ATA National Title Group operated eleven separate brand websites: the parent corporate site and ten regional and product sub-brands absorbed through years of acquisition. Each site was maintained independently, with drift in visual standards, duplicated content structures, and inconsistent experiences that made the network hard to run and harder to evolve.

This project consolidated all eleven sites into a single WordPress Multisite, modernized the public presence, and introduced governance around what’s centralized and what each sub-brand can still own. The intent was a platform that reflects how the organization actually operates: one parent brand, ten distinct sub-identities, shared operational spine.

The objective: build a system that reduces the cost of network-wide change from eleven edits to one, without flattening what makes each brand distinct.

The Challenge

Unify the network without flattening the brands

Every global change cost eleven edits, but forcing the brands into a single template would strip what made each one worth preserving.

Focus #1

A shared design language that flexes per brand

Focus #2

Modular templates usable across all eleven sites

Focus #3

Clear governance for what's centralized vs. locally customized

Focus #4

An editor experience a non-technical team can run confidently

Process

Discovery & Behavior Analysis

Discovery grounded the new system in how users actually moved through the existing sites, not how the team assumed they did.

  • Ran Microsoft Clarity across the legacy sites pre-launch to gather heatmaps, session recordings, and navigation patterns
  • Reviewed Google Analytics to separate intentional user behavior from friction and drop-off
  • Interviewed internal stakeholders to surface operational pain points across the network
  • Switched to PostHog post-launch to continue measurement on the new platform and feed ongoing iteration

Pre-launch findings became design decisions. Post-launch data keeps the feedback loop open.

Clarity heatmaps

Analytics analysis

Clarity session recording

Design

Design System

The visual system was built as a shared foundation of tokens and components, with deliberate extension points where each brand could diverge without forking.

  • Defined a token system covering color, typography, spacing, layout, and component states, so every sub-brand inherited the same visual language before brand-specific tokens layered on top
  • Built a component and page-template library covering every content shape the network required: one implementation each, reused across all eleven sites
  • Configured the block editor with custom content blocks, shared styles, and locked-down color and font-size inputs. Editors build within-system by default, not free to drift
  • Established a site-keyed override pattern so any sub-brand could own its own styles, scripts, or specific page pieces when a genuine need arose, without touching the shared theme

The result is a design system that eleven distinct brands could live inside without blurring together or forking apart. Brand consistency became the default behavior, not something a reviewer had to catch.

Example brand comparison

Primary site design tokens

Build

The Locations System

A unified locations system gave the network one source of truth for every office across eleven brands, surfaced wherever it needed to appear and filtered in real time on the public side.

  • Custom content type managed from a single network-wide admin surface, so locations are added or updated in one place rather than duplicated per site
  • Real-time, state-based filtering on the public side, built to narrow over 60 locations to the ones relevant to the user’s geography
  • One record, many surfaces: a location edited once flows through to every site that references it, rendered natively inside each brand’s visual treatment
  • Editor workflows designed so anyone on the team can maintain location data regardless of which brand owns the page it appears on

Before this system, location information duplicated across eleven sites and quietly drifted out of sync. Now the network treats locations as shared data rather than per-brand content, while still letting each brand present them as its own.

State filtering on the public side, allows real-time filtering via JSON

One location record, shown on any subsite's location page that is applicable.

Build

The Governance Model

The governance layer is where “shared spine versus local flex” moves from concept to code. Every shared setting has a parallel network-level default that any site can override: headers, footers, CTAs, navigation.

  • Built a three-tier resolution pattern (per-site value → network default → hard-coded fallback) so one change at the top propagates everywhere nothing has explicitly been overridden
  • Mirrored each site’s admin page with an admin-only network version, using the same structure and fields: familiar surface, different scope
  • Wrote a one-click migration to move existing per-site values up into network defaults: safe to run, with a summary of what moved and what didn’t
  • Ensured network defaults never overwrite explicit per-site values; fallback only activates when a site has left a setting empty

Before: eleven sites each edited independently for every global change. After: editors update the network default once; any site can still override where the brand requires it.

That shift, from eleven edits to one without losing the ability to diverge, was a primary reason the client engaged with me on this.

Build

Editor Experience & Operational Tooling

The admin experience was shaped to match operational reality, not default assumptions: organized, guarded, and branded end-to-end.

  • Rebuilt the admin sidebar across all eleven sites with grouped sections and clear labels, so editors skim past technical settings and find what they use
  • Introduced a custom User Manager role for controlling agent access to the Sales Portal’s document-sharing tools, built around how the business actually assigns permissions
  • Branded every touchpoint the design system could reach: per-site login pages, per-brand password reset URLs, wrapped transactional emails and form notifications, and an in-admin onboarding guide
  • Shipped deploy, backup, and migration tooling across development, staging, and production environments, including a command-line tool for data integrity repair

Everything outside the obvious “design the homepage” work was treated as a design problem, because it’s the part the client’s team lives inside every day.

Device Screens

Closing Thoughts

The platform consolidated an eleven-site network into a single WordPress Multisite, built around one design system, one governance model, and one set of operational tools. It:

  • Unified eleven legacy sites into a governed multisite with shared design tokens and a network-wide component library
  • Introduced a governance model so editors update global content once and override per brand only when it matters
  • Manually migrated 200+ pages as a deliberate audit opportunity, giving every brand a clean content pass during the move
  • Built a non-technical editor experience from the admin menu up: guardrails, organized options, purpose-fit roles, in-admin onboarding
  • Launched with measurable performance: 0.02 CLS, 1.5s Time to Interactive, and 2.0s Fully Loaded Time

The result is a platform that reflects how the organization actually operates and scales with its growth rather than against it.

What would I have done different if I had to do it again?

  • Ship a documented brand token contract. Today each per-brand override can tweak anything it wants. A fixed list of tokens each sub-brand is required to override (and nothing else) would keep the system tighter as more brands come on.
  • Move the remaining hard-coded per-brand logic out of code. A few per-site behaviors still live in templates rather than settings. Moving them into the governance model would let non-developers change them without a deployment.
  • Build per-brand previews into the styleguide. Seeing all eleven brands render the same component side by side would catch visual regressions before they reach live.

The system, as shipped, does what it was built to do. Iteration is required to grow, though, so I’ll be continuing on this journey with them as maintenance partners.