Principal Product Designer · Experience Architecture

I design the structure many teams build against.

Most of my work happens between products rather than inside one — the shared interaction models, navigation, and information architecture that keep an ecosystem coherent while eight teams build in parallel. I find the overlaps, gaps, and competing approaches, and settle them before users feel them.

Currently Principal UX Designer at ADP, working across Launchpad, Workforce Now, and ADP Assist. Previously Senior UX Architect at The Walt Disney Company.

Selected work

3 case studies

Building the case for change inside a twenty-year-old system

A platform nobody had approved rebuilding — and how making it visible turned a training problem into an architecture problem.

ADP · Launchpad 2022 – present
Experience architecture, AI workflows

Answers where people needed actions

A knowledge base for the whole Walt Disney Family of Companies kept generating calls. The reason decided what the AI was allowed to do.

The Walt Disney Company 2018 – 2020
Conversational AI, taxonomy, localization

The form that sent you back to the start

New hire onboarding was slow and wildly inconsistent. Contextual inquiry found the loop that the process documentation didn't show.

The Walt Disney Company Talent Acquisition
Contextual inquiry, workflow design

A note on what you'll see here.
This work was done inside enterprise environments and none of it can be shown directly. Every diagram on this site was drawn from scratch for these case studies to illustrate structure and reasoning. No proprietary screens, assets, or client data appear anywhere.

Case study 01 · ADP Launchpad

Building the case for change inside a twenty-year-old system

Launchpad is the platform ADP's implementation specialists use to move new clients onto Workforce Now. It is two decades of accretion, and nobody had approved rebuilding it. This is how I made the problem visible, shipped inside the constraint, and built the argument for the overhaul.

Role: Principal UX Designer — Launchpad, Workforce Now, ADP Assist
Team: 2 product designers, 1 content designer, 1 researcher; partnered with product and several engineering teams
Timeframe: 2022 – present
Status: Benefits chat experience in final pilot; general availability September

01
The system

A platform nobody owns the rebuild of

ADP serves over 1.1 million clients across more than 140 countries and pays over 42 million workers. Before any of that happens, a new client has to be moved off whatever they were using and onto an ADP platform. That migration is the job of implementation specialists, and Launchpad is the tool they do it in.

Launchpad has grown for twenty years by accretion. Five distinct workflows live inside it — assignments, benefits, spin-offs and mergers, Canadian tax, and general ledger import — each added at a different time, by a different team, to solve a different problem. There is no mandate to overhaul it. Work arrives through three channels: requests from the field, ongoing maintenance, and the company's AI initiatives.

That constraint defines everything that follows. I could not propose a rebuild and wait for approval. I had to ship useful work inside the system as it exists while assembling the evidence that would make the larger case.

Diagram scrolls sideways →

Fig. 1 — The territory. Five workflows inside one platform, each built at a different time by a different team, with no shared model between them.

02
The number

The system was training people right up until they left

The clearest measure of Launchpad's condition was not a satisfaction score. It was how long it took a new implementation specialist to become useful.

A year to competence. A second year to proficiency. By then, most specialists were ready to move to another role.

That is a two-year investment producing a short return, repeated with every hire. It was also the number that leadership recognized immediately — far more legible than any argument about consistency or pattern debt.

03
Making it visible

Nobody could see the system whole

When I arrived, work was moving forward in parallel across teams with no shared picture of what existed. Each team knew its own area. No one held the whole.

So the first thing I built was not a design. It was a map. In Miro, my team and I documented the current state of each workflow against a proposed future state, and laid them on one surface so the relationships between areas were visible for the first time. Flows and maps live in Miro; UX requirements, personas, and research notes in Confluence; wireframes, content audits, and clickable prototypes in Figma; tickets and Kanban shared with product and engineering in Jira.

We review the maps as a team every two weeks — partly to keep them accurate as the system changes, partly because the review itself surfaces things no individual team would have reported.

Nothing like this had existed before. That matters more than it sounds. The overhaul agenda I am now building with leadership is only possible because there is finally a shared picture to argue from. You cannot make the case for rebuilding a system that no one can see.

04
The finding

What the field told us

A year ago I flew to a field office and ran a workshop with implementation specialists and their managers — the people who live in Launchpad every day. Some assumptions were confirmed. One finding reframed the entire problem.

Launchpad does not reliably save what you put into it. So specialists had independently arrived at the same workaround: they kept their client notes and working documentation in personal OneNote files. It works — for them. It is invisible to everyone else on the team.

Follow that thread and the training number stops being a training problem:

Diagram scrolls sideways →

Fig. 2 — The mechanism behind the training number. A data-retention failure produces a private workaround, which prevents knowledge from accumulating, which is what actually makes the ramp twelve months long.

This is the observation the case study turns on. The steep learning curve is not a training problem wearing a training problem's clothes — it is a data-retention problem. Better documentation and better onboarding would not have fixed it. Every request I had been fielding one at a time was a symptom of the same architectural failure.

05
Being wrong

The assumption we lost

We were confident that implementation specialists would not want to do this work in a chat window. These are people handling dense, high-consequence benefit configurations; a conversational interface felt like the wrong instrument for precision work.

Our engineering partners disagreed, and the debate ran for a while. We conceded. The benefits experience was built around a chat-led interaction, and rather than defend the original position we instrumented it — watching what specialists actually do inside the new experience rather than what we predicted they would want.

I include this because it is the most useful thing in the project. A design organization that cannot lose an argument to its engineers is not collaborating with them, and the monitoring we put in place because we were unsure is now better evidence than certainty would have produced.

06
The design

AI fills, the human corrects, no one gets trapped

The benefits work replaces a manual process: reading client benefit documentation and re-keying it into the system by hand. AI now handles collection, analysis, and distribution of that information into the right places.

The design principle that came out of the research is the part I would carry to any AI product. Automation is a default, never a cage. We still built manual form flows — as a backup when extraction fails, and as an editing path over whatever the system filled in on its own. A specialist can always see what the AI decided and overrule it.

Diagram scrolls sideways →

Fig. 3 — What changed. The before path lets knowledge escape into private files; the after path keeps it in the system, with a manual route that is a permanent feature rather than an error state.

07
Where it stands

Live in September, and genuinely contested

The integrated chat experience is in the final stages of pilot and turns on for all clients in September. There was significant pushback from associates when it arrived — it asks people who have done this work one way for years to do it a different way — and they are adapting.

I would rather report that honestly than claim a win that has not been earned yet. The question the pilot is answering is not whether specialists like the new experience. It is whether the work stays inside the system this time, or whether OneNote quietly comes back.

Across Launchpad more broadly, the newer systems have cut specialist training from roughly twelve months to six, with a three-month target — a program-level result that many teams contributed to, mine among them. In the AI-led areas the ambition is higher still.

months · before

Time to competence in legacy Launchpad

months · today

After the newer systems across the platform

months · target

Where the program is aiming next

08
Carry forward

What this taught me

Draw the system before arguing about it. The overhaul agenda exists because there is finally one surface where the whole platform is visible. No map, no argument.
Recurring requests are a diagnosis. The individual tickets were real, but the pattern across them was the actual finding — and it only appeared once I stopped treating them as separate.
Go to where the work happens. The OneNote workaround would never have surfaced in a survey or a remote session. It surfaced in a room, in a field office, from people describing what they actually do.
Automation is a default, not a cage. Every AI path needs a manual one beside it — for failure, and for the human who knows something the model doesn't.

Conceptual diagrams, created for this case study.
All figures on this page were drawn from scratch to illustrate structure and reasoning. They are not reproductions of ADP screens, artifacts, or documentation. No proprietary assets or client data appear here. Figures shown at their current draft state.

← All work

Case study 02 · The Walt Disney Company

Answers where people needed actions

A knowledge base served the entire Walt Disney Family of Companies, and cast members kept calling anyway. The reason turned out to be simple enough to say in one sentence — and it decided what we built, what the AI was allowed to do, and where it had to get out of the way.

Role: UX lead — brief, user requirements, flow models, design system components; point person to the AI/ML teams
Program: 7 vendor organizations, 3 overseas content teams (India, China, Japan), internal contributors in Florida and California
Timeframe: Late 2018 – early 2020
Outcome: ~25% call reduction on catalog items handled by the chatbot, measured mid-program

01
The system

A knowledge base with a phone problem

The knowledge base served cast members across the entire Walt Disney Family of Companies — domestic and international, park operations to corporate. It existed, it was maintained, and people used it. They also called the service desk constantly.

The program's goal was blunt: reduce call volume by any means available. The instrument chosen was a machine-learning chatbot with natural-language search and live chat, built on ServiceNow. Around it sat seven vendor organizations — two development teams, an information architecture agency, and four working on the AI and ML — plus content teams in India, China, and Japan authoring in their own languages, and internal contributors in Florida and California.

My job was to make those pieces produce one coherent experience. I wrote the initial brief the IA agency worked from and the user requirements in the BRD, coordinated and facilitated the interview sessions, refined the flow models and diagrams that came out of them, and served as UX lead and point person to the AI/ML teams. The KPIs — processing time, digital channel adoption, call deflection — were set by product and the business unit.

02
The insight

The article was excellent. It was also useless.

Search the knowledge base for change my address and you got a well-written, accurate article explaining how to change your address. Clear steps. Correct information. Someone had done a good job writing it.

It explained how to change your address instead of taking you to the place where you change your address.

That is the entire call volume problem in one example. The knowledge base was answering questions when people were trying to complete tasks. If the article doesn't finish the job, you call someone who will — and the better the article is, the more insulting the dead end feels.

Diagram scrolls sideways →

Fig. 1 — Why a well-written knowledge base still generates calls. An accurate article that ends without an action is a dead end with good grammar.

03
The brief

Fix the structure, not the interface

The obvious move was to redesign the knowledge base's interface. I briefed the information architecture agency to attack the structure instead — the taxonomy, the labels, and the paths through the content.

They were excellent, and I managed their work rather than doing it: they mapped the dead ends, ran card sorting to pull labels from cast members' own mental models rather than IT's internal vocabulary, and reorganized the content into groupings that a person could follow and a machine could parse.

That second requirement is why the structural work mattered more than the visual work. A chatbot resolving intent and asking disambiguating questions is only as good as the organization of what it is drawing from. Taxonomy stopped being a findability problem and became a machine-comprehension problem — and no interface redesign would have touched it.

04
The design

Where the chatbot had to get out of the way

As UX lead and point person to the AI/ML teams, I defined and built the visual mocks, prototypes, and components on Snowball, Disney's internal cast-facing design system — so the conversational surface belonged to the same family as everything else cast members used.

The rule that came out of the address example governed the whole interaction model. Conversation is good at working out what you meant. It is bad at collecting structured data. Asking someone to supply a street address, unit number, city, state, and postal code one message at a time is slower and more frustrating than the form they already know how to fill in.

So the chatbot's job was to resolve intent and hand off. Understand the request, disambiguate when the request was unclear, then route to the thing that actually completes the task — and stop talking.

Diagram scrolls sideways →

Fig. 2 — The interaction model. Conversation earns its place resolving ambiguity; the moment the request becomes a structured task, the chatbot hands off rather than collecting fields one message at a time.

05
Across languages

Three content teams, one behavior

The teams in India, China, and Japan owned their own language and content. That was correct — nobody in California should be writing Japanese knowledge base articles for cast members in Japan.

What could not vary was how the chatbot behaved. I worked directly with each team so that intent resolution, disambiguation, and the handoff to a form or an article worked the same way in every localized experience. Local content, shared behavior. A cast member in Shanghai and a cast member in Orlando should encounter the same system, speaking their own language.

06
What moved

About a quarter, on the part we had done

Attributing call reduction cleanly is hard in an organization this size, and I want to state this the way it actually was. For the catalog items that had been added to the chatbot, the best estimate while I was still on the project was roughly a 25% reduction in calls. Partial scope, measured mid-flight, directional rather than final — and a good enough signal to keep going.

The roadmap after that was to move more HR functions into genuine self-service, which is the logical continuation of the address problem: stop explaining the task, complete it. I moved to another project before that work happened.

07
Carry forward

What this taught me

A good article can still be a dead end. Content quality and task completion are different problems, and measuring the first tells you nothing about the second.
Chat is not a form. Conversation is the right instrument for working out what someone meant and the wrong one for collecting structured data. I have applied this in every AI project since — including insisting on manual form paths beside the AI at ADP.
Taxonomy became an AI problem. The structural work I briefed was not housekeeping; it was the substrate the model reasoned over. Badly organized content produces a badly behaved assistant.
Localize content, standardize behavior. Regional teams should own their language. Nobody should own their own interaction model.

Conceptual diagrams, created for this case study.
All figures on this page were drawn from scratch to illustrate structure and reasoning. They are not reproductions of Disney screens, artifacts, or documentation. No proprietary assets or internal data appear here.

← All work

Case study 03 · The Walt Disney Company

The form that sent you back to the start

New hires were taking a long time to become operational, and the process was inconsistent from person to person. The delay wasn't caused by the number of steps. It was caused by one of them quietly failing and returning people to the beginning.

Role: UX research and design lead — contextual inquiry, synthesis, form consolidation
Partner: Talent Acquisition; initial cohort at corporate headquarters
Participants: 8 new hires sampled across three stages of onboarding
Change: À la carte equipment request replaced with a single inclusive request; downstream forms simplified and consolidated

01
The path

Four steps to a working new hire

Before a new cast member could do the job they were hired for, four things had to happen: request a computer, receive the computer, set up single sign-on, and log into the portal. None of them is unnecessary. All four have to occur.

The complaint from Talent Acquisition was that the sequence took a long time and — more tellingly — that it was inconsistent. Two people hired the same week could have completely different experiences. Inconsistency of that kind usually means the process has a failure path that some people fall into and others don't.

02
The research

Catching people mid-process, not after

We were given a list of new hires at different points in onboarding, and I sampled deliberately across the arc rather than only talking to people who had finished: three who were just starting, three who were one to two months in, and two who had just completed.

That sampling is the reason the research worked. People who have finished onboarding remember it as smooth — the friction compresses in memory the moment it's over. People in the middle of it are still angry about the specific thing that is blocking them today. Running contextual inquiries at three stages meant seeing the process as it was experienced, not as it was recalled.

Diagram scrolls sideways →

Fig. 1 — Sampling design. Eight contextual inquiries placed at three points along the onboarding arc rather than clustered at the end.

03
The finding

The equipment request was à la carte

The computer request form let you order items individually — pick what you need, submit. Reasonable on its face, and the source of the whole problem.

If you missed an item, you didn't find out until the equipment arrived. Then you ordered again, and waited again.

A new hire doesn't know what a new hire needs. That is definitionally true, and the form assumed the opposite — it asked people to specify a complete kit for a job they hadn't started yet, using a vocabulary they hadn't learned. Missed items were not user error. They were the predictable result of asking the wrong person to be the expert.

That's what made the process inconsistent. Someone who happened to order correctly moved through in one pass. Someone who missed a cable, a dock, or an adapter went around again — and the loop was invisible in the process documentation, because on paper there were still only four steps.

Diagram scrolls sideways →

Fig. 2 — The loop that made onboarding inconsistent. Removing the reorder path didn't remove a step; it removed the chance of repeating one.

04
The change

Make the complete order the default one

We replaced à la carte ordering with a single inclusive request built around what the role actually needs. The new hire is no longer asked to assemble a kit from a catalog; they are asked to confirm the one their role requires.

The rest of the forms in the sequence were simplified and consolidated on the same evidence — the contextual inquiries showed which fields caused hesitation, which ones people guessed at, and which ones were being asked twice across different systems.

The underlying move is one I keep coming back to. When a process is inconsistent, look for the step where a user can fail without knowing it. The fix usually isn't a better interface for that step — it's removing the possibility of failing it at all.

05
Honestly

What I can and can't claim

The reorder loop was real, the sampling was deliberate, and the consolidated request form shipped. What I don't have to hand is a clean measurement of the time saved — this work predates my current record-keeping, and I would rather say so than publish a figure I can't reconstruct on request.

What the change did, structurally, is take a process whose duration depended on whether a new hire happened to guess right and make it the same for everyone. Consistency was the complaint. Consistency was the fix.

06
Carry forward

What this taught me

Sample the middle, not just the end. People who completed a process remember it as fine. The ones still in it can tell you exactly what's wrong.
Inconsistency is a symptom of a hidden failure path. When the same process takes wildly different amounts of time, something is quietly sending some people back to the beginning.
Don't ask novices to be experts. A form that requires knowledge the user hasn't acquired yet will produce errors, and those errors are the form's fault.
Removing a loop beats optimizing a step. The four steps stayed. What changed was that the first one stopped failing.

← All work