user-journey-mapping

Use when running /ux:user-journey, after a persona exists — walks that persona through a scenario end to end. Philosophy adapted from the toolkit's UX extension (Business Goal -> Persona -> Journey -> Wireframe -> Prototype).

跳到安装

仓库: KiemVM/AI-SDLC
最近来源活动: 2026年7月23日 10:04
检测到的 SKILL.md 语言: 英语
星标: 5
分支: 0

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/KiemVM/AI-SDLC --skill user-journey-mapping

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

decision-capture

Use when running /decide, or whenever a product/technical decision changes something already written (a spec, plan, architecture doc) mid-work — captures it as an ADR and finds what needs to be updated downstream. Philosophy adapted from GitHub Spec-Kit's ADR discipline and BMAD-METHOD's documentation-first governance.

2026-07-29

implementation-planning

Use when running /spec:plan, after a Specification.md exists and before task breakdown — turns approved requirements into a technical approach, file structure, and testing strategy. Philosophy adapted from GitHub Spec-Kit's plan phase and BMAD-METHOD's architecture discipline.

2026-07-24

reviewing-code

Use when running /engineering:review, or whenever asked to review a diff or PR for bugs and spec/constitution adherence. If the host project already has Anthropic's official code-review plugin configured, prefer that instead. Philosophy adapted from Superpowers' code-review discipline.

2026-07-24

查看这个仓库的全部 Skills

User Journey Mapping

A journey is the bridge between a persona (who) and wireframes (what screens). It exists to answer: given this persona's actual goals and pain points, what does success look like step-by-step, and where could it fail?

Process

Start from the persona's goal, not a feature. The journey should read as "the persona wants X, so they do..." not "the app has a flow where..."

Walk it step by step, naming the touchpoint (screen, notification, external channel) at each step — vague steps like "user interacts with the app" produce vague wireframes later.

Mark the emotional arc. Where does friction peak? Where's the moment of relief or accomplishment? This tells /ux:wireframe where to invest the most design care.

Identify drop-off risk per step. A step with high drop-off risk is a design priority, not an afterthought.

Define success concretely, bounded by time or step count where possible, and tied back to the persona's original goal.

List candidate screens as a bridge to /ux:wireframe — names only, no layout.

Self-review checklist

Every step ties back to the persona's stated goal.

Each step names a concrete touchpoint, not a vague interaction.

At least one drop-off risk is identified, or the journey is trivial enough that none exists (state that explicitly).

Success criteria are concrete and traceable to the persona's goal.

Red flags

Red flag

Why it matters

Steps describe UI ("clicks the blue button") instead of intent

Premature UI commitment before wireframing has happened

No step is marked as risky/frustrating

Either the journey is genuinely trivial, or friction points were missed

The journey doesn't match anything in the persona's goals/pain points

Likely designed from assumption rather than the actual persona document