App Experience Mapping
Core Principle
Treat the app as a black box: map product intent and observed behavior, never implementation details; mark every cell hypothesis (H) or observed (O), unmarked cells are hypotheses, not facts.
When to Use
Use when planning an app build, change, or launch and the team needs to see the whole experience before writing code: who the user is, what they are trying to do, which touchpoints and channels they cross, and where the app hands work to another system.
When NOT to use
- Executing the review itself -> black-box-experience-review
- Screen-level UI review -> ux-review
- Visual styling or design tokens -> design-taste-frontend / design-system-audit
Workflow
- Collect black-box inputs: app name and platform, primary user and goal, channels, entry point, expected outcome.
- Produce the journey map (stage, user action, touchpoint, channel, feeling, pain points, opportunity).
- Produce the experience map across all touchpoints and channels; mark seam candidates.
- Produce the service blueprint: frontstage, backstage, supporting systems, handoffs.
- Inventory seams: two systems, failure modes, user-visible signal of success or failure.
- Turn the map into research questions.
- Deliver outputs labeled hypothesis/observed/verified, each hypothesis with a measurable outcome.
Black-box input contract
Treat the app as a black box. Inputs: the app name and platform, the primary user and their goal, the channels used (web, mobile, desktop, CLI, API, notifications, email), the entry point, and the expected outcome. Do not read implementation details to build the map; read product intent and observed behavior.
Journey map schema
For each primary journey produce a table: stage, user action, touchpoint, channel, what the user feels, pain points, and opportunity. Stages run from entry through first success to repeat use. Mark every cell as hypothesis (H) or observed (O). Unmarked cells default to hypothesis and must not be reported as fact.
Experience map schema
Map the full ecosystem: every touchpoint and channel a user can reach, how they connect, and where the same intent splits across channels (web start, email resume, mobile finish). Highlight channel handoff points as seam candidates.
Service blueprint schema
For the service behind the app: frontstage actions the user sees, backstage actions the app performs, and supporting systems (auth, payments, storage, queues, email, notifications). At each step record the handoff: which system owns the next step, what can fail, and what the user sees while waiting.
Seam inventory
Inventory the boundary crossings the map exposes: authentication and permissions, payments and billing, external OAuth, file pickers and uploads, deep links and redirects, email and push notifications, background jobs, support and feedback, account deletion and export, cross-device sync, offline storage, and third-party embeds. For each seam name the two systems, the failure modes, and the user-visible signal of success or failure.
Research questions
Turn the map into questions: what does the user need at each stage, what
breaks the flow, what would make them abandon, and what recovery they expect
after each failure. Use the research pack's evidence-router methods (or describe the interview/survey/ticket-analysis approach directly)
for interviews, surveys, and ticket analysis.
Outputs
Deliver the journey map, experience map, blueprint, seam inventory, and a prioritized list of hypotheses. Label every output with its evidence status: hypothesis, observed, or verified. Each hypothesis needs a measurable outcome so the later review can test it.
Red Flags
- Unmarked cells reported as fact (default is hypothesis).
- Map built from implementation details instead of observed behavior.
- Hypotheses without a measurable outcome.
- Seam entries missing failure modes or the user-visible signal.
Verification
Every cell marked H or O; every output labeled hypothesis, observed, or verified; deliverables present: journey map, experience map, service blueprint, seam inventory, prioritized hypotheses.
References
N/A, no reference files; this skill is self-contained.