app-experience-mappinglisted

# 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 1. Collect black-box inputs: app name and platform, primary user and goal, channels, entry point, expected outcome. 2. Produce the journey map (stage, user action, touchpoint, channel, feeling, pain points, opportunity). 3. Produce the experience map across all touchpoints and channels; mark seam candidates. 4. Produce the service blueprint: frontstage, backstage, supporting systems, handoffs. 5. Inventory seams: two systems, failure modes, user-visible signal of success or failure. 6. Turn the map into research questions. 7. 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 (w