ATA National Title Group Multi-Brand Platform

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, and Audit

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 for heatmaps, session recordings, and navigation patterns
  • Reviewed Google Analytics to separate intentional behavior from friction and drop-off
  • Cataloged the eleven existing sites to separate intentional brand differentiation from accidental drift
  • Interviewed internal stakeholders to surface operational pain points
  • Drafted the governance split (shared spine versus per-brand flex) from audit findings
  • Switched to PostHog post-launch to continue measurement on the new platform

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.

Three sub-brands rendered through one underlying system. Shared structure, brand-applied on top.

The token foundation every sub-brand inherits before brand-specific tokens layer on.

Design

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.

One location record, shown on any sub-brand's location page that is applicable.

One location record lives as the master to other sub-brands

Build

Platform & Governance Model

Eleven sites run on one WordPress install with a governance layer on top that lets shared settings cascade network-wide, and per-site overrides hold their ground where a brand genuinely needs to diverge.

  • Multisite setup where each sub-brand runs its own apex domain on a single underlying install, sharing code while keeping content isolated
  • Content structure treated as code: post types, field groups, and templates versioned and deployed like any other change, rather than drift-prone database configuration
  • Three-tier resolution pattern (per-site value → network default → hard-coded fallback), so one change at the top propagates everywhere nothing has been explicitly overridden
  • Mirrored admin surfaces: each site’s settings page has a network-level twin with the same fields, so Super Admins set defaults through a familiar interface rather than a separate one
  • One-click migration tool that moved existing per-site values up into network defaults, with a summary of what moved and what didn’t, and without overwriting anything a site had explicitly set

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.

What's shared, what's overridable, what each brand owns.

Eleven branded sites. One shared platform underneath.

Same schema, different scope. Editors have per-site control, Super Admins can set network defaults.

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.

Reorganized admin bar to assist for clarity with common editors

Branding reached every edge of the system, including the login screen.

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.