Untangling the Hairball

Information Architecture & Journey Strategy

01.-

Context

The Challenge

Neighborly is the parent company of a portfolio of 20+ home service franchise brands, Molly Maid, Mosquito Joe, Mr. Rooter, and others, each acquired with its own website, booking system, and franchise operating model. As the portfolio grew, so did the fragmentation: every brand had a different digital experience, different backend systems, and no shared way for a customer to move from "I need this fixed" to "someone showed up and fixed it."

The deeper challenge wasn't just visual inconsistency, it was structural. A single customer journey actually touches three separate organizational lenses at once: the end customer, the brand's Franchise Owner's point of service platform, and Neighborly's central Call-a-Neighbor platform. None of these had ever been mapped as one coherent system. Before any redesign work could start, that system needed to exist on paper.

Project OPUS, a SaaS CMS platform built on CrownPeak, Tailwind CSS, and Flowbite, was Neighborly's answer to the platform problem. My role was to lead the UX strategy underneath it: define the shared information architecture, align 20+ brand stakeholders around it, and build the design system that let each brand keep its identity while running on common rails.

02.-

Research & Framing

Starting from Jobs, Not Screens

Before mapping any journey, the work was framed around three actual jobs a Neighborly customer is trying to get done, because each one demands a completely different tone and level of support from the brand.

Repair • Maintain • Enhance

This mattered because it became the shared vocabulary for every conversation that followed. When a brand president asked "why doesn't the booking flow work like X," the answer was almost always "because that's a different job than the one X solves for."

Personas Grounded in Real Segments

Rather than inventing archetypes, personas were built on Neighborly's actual customer segmentation (Affluent Empty Nesters, Accumulated Wealth households):

Diane (Adapter) — 53, suburban, owns her home 7+ years. Wants to stay informed and involved: "I've got time, show me options."
Elizabeth (Optimizer) — 36, metro, young family, time-constrained. Wants Neighborly to do the deciding: "I'm so busy, decide for me and I'll review."

These two mental models, "show me" vs. "decide for me", became a recurring design lens for every flow we built afterward, including how much configuration vs. automation to expose in booking.

03.-

Mapping the System

A Six-Stage Journey, Tied to Real Systems

The core deliverable was a full-service journey map spanning six stages: Needs & Planning → Research & Compare → Books Service → Pre-Service & Planning → During Service → Post-Service & Follow-up.

What made this an information architecture exercise rather than a whiteboard exercise was the fourth row: Behind the Scenes, which mapped every stage to the actual platform doing the work, WAM, NCS, Onverity, FO POS, CaN. Every customer-facing "activity" had a corresponding system dependency, which meant the map could be handed directly to engineering, not just used in a workshop.

Stage triggers were defined, the specific event, system action, or user behavior that moves someone from one stage to the next (e.g. "FO sends estimate to user" → moves customer from Research to Book). This turned a descriptive journey map into something closer to a state machine: unambiguous about what has to happen for the customer to progress.

04.-

Aligning the Organization

Turning 20+ Competing Priorities Into One Framework

This system didn't get built in isolation, it came out of structured working sessions with brand presidents, PMOs, engineers, and CRO/SEO stakeholders, each of whom came in with a different definition of "the customer journey" based on their own brand's tools.

These sessions were run using a consistent structure { Stage → Goal → Activity → Touchpoint → Platform } so that every brand's input could be captured in the same shape and compared directly, rather than each brand presenting a custom version of "how our booking works."

The outcome of this alignment work: Got sign-off from brand presidents on the shared journey model with a rolling migration schedule of every 5 weeks (x15). Reduced conflicting requirements entering OPUS design reviews by 60%.

05.-

Designing for Multi-Brand Complexity

One Customer Action, Three Parallel Systems

A single customer action, booking a cleaning, looks linear to the customer, but isn't linear behind the scenes. A booking for "Olivia" simultaneously triggers separate, parallel paths through Neighborly's central CaN platform and two different franchise brands' Field Operations teams (Molly Maid, Mosquito Joe), each with their own scheduling and lead-routing logic.

This was flagged during the mapping work, the diagram carries my own note-to-self: "This needs to be accounted for in the prototype flow." Catching this early meant the prototype and eventual build accounted for multi-brand routing from the start, rather than discovering the gap during QA.

06.-

Looking Ahead

Scoping Future Vision Without Losing the Roadmap

Alongside the near-term OPUS work, a longer-term scenario was mapped for how AI and smart-home data could shift Neighborly from reactive booking to proactive service, e.g. a leak sensor triggering a repair booking automatically, or IoT data prompting a maintenance reminder.

The important discipline here was being explicit about what was in scope vs. out of scope for the near-term demo, so the exploratory thinking informed the roadmap without derailing current sprint commitments.