EXPERIENCE OPERATIONS · SELF-INITIATED · WORKING PROTOTYPE

The team did not need another dashboard.It needed a place to remember the work.

Experiments lived in spreadsheets, links, and people’s memory across hundreds of programs. I mapped the records and relationships the team was already tracking, then built a working product for finding what was live, who owned it, and what we had learned.

01 · ORIENT TO THE PORTFOLIO

Experience Operations dashboard showing recently launched work and tests

PROTOTYPE SCOPE

DozensEXPERIENCES IN CONTINUOUS MOTION
TensCONCURRENT TESTS AND ITERATIONS
1 modelPORTFOLIO → PROGRAM → EXPERIENCE → TEST
WorkingAI-ASSISTED PRODUCT PROTOTYPE

THE PROBLEM WAS NOT REPORTING

The team had data.What it lacked was operational memory.

One program at one school might have several live variants, a control, a few tests, and recent launches. Across the full portfolio, simple questions became surprisingly hard: What is live? Who owns it? Which version is current? What did we learn last time?

The process depended on people remembering naming conventions, spreadsheets, links, and conversations. We did not need another dashboard widget. We needed a shared place the work could live.

The product needed to remember the portfolio so the team did not have to.
Original working portfolio dashboard

BEFORE

Reconstruct the work through spreadsheets, links, conversations, and memory.

IN THE PROTOTYPE

Search once and see owner, state, program, tests, and learning together.

MODEL THE PORTFOLIO BEFORE STYLING THE SCREENS

The information architecture becamethe product strategy.

I mapped the relationships the team was already managing informally, then built the navigation and records around them. The same structure had to answer a portfolio question and explain the history of one specific experience.

01

Line of business

The operating context and shared template family.

02

School + program

The institution and offering being represented.

03

Experience

The persistent product record across versions and channels.

04

Variant + test

The live implementation, control, hypothesis, state, and learning.

Experience Operations workflow and taxonomy maps

FIND THE THING SOMEONE ACTUALLY REMEMBERS

Search, filters, and quick pathsturned fragments into a browsable portfolio.

People rarely remember an internal ID. They remember the school, program type, owner, a recent launch, or what the page looked like. Search and filters needed to work from those imperfect clues without breaking the underlying taxonomy.

Portfolio overview with real experience previews
PORTFOLIO OVERVIEW · Recently launched work, active tests, schools, rankings, device states, and previews.
Line-of-business dashboard with scoped filters
SCOPED NAVIGATION · Program views reduce the portfolio without losing the shared vocabulary.

ONE EXPERIENCE BECOMES A SHARED SOURCE OF TRUTH

The record connects the work,the hypothesis, the state, and the evidence.

A record brings the live experience, ownership, channels, devices, hypothesis, goals, performance, project brief, and test-versus-control view into one place. It is where someone can understand the work and decide what to do next.

Single experience record connecting content, ownership, performance, and comparison
CONTEXT

School, program, channel, device, publication date, lifecycle state, and ownership.

INTENT

Hypothesis, goals, linked brief, and the reason the variant exists.

EVIDENCE

Sessions, leads, conversion signal, statistical significance, and update recency.

COMPARISON

Test and control shown together so a decision does not depend on memory or another tab.

BUILD THE PRODUCT, NOT JUST THE CONCEPT

A working prototype made the operating modeltestable before a roadmap existed.

AI helped me build and revise the prototype faster. I still made the product decisions: what the records meant, how they connected, which workflows mattered, and what the interface needed to make clear.

The working prototype exposed problems the static screens missed: unclear states, broken links between records, awkward transitions, and layouts that failed with real content. Coding it changed the design.

AI increased the speed of making. It did not replace the judgment required to decide what should exist.
01

Product definition

Converted an operational pain into a coherent product model.

02

Workflow design

Designed the portfolio, records, filters, comparisons, states, and actions.

03

AI-assisted build

Implemented a functioning prototype to test density and behavior.

04

Source-faithful previews

Real imagery and realistic content exposed wireframe issues.

THE OUTCOME

An internal tracking problem becamea product strategy for experimentation operations.

The value is not another place to look at metrics. It is a shared system for knowing what exists, how it relates, what is live, why it was created, what changed, and where the team should go next.

Self-initiatedOPPORTUNITY + PRODUCT DEFINITION
End-to-endIA, WORKFLOWS, VISUAL DESIGN, BUILD
OperationalDESIGNED FOR REAL PORTFOLIO DENSITY
WorkingFUNCTIONAL PROTOTYPE