Case Studies of Experience Design | Thinking Made Visual

The engagement ran roughly two years, ending when I transitioned to a different role, not when the work concluded. Multiple teams were involved: the author's own design track, at least one peer design team pursuing a different technical approach, product management, and the feature product owners feeding them specs. The author's scope was the customer-facing side of the modernization specifically, the household data and service experience agents used day to day, not the platform's full technical build, and not a separate, related back-office tool the business also had in flight for agents' own business management (a distinct effort, outside this case study's scope).

Worth stating plainly: this account covers what happened up to that departure. It is not a launched-and-measured story, and it doesn't pretend to be one.

Independent agency office workers aren't a captive audience. They run their own businesses, and the CRM is the tool they use to serve their own customers. Force a migration onto a system that doesn't reflect how they actually work, and there are exactly two outcomes: the rollout stalls, or agents route around it in ways that eventually reach the customers those agents serve. Neither is acceptable when the thing being modernized is the tool people use to manage another person's insurance, their bills, and the life events attached to both.

That's the stake that made this more than an internal tooling decision. A failed migration here doesn't just cost the business money. It puts the actual service someone receives from their insurance agent at risk.

The real gap wasn't in the level of detail in the specs. It was in where the specs came from. Product managers had been collecting requirements from feature product owners inside the company, people responsible for a product line, not people who spent their day inside an agent's actual workflow. Nobody in that chain had asked the agents themselves how they worked, what they needed in front of them first, or what a household actually looked like from their side of the desk.

That assumption wasn't unique to this work stream. Around the same time, I was separately asked to map a customer-service scenario, because, again, no one else had documented how that particular interaction actually worked. Two different requests, the same missing piece: an organization that had built a spec-review process with no seat at the table for the people the specs were about.

Once that was visible, the fix wasn't better documentation of the old plan; it was a new source for the plan. The team ran direct end-user workshops, usability testing, and focus groups with independent agency office workers: not to validate a design that already existed, but to map how their business actually ran, what a household meant in their world, and which scenarios the platform needed to solve for that no spec had captured.

The reframe that came out of it: build the platform for how these agents do their job and run their business, not for how corporate assumed it should work, and not for how a product roadmap had already assumed it could be implemented.

The framework that came out of that research was Hierarchy of Data, a principle for presenting end-user information in stages that match real need, instead of surfacing everything a system holds about a customer at once. Applied to this work stream, it became the household view: instead of an agent working one policy at a time, they'd see a household's full product relationship together, with the details that mattered most- a life event, a lapsed payment, a coverage gap- surfaced first rather than buried under fields that didn't matter to that conversation.

This wasn't a framework built for the case study after the fact. It's the name I used for the framework at the time, and it's a principle the competing peer-team approach, preserving the old system's look and feel through a "lift and shift," didn't share.

The central tension wasn't technical. It was that another design team was already committed to lift-and-shift, keeping the existing interface's shape to minimize disruption, while this workstream's direct evidence pointed toward a structural rebuild. Both sides believed they were representing the end user. Both approaches were described as user-centered, but only one had been tested directly with the agents expected to use the platform.

Resolving that took more than a design decision. It took proving the recommendation against evidence the other approach didn't have: workshop findings, usability sessions, and a direct account of how agents' businesses actually ran. That evidence, not seniority or preference, is what eventually moved stakeholders toward the Hierarchy of Data direction.

One organizational constraint shaped what "the new platform" could even mean: the business didn't want to move off its core CRM platform outright, given the cost of a global platform change. Any recommendation had to work within that constraint, not against it. The household view had to be something the existing platform could actually support, not a clean-slate reimagining that ignored what the business had already committed to.

That's a real tradeoff, not a footnote: the strongest version of an idea is rarely the version that ignores what the organization has already paid for.

Customer Impact: The validated design would allow agents to see a household's full relationship with the company in one place, with life events surfaced rather than buried, meaning conversations with customers could be proactive instead of reactive. This reflects the validated design direction; I did not observe it in live use, since the transition off the project came before launch.

Business Impact: The business avoided the likely alternative outcome of a forced migration built on unvalidated specs, a path that risked either a stalled rollout or agents working around a system that didn't fit their business. Adoption outcome not measured; author transitioned off the project before implementation.

Organizational Impact: Stakeholders and end users validated a working example showing how direct end-user research produced requirements and design decisions that more closely reflected agent workflows. Whether that changed how the organization sourced specs going forward is not something the author was in a position to confirm.

The clearest lesson from this project wasn't about data hierarchies. It was about where trust actually gets built in a migration. Not in the interface, and not in the announcement. In whether the people being asked to move can see themselves in what they're being asked to move to.

What was genuinely surprising, in hindsight, wasn't that the specs were incomplete. Incomplete specs are common. What was surprising was how confidently a competing team believed their own assumption-based approach was already user-grounded, right up until it was tested against people who'd actually go ask. That's not a criticism of the other team's intent. It's a reminder that "we understand the user" and "we asked the user" are not the same claim, and only one of them holds up under a workshop.

Get in touch

Executive Snapshot

Strategic Signals

What Changed: From Legacy Structure to a Validated Product Direction

Deep Dive

My Scope Within a Multi-Team Modernization

Why a Poorly Fitted Migration Created Business Risk

The Problem as Initially Understood: The Specifications Needed More Detail

The Actual Problem: The Specifications Came From the Wrong Source

Changing the Source of Truth Behind the Product

Reorganizing the CRM Around the Household

Using Agent Evidence to Challenge a Lift-and-Shift Direction

Designing Within the Existing CRM Investment

What the Work Changed and What Remained Unmeasured

Strategic Lesson: Migration Trust Begins Before the Interface