improve-app
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseImprove an App
优化应用体验
The app already ships and works — users, screens, a real flow — but the experience feels rough where it
should feel effortless. Across nine phases this journey fixes what users feel, in evidence order: re-anchor
on the job, remove friction, polish the look and the moments, sharpen the words, persuade honestly, and end
with a review brutal enough to cut. It is interactive (the agent asks before deciding) and resumable (state
lives in ). Code-level causes route out to the code journeys — this pass fixes the product experience.
docs/这款应用已上线且能正常运行——拥有用户、界面和完整流程,但本应流畅的体验却显得粗糙。本旅程将分九个阶段,依据证据顺序解决用户感知到的问题:重新锚定应用的核心价值、消除体验摩擦、打磨视觉与交互细节、优化文案表述、诚信说服用户,最后进行严苛的复盘评审。整个过程是交互式的(Agent会在决策前询问用户)且可续期的(状态存储在文件夹中)。代码层面的问题会引导至代码优化旅程——本次流程专注于修复产品体验。
docs/Core Principle
核心原则
Fix what users feel, in evidence order: re-anchor on the job the app is hired for, remove friction before
polish, sharpen the words, persuade honestly, and end with a review brutal enough to cut. A prettier
screen on a confusing flow loses users at the same rate — the order of the phases is the whole game.
This skill sequences the phases, asks the decision questions, and records what you decide. The nine
constituent skills carry the method — invoke them rather than improvising their frameworks.
依据证据顺序解决用户感知到的问题:先重新锚定应用被用户选择的核心价值,先消除摩擦再打磨细节,优化文案表述,诚信说服用户,最后进行足够严苛的复盘评审。 一个流程混乱但视觉精美的界面,用户流失率并不会降低——阶段顺序是关键。
本技能会按顺序编排各阶段,提出决策问题,并记录你的决策。九个组成技能承载了具体方法——请调用这些技能而非自行摸索其框架。
Journey Map
旅程地图
| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | jobs-to-be-done | What job is the app hired for, and where does it underdeliver? | Extends docs/CUSTOMER.md — GATE |
| 2 | ux-heuristics | Where does the interface make users stop and think? | Extends docs/DESIGN.md, docs/EXPERIMENTS.md |
| 3 | design-everyday-things | Where do users act wrong because the design misled them? | Extends docs/DESIGN.md, docs/EXPERIMENTS.md |
| 4 | refactoring-ui | Does the app look as clear as it works? | Extends docs/DESIGN.md, docs/EXPERIMENTS.md |
| 5 | microinteractions | Does every action feel alive, or dead? | Extends docs/DESIGN.md, docs/EXPERIMENTS.md |
| 6 | made-to-stick | Do the in-app words land, or read as jargon? | Extends docs/POSITIONING.md, docs/EXPERIMENTS.md |
| 7 | influence-psychology | Do the paywall and upgrade moments persuade honestly? | Extends docs/POSITIONING.md, docs/EXPERIMENTS.md |
| 8 | high-perf-browser | Does the app feel fast where users touch it? | Extends docs/DESIGN.md, docs/EXPERIMENTS.md |
| 9 | steve-jobs-design-review | Is the whole experience insanely great, or just better? | Extends docs/PRODUCT.md, docs/DESIGN.md, docs/EXPERIMENTS.md |
| 阶段 | 技能 | 要解答的问题 | 产出物 |
|---|---|---|---|
| 1 | jobs-to-be-done | 用户选择这款应用是为了完成什么任务,应用在哪些方面未达预期? | 扩展docs/CUSTOMER.md —— 关键节点 |
| 2 | ux-heuristics | 界面在哪些地方让用户停滞思考? | 扩展docs/DESIGN.md、docs/EXPERIMENTS.md |
| 3 | design-everyday-things | 用户在哪些地方因设计误导而操作失误? | 扩展docs/DESIGN.md、docs/EXPERIMENTS.md |
| 4 | refactoring-ui | 应用的视觉呈现是否与其功能一样清晰? | 扩展docs/DESIGN.md、docs/EXPERIMENTS.md |
| 5 | microinteractions | 每个操作是否有鲜活的反馈,还是毫无生气? | 扩展docs/DESIGN.md、docs/EXPERIMENTS.md |
| 6 | made-to-stick | 应用内文案是否清晰易懂,还是充斥行话? | 扩展docs/POSITIONING.md、docs/EXPERIMENTS.md |
| 7 | influence-psychology | 付费墙和升级提示是否能诚信地说服用户? | 扩展docs/POSITIONING.md、docs/EXPERIMENTS.md |
| 8 | high-perf-browser | 用户频繁接触的应用部分是否感觉流畅快速? | 扩展docs/DESIGN.md、docs/EXPERIMENTS.md |
| 9 | steve-jobs-design-review | 整体体验是否极致出色,还是仅仅有所改善? | 扩展docs/PRODUCT.md、docs/DESIGN.md、docs/EXPERIMENTS.md |
Operating Rules
操作规则
- Resume first. Before anything else, read and every artifact in the Journey Map. If the tracker exists, summarize the journey state in 3-5 lines and ask which phase to enter. Done when the user has confirmed an entry point. A journey with a tracker is resumed, never restarted.
docs/IMPROVE-APP-PLAN.md - Intake on first run only. No tracker: run the Intake below, then create with every phase statused
docs/IMPROVE-APP-PLAN.md. Done when the tracker exists and the user has confirmed the phase plan.pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason - Phase entry. Announce: what the phase does, the decision it forces, the artifact it produces, rough effort. Offer proceed / skip / defer — phases marked GATE may be deferred, never skipped. Mark the phase on proceed. Done when the user chose.
in-progress - Skill invocation and fallback. Load the phase's skill and use it: each phase's Invoke line names the skill by slug — use that skill to run the phase. If it is not available, offer: . If the user declines, run the phase from its Brief — the minimum viable method. State which mode you are in.
npx skills add wondelai/skills/<slug> --global - In-phase decisions. Ask every question under "Decide with the user" — with concrete options and your recommendation. Record the choice in the tracker's Key Decisions. A decision made silently is a defect.
- Phase exit. Present the draft artifact content for sign-off before writing. On approval: write or extend the docs/ files, update the tracker (status, Key Decisions, Next Actions). Done when the files are written and the phase row shows .
done - Artifact discipline. Read before writing; create a file only if missing, otherwise extend — add or update your sections, preserve everyone else's. Files are UPPERCASE in . Every recommendation lands as a checkbox or a table row with owner and priority. See references/artifact-templates.md when creating a docs/ file for the first time — create it from the full skeleton (all section headings), then fill the sections your phase names.
docs/ - Evidence before redesign; persuasion stays honest. No UI or copy change ships without an audit or evidence row from Phases 1-3 behind it — a change with no finding behind it goes back to the audits. Every shipped change lands in docs/EXPERIMENTS.md with a pre-committed metric. Every in-app scarcity cue, social-proof claim, and upgrade promise must be true — replace any tactic that needs invented evidence with one that uses evidence you have.
- 优先续期旅程:首先读取和旅程地图中的所有产出物。若存在追踪文件,用3-5行总结当前旅程状态,并询问进入哪个阶段。待用户确认进入点后完成此步骤。已有追踪文件的旅程需续期,而非重启。
docs/IMPROVE-APP-PLAN.md - 仅首次运行时收集信息:若没有追踪文件,先完成下方的信息收集,然后创建,将每个阶段标记为
docs/IMPROVE-APP-PLAN.md。待追踪文件创建完成且用户确认阶段计划后完成此步骤。pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason - 进入阶段:告知用户:该阶段的作用、需要做出的决策、产出的文档、大致工作量。提供继续/跳过/推迟选项——标记为关键节点的阶段可推迟,但不可跳过。若用户选择继续,将阶段标记为。待用户做出选择后完成此步骤。
in-progress - 调用技能与备选方案:加载该阶段的技能并使用:每个阶段的调用行都以短名称指定技能——请使用该技能完成阶段任务。若技能不可用,提供选项:。若用户拒绝,使用该技能的简要说明完成阶段任务——即最小可行方法。需说明当前使用的模式。
npx skills add wondelai/skills/<slug> --global - 阶段内决策:询问“与用户共同决策”下的所有问题——提供具体选项及你的建议。将选择记录在追踪文件的“关键决策”部分。未经询问擅自做出的决策视为缺陷。
- 退出阶段:在写入前展示产出物草稿内容供用户确认。获得批准后:写入或扩展docs/文件夹中的文件,更新追踪文件(状态、关键决策、下一步行动)。待文件写入完成且阶段状态显示为后完成此步骤。
done - 产出物规范:先读取再写入;仅当文件不存在时创建,否则扩展内容——添加或更新你的章节,保留其他人的内容。docs/文件夹中的文件均为大写。每条建议需以复选框或包含负责人与优先级的表格行形式呈现。首次创建docs/文件时,请参考references/artifact-templates.md——从完整框架(所有章节标题)创建文件,然后填充该阶段指定的章节。
- 基于证据进行重设计;保持说服诚信:所有UI或文案变更需有阶段1-3的审计或发现作为依据——无依据的变更需返回重新审计。所有上线的变更需记录在docs/EXPERIMENTS.md中,并预先设定衡量指标。应用内的稀缺提示、社交证明声明和升级承诺必须真实——替换所有需要虚构证据的策略,改用现有证据支持的策略。
Intake
信息收集
Ask these before creating the tracker:
- What is the app, and what job did users hire it to do — in their words? (Anchors Phase 1; gates every later phase.)
- Where does it feel roughest — confusing screens, dead interactions, amateur UI, weak copy, pushy upgrade prompts, or sluggishness? (Sets the entry phase and front-loads a fix phase.)
- What evidence do you have — recordings, support tickets, reviews, funnel drop-off, usage analytics? ("None" routes to the optional continuous-discovery phase.)
- What platform(s) does the app run on — web, native iOS, both? (Gates Phase 8 and optional ios-hig-design; no browser surface with smooth native perf skips Phase 8.)
- Which in-app surfaces sell or upsell — paywall, upgrade prompt, trial nudge, badges — and are the scarcity and social-proof claims true today? (Scopes Phase 7 and the honesty guardrail.)
- Which flow leaks the most users or draws the most tickets? (Targets Phases 2-3, 5, and 8.)
- Do you already have positioning, design, or customer docs (POSITIONING.md, DESIGN.md, CUSTOMER.md)? (Phases 1, 4, 6, 7 build on them.)
Phase-skip heuristics: skip Phase 8 with no browser surface and smooth native speed; skip Phase 7 with no
in-app upsell surfaces; skip Phase 4 when the UI already reads cleanly in grayscale on a consistent token
scale; skip Phase 6 when in-app copy is already concrete and jargon-free. Never skip Phase 1 — it aims every
other phase (defer it, don't skip it). Then create from the template and confirm
the plan. Done when exists with every phase statused and the user has confirmed the plan.
docs/IMPROVE-APP-PLAN.mddocs/IMPROVE-APP-PLAN.md创建追踪文件前需询问以下问题:
- 这款应用是什么,用户选择它是为了完成什么任务——用用户的话来说?(锚定阶段1;为后续所有阶段奠定基础。)
- 体验最粗糙的地方在哪里——混乱的界面、无反馈的交互、业余的UI、薄弱的文案、强行的升级提示,还是卡顿?(设定进入阶段并优先安排修复阶段。)
- 你有哪些证据——用户录制视频、支持工单、评论、漏斗流失数据、使用分析?(“无证据”将引导至可选的持续发现阶段。)
- 应用运行在哪些平台上——网页、原生iOS,还是两者皆有?(为阶段8和可选的ios-hig-design奠定基础;若无浏览器界面且原生性能流畅,可跳过阶段8。)
- 应用内哪些界面用于销售或升级——付费墙、升级提示、试用提醒、徽章——且当前的稀缺性和社交证明声明是否真实?(限定阶段7的范围及诚信准则。)
- 哪个流程的用户流失最多或收到的工单最多?(针对阶段2-3、5和8。)
- 你是否已有定位、设计或用户文档(POSITIONING.md、DESIGN.md、CUSTOMER.md)?(阶段1、4、6、7将基于这些文档展开。)
阶段跳过规则:若无浏览器界面且原生性能流畅,跳过阶段8;若无应用内升级界面,跳过阶段7;若UI在灰度模式下基于一致的令牌尺度已清晰可读,跳过阶段4;若应用内文案已具体且无行话,跳过阶段6。切勿跳过阶段1——它为其他所有阶段指明方向(可推迟,但不可跳过)。然后根据模板创建并确认计划。待创建完成,所有阶段已标记状态且用户确认计划后完成此步骤。
docs/IMPROVE-APP-PLAN.mddocs/IMPROVE-APP-PLAN.mdPhases
各阶段详情
Phase 1 — Re-anchor on the job the app is hired for (jobs-to-be-done) — GATE
阶段1——重新锚定应用的核心价值(jobs-to-be-done)——关键节点
Purpose: Name the job users hire the app for and where it underdelivers, before any screen changes; Phases 2-9 may only fix what an audit or finding in Phases 1-3 flags.
Brief (fallback): Customers hire a product to make progress in a circumstance. State the job as "When [situation], I want to [motivation], so I can [outcome]" — never naming the app; every job has three dimensions (functional, emotional, social), and omitting one loses why users stay. Track first use vs repeated use (Big Hire vs Little Hire), and map alternatives including non-consumption and improvised workarounds.
Invoke: Use the skill with the app, its usage data, and the roughest flow from intake. Ask for the job statement, the three dimensions with where the app underdelivers on each, and the alternatives users switch to.
jobs-to-be-doneDecide with the user: (1) Confirm the job statement reads without the product name. (2) Which underdelivered dimension is worst — functional, emotional, or social? (3) Is the leak a Big Hire (onboarding) or Little Hire (daily use) failure?
Artifact: Extend docs/CUSTOMER.md , (functional/emotional/social, each with its underdelivery note), and (alternative | why hired | weakness, incl. non-consumption). Update the tracker.
## Job Statement## Job Dimensions## Competing AlternativesDone when: the job is stated without the product name, all three dimensions carry an underdelivery note, alternatives are logged, and Phase 1 shows done — only then are Phases 2-9 unlocked.
目标:在修改任何界面之前,明确用户选择应用的核心任务以及应用未达预期的地方;阶段2-9仅能修复阶段1-3审计或发现中标记的问题。
简要说明(备选方案):用户选择产品是为了在特定场景下取得进展。将核心任务表述为“当[场景]时,我想要[动机],这样我就能[结果]”——切勿提及应用名称;每个任务都包含三个维度(功能、情感、社交),遗漏任一维度都会失去用户留存的原因。区分首次使用与重复使用(核心任务与次要任务),并绘制替代方案图谱,包括无产品可用的情况和用户自行摸索的解决方法。
调用:结合应用、使用数据和信息收集阶段确定的最粗糙流程,使用技能。询问任务表述、三个维度中应用未达预期的方面,以及用户转向的替代方案。
jobs-to-be-done与用户共同决策:(1) 确认任务表述中未提及产品名称。(2) 哪个维度的未达预期情况最严重——功能、情感还是社交?(3) 用户流失是核心任务(新用户引导)还是次要任务(日常使用)的失败导致的?
产出物:扩展docs/CUSTOMER.md中的、(功能/情感/社交,每个维度包含未达预期说明)和(替代方案 | 被选择的原因 | 劣势,包括无产品可用的情况)。更新追踪文件。
## Job Statement## Job Dimensions## Competing Alternatives完成标志:任务表述中未提及产品名称,三个维度均包含未达预期说明,替代方案已记录,且阶段1显示为完成——此时阶段2-9才会解锁。
Phase 2 — Remove the friction that makes users think (ux-heuristics)
阶段2——消除让用户思考的体验摩擦(ux-heuristics)
Purpose: Cut cognitive load on the flows that leak users — find where the interface makes people stop and puzzle.
Brief (fallback): "Don't Make Me Think" — users scan, satisfice, and muddle through. Run a heuristic evaluation against Nielsen's 10 heuristics; rate each issue 0-4 and order by severity × how often users hit it, so catastrophes outrank cosmetics. Apply the Trunk Test to key screens (what app, what screen, my options, where am I, where's search?), cut half the words then half again, and fix forms with inline validation and error messages that say what, why, and how.
Invoke: Use the skill on the highest-leak flow with the Phase 1 job and dimensions. Ask for a severity-rated evaluation, a Trunk Test result per key screen, and rewritten label, form, and error copy.
ux-heuristicsDecide with the user: Which severity-4 and -3 issues get fixed now versus backlogged? Confirm fixes run by severity × frequency, not by ease.
Artifact: Extend docs/DESIGN.md (issue | heuristic | severity 0-4 | fix | status); append each fix to docs/EXPERIMENTS.md with ICE. Update the tracker.
## UX Audit Findings## Experiment BacklogDone when: every issue carries a 0-4 severity and a fix, the Trunk Test passes on each key screen or is logged, and severity-4 issues have an owner.
目标:减少用户流失流程中的认知负荷——找出界面让用户停滞困惑的地方。
简要说明(备选方案):“别让我思考”——用户会快速浏览、勉强接受并摸索前行。依据尼尔森的10条启发式原则进行启发式评估;为每个问题评分0-4,并按严重程度×用户接触频率排序,确保严重问题优先于 cosmetic问题。对关键界面进行主干测试(这是什么应用、当前在哪个界面、我的选项有哪些、我在哪里、搜索功能在哪里?),将文案减半后再减半,使用内联验证和包含问题、原因及解决方案的错误提示修复表单。
调用:结合阶段1的任务和维度,针对用户流失最严重的流程使用技能。询问严重程度评级的评估结果、每个关键界面的主干测试结果,以及重写后的标签、表单和错误文案。
ux-heuristics与用户共同决策:哪些严重程度为4和3的问题需要立即修复,哪些需要列入待办?确认修复按严重程度×频率排序,而非按难易程度。
产出物:扩展docs/DESIGN.md中的(问题 | 启发式原则 | 严重程度0-4 | 修复方案 | 状态);将每个修复方案添加到docs/EXPERIMENTS.md中的并标注ICE评分。更新追踪文件。
## UX Audit Findings## Experiment Backlog完成标志:每个问题都有0-4的严重程度评分和修复方案,每个关键界面的主干测试已通过或记录在案,严重程度为4的问题已指定负责人。
Phase 3 — Design out the errors (design-everyday-things)
阶段3——从设计层面消除错误(design-everyday-things)
Purpose: Make the wrong action hard and every outcome legible — where users act wrong, the design misled them, not the user.
Brief (fallback): There is no human error, only bad design. Bridge two gulfs: Execution ("how do I do this?") with clear signifiers and constraints (date picker over free text, Submit disabled until valid); Evaluation ("what happened?") with feedback under 0.1s and visible system state. Distinguish slips (right intent, wrong action) from mistakes (wrong intent); prefer undo over are-you-sure dialogs, and write error messages that say what went wrong and how to fix it, never blame.
Invoke: Use the skill on the core flows (onboarding, the primary action, destructive actions). Ask for weak signifiers, where a constraint makes an error impossible, feedback gaps, and message rewrites.
design-everyday-thingsDecide with the user: Where should a constraint replace an error message, and where should undo replace a confirmation dialog?
Artifact: Extend docs/DESIGN.md (heuristic = Norman gulf; issue | severity 0-4 | fix | status); append fixes to docs/EXPERIMENTS.md . Update the tracker.
## UX Audit Findings## Experiment BacklogDone when: each core flow has signifier/constraint/feedback fixes logged, error messages meet the what/why/how checklist, and destructive actions offer undo.
目标:让错误操作难以发生,让所有结果清晰可见——用户操作失误的地方,是设计误导了他们,而非用户的问题。
简要说明(备选方案):不存在人为错误,只有糟糕的设计。弥合两个鸿沟:执行鸿沟(“我该怎么做?”)——通过清晰的标识和约束(使用日期选择器而非自由文本输入,表单验证通过前禁用提交按钮);评估鸿沟(“发生了什么?”)——通过0.1秒内的反馈和可见的系统状态。区分失误(意图正确,操作错误)与错误(意图错误);优先使用撤销功能而非“你确定吗?”对话框,错误提示需说明问题、原因及解决方案,切勿指责用户。
调用:针对核心流程(新用户引导、主要操作、破坏性操作)使用技能。询问薄弱的标识、可通过约束避免错误的地方、反馈缺口,以及重写的提示文案。
design-everyday-things与用户共同决策:哪些地方应使用约束替代错误提示,哪些地方应使用撤销功能替代确认对话框?
产出物:扩展docs/DESIGN.md中的(启发式原则 = 诺曼鸿沟;问题 | 严重程度0-4 | 修复方案 | 状态);将修复方案添加到docs/EXPERIMENTS.md中的。更新追踪文件。
## UX Audit Findings## Experiment Backlog完成标志:每个核心流程都记录了标识/约束/反馈修复方案,错误提示符合“问题/原因/解决方案”要求,破坏性操作提供撤销功能。
Phase 4 — Make it look as clear as it works (refactoring-ui)
阶段4——让视觉呈现与功能一样清晰(refactoring-ui)
Purpose: Give the screens a professional visual hierarchy so nothing amateur undercuts the flows you just fixed.
Brief (fallback): Great UI is systems, not talent. Design in grayscale first: establish hierarchy with size, weight, and contrast before any color — combine levers, don't multiply (all three only for the one hero element). Enforce a spacing scale (4/8/16/24/32/48/64) where gaps between groups exceed gaps within them; constrain text to 45-75 chars and forms to 300-500px. Add color last: 5-9 shades per hue, grays tinted, not pure black.
Invoke: Use the skill on the key screens with the Phase 2-3 findings and current design tokens. Ask for a grayscale hierarchy pass, spacing-scale corrections, a systematic palette, and the exact token/CSS changes.
refactoring-uiDecide with the user: Fix within the current design system or introduce new tokens? Confirm color work waits until the grayscale layout reads.
Artifact: Extend docs/DESIGN.md (spacing scale · palette shades · shadows) and (component | decision | status); append fixes to docs/EXPERIMENTS.md . Update the tracker.
## Tokens## Components## Experiment BacklogDone when: the key screens read in grayscale, the spacing scale is applied, one primary action dominates each screen, and the token decisions are recorded.
目标:为界面建立专业的视觉层次,避免业余设计削弱你刚修复的流程体验。
简要说明(备选方案):优秀的UI是系统设计,而非天赋。先以灰度模式设计:在添加颜色前,通过尺寸、权重和对比度建立层次——组合使用这些手段,而非单独叠加(仅核心元素同时使用三种手段)。遵循间距尺度(4/8/16/24/32/48/64),组间间距需大于组内间距;文本长度限制为45-75字符,表单宽度限制为300-500px。最后添加颜色:每个色调使用5-9种渐变,灰色需带色调,而非纯黑。
调用:结合阶段2-3的发现和当前设计令牌,针对关键界面使用技能。询问灰度层次优化结果、间距尺度修正、系统调色板,以及具体的令牌/CSS变更。
refactoring-ui与用户共同决策:在现有设计系统内修复,还是引入新的令牌?确认颜色优化需等待灰度布局清晰后进行。
产出物:扩展docs/DESIGN.md中的(间距尺度 · 调色板渐变 · 阴影)和(组件 | 决策 | 状态);将修复方案添加到docs/EXPERIMENTS.md中的。更新追踪文件。
## Tokens## Components## Experiment Backlog完成标志:关键界面在灰度模式下清晰可读,间距尺度已应用,每个界面有一个主导操作,令牌决策已记录。
Phase 5 — Make every action feel alive (microinteractions)
阶段5——让每个操作都有鲜活反馈(microinteractions)
Purpose: Give the moments users touch every day the feedback that separates a product they tolerate from one they love.
Brief (fallback): Every microinteraction has four parts — Trigger, Rules, Feedback, Loops & Modes. The common failure is missing or late feedback: direct manipulation needs a response under 100ms, usually by animating the element the user touched (a button depresses to "Saving…"), not a separate toast. Map every state — empty, loading, partial, full, error, disabled — and use the least feedback that communicates, scaled to the event's significance.
Invoke: Use the skill on the most-used interactions (save, submit, toggle, delete, load). Ask for a Trigger/Rules/Feedback/Loops audit, the exact feedback each needs, a full state map, and one signature moment.
microinteractionsDecide with the user: (1) Which interactions to polish first. (2) The one signature moment worth extra craft — apply the removal test: would the product feel materially worse without it?
Artifact: Extend docs/DESIGN.md (interaction | trigger/rules/feedback/loops | fix | status); append fixes to docs/EXPERIMENTS.md . Update the tracker.
## Microinteraction Inventory## Experiment BacklogDone when: each audited interaction has its four parts and required feedback logged, every state is mapped, the signature moment passes the removal test, and fixes are rows with status.
目标:为用户日常接触的交互时刻添加反馈,将用户容忍的产品转变为用户喜爱的产品。
简要说明(备选方案):每个微交互都包含四个部分——触发、规则、反馈、循环与模式。常见问题是缺失或延迟的反馈:直接操作需在100ms内响应,通常通过动画用户触摸的元素(按钮变为“保存中…”)实现,而非单独的提示框。绘制所有状态——空状态、加载中、部分完成、完成、错误、禁用——并使用最少的反馈传递信息,根据事件的重要性调整反馈程度。
调用:针对最常用的交互(保存、提交、切换、删除、加载)使用技能。询问触发/规则/反馈/循环审计结果、每个交互所需的具体反馈、完整状态图谱,以及一个标志性交互时刻。
microinteractions与用户共同决策:(1) 优先打磨哪些交互。(2) 哪个标志性交互时刻值得额外打磨——应用移除测试:如果移除它,产品体验会明显变差吗?
产出物:扩展docs/DESIGN.md中的(交互 | 触发/规则/反馈/循环 | 修复方案 | 状态);将修复方案添加到docs/EXPERIMENTS.md中的。更新追踪文件。
## Microinteraction Inventory## Experiment Backlog完成标志:每个被审计的交互都记录了四个部分和所需反馈,所有状态已绘制,标志性交互时刻通过移除测试,修复方案已标记状态。
Phase 6 — Sharpen the in-app words (made-to-stick)
阶段6——优化应用内文案(made-to-stick)
Purpose: Make the copy users read inside the app — onboarding, empty states, errors, CTAs, tooltips — concrete, clear, and jargon-free.
Brief (fallback): Beat the Curse of Knowledge: once you know the product you can't imagine not knowing it. Score key in-app copy on SUCCESs (Simple, Unexpected, Concrete, Credible, Emotional, Stories). Concrete beats abstract: "Users open the app 8 times a day," not "increase engagement." Simple is the Commander's Intent — the one thing a screen must land; if a label needs a manual, rewrite the label.
Invoke: Use the skill with the onboarding copy, empty states, error strings, CTAs, and tooltips plus the Phase 1 job language. Ask for a SUCCESs score per surface with concrete de-jargoned rewrites and the Commander's Intent for each screen.
made-to-stickDecide with the user: Which abstractions become which concrete specifics, and what is the one thing each screen must land?
Artifact: Extend docs/POSITIONING.md (surface = the in-app screen | message | status) with SUCCESs scores and concrete rewrites; append copy tests to docs/EXPERIMENTS.md . Update the tracker.
## Key Messages## Experiment BacklogDone when: each in-app surface has a SUCCESs score and a concrete rewrite, jargon is gone, the Commander's Intent per screen is named, and the messages are logged by surface.
目标:让应用内用户阅读的文案——新用户引导、空状态、错误提示、CTA、工具提示——具体、清晰且无行话。
简要说明(备选方案):克服知识诅咒:一旦你了解产品,就无法想象不了解它的感受。使用SUCCESs原则(Simple简洁、Unexpected意外、Concrete具体、Credible可信、Emotional情感、Stories故事)为关键应用内文案评分。具体优于抽象:“用户每天打开应用8次”,而非“提升用户参与度”。简洁就是核心意图——每个界面必须传递一个核心信息;如果标签需要说明文档,就重写标签。
调用:结合新用户引导文案、空状态文案、错误提示、CTA、工具提示以及阶段1的任务语言,使用技能。询问每个界面的SUCCESs评分、具体的去行话重写版本,以及每个界面的核心意图。
made-to-stick与用户共同决策:哪些抽象表述应改为具体内容,每个界面必须传递的核心信息是什么?
产出物:扩展docs/POSITIONING.md中的(界面 = 应用内屏幕 | 文案 | 状态),包含SUCCESs评分和具体重写版本;将文案测试添加到docs/EXPERIMENTS.md中的。更新追踪文件。
## Key Messages## Experiment Backlog完成标志:每个应用内界面都有SUCCESs评分和具体重写版本,行话已消除,每个界面的核心意图已明确,文案按界面记录。
Phase 7 — Persuade honestly at the decision points (influence-psychology)
阶段7——在决策点诚信说服用户(influence-psychology)
Purpose: Make the in-app marketing surfaces — paywalls, upgrade prompts, trial nudges, social proof, badges — persuade with true evidence, not tricks.
Brief (fallback): People decide with mental shortcuts — seven principles trigger "yes": reciprocity, commitment, social proof, authority, liking, scarcity, unity. Apply them where the user decides (paywall, upgrade, trial end); layer principles, keep every claim truthful, keep the decision reversible. Ethics gate: any fabricated proof, fake scarcity, or hidden-cost dark pattern is disqualifying — a tactic that only works if the user doesn't know the strategy is manipulation, not persuasion.
Invoke: Use the skill on the upsell surfaces from intake. Ask which principles fit each decision point, the honest copy for each, and a reversibility check — flag any cue that needs evidence you don't have.
influence-psychologyDecide with the user: (1) Which principle leads at each surface. (2) For each scarcity or social-proof cue: is it true today? If not, cut it or make it true before shipping.
Artifact: Extend docs/POSITIONING.md (surface | message | status) with the persuasion copy; queue each change in docs/EXPERIMENTS.md with the metric it should move. Update the tracker.
## Key Messages## Experiment BacklogDone when: each upsell surface names its lead principle and honest copy, every scarcity/social-proof claim is verified true or cut, decisions are reversible, and changes are queued as experiments.
目标:让应用内营销界面——付费墙、升级提示、试用提醒、社交证明、徽章——用真实证据说服用户,而非使用套路。
简要说明(备选方案):人们通过心理捷径做决策——七个原则会触发“同意”:互惠、承诺、社交证明、权威、喜爱、稀缺、团结。在用户做决策的地方(付费墙、升级、试用结束)应用这些原则;叠加原则,保持所有声明真实,让决策可逆。道德准则:任何伪造证据、虚假稀缺或隐藏成本的黑暗模式均不可取——只有当用户不知道策略时才有效的手段是操纵,而非说服。
调用:针对信息收集阶段确定的升级界面使用技能。询问每个决策点适用的原则、诚信文案,以及可逆性检查——标记任何需要你没有的证据的提示。
influence-psychology与用户共同决策:(1) 每个界面以哪个原则为主导。(2) 每个稀缺性或社交证明提示:当前是否真实?若不真实,删除它或在上线前使其真实。
产出物:扩展docs/POSITIONING.md中的(界面 | 文案 | 状态),包含说服文案;将每个变更添加到docs/EXPERIMENTS.md中的并标注预期影响指标。更新追踪文件。
## Key Messages## Experiment Backlog完成标志:每个升级界面都明确了主导原则和诚信文案,所有稀缺性/社交证明声明已验证真实或删除,决策可逆,变更已列为实验任务。
Phase 8 — Make it feel fast where users touch it (high-perf-browser)
阶段8——让用户接触的部分感觉流畅快速(high-perf-browser)
Purpose: Fix perceived slowness on the interactions and entry views users feel — speed is part of the experience, not a back-end afterthought.
Brief (fallback): Latency, not bandwidth, is the bottleneck — most pain is too many round trips. Target the field metrics: INP under 200ms on key interactions (break long tasks, defer non-critical JS), LCP under 2.5s on entry views (preload the hero, raise fetchpriority), CLS under 0.1 (reserve space with explicit dimensions). Where real latency remains, hide it with skeleton screens and optimistic UI so the interface responds before the server does.
Invoke: Use the skill on the slowest key interaction and entry view with a trace or Lighthouse run if available. Ask for the INP long tasks, the LCP element, layout-shift sources, and an impact-ordered fix list including where skeletons or optimistic UI apply.
high-perf-browserDecide with the user: Which interactions and views to measure first, and confirm the field-metric targets as the lines in the sand.
Artifact: Extend docs/DESIGN.md (heuristic = performance; issue | severity 0-4 | fix | status) with INP/LCP/CLS rows; append fixes to docs/EXPERIMENTS.md . Update the tracker.
## UX Audit Findings## Experiment BacklogDone when: INP/LCP/CLS baselines are recorded as performance rows, targets are set (INP < 200ms, LCP < 2.5s, CLS < 0.1), and each fix is ordered by impact with skeleton/optimistic-UI fallbacks noted where latency remains.
目标:修复用户感知到的交互和入口界面的卡顿——速度是体验的一部分,而非后端的事后补救。
简要说明(备选方案):延迟而非带宽是瓶颈——大部分痛点源于过多的往返请求。瞄准现场指标:关键交互的INP低于200ms(拆分长任务,延迟非关键JS),入口界面的LCP低于2.5s(预加载核心元素,提升fetchpriority),CLS低于0.1(用明确尺寸预留空间)。若真实延迟无法消除,使用骨架屏和乐观UI隐藏延迟,让界面在服务器响应前做出反馈。
调用:结合最慢的关键交互和入口界面(若有追踪或Lighthouse运行结果)使用技能。询问INP长任务、LCP元素、布局偏移来源,以及按影响排序的修复列表,包括适用骨架屏或乐观UI的地方。
high-perf-browser与用户共同决策:优先测量哪些交互和界面,确认现场指标目标为底线。
产出物:扩展docs/DESIGN.md中的(启发式原则 = 性能;问题 | 严重程度0-4 | 修复方案 | 状态),包含INP/LCP/CLS相关条目;将修复方案添加到docs/EXPERIMENTS.md中的。更新追踪文件。
## UX Audit Findings## Experiment Backlog完成标志:INP/LCP/CLS基线已作为性能条目记录,目标已设定(INP < 200ms,LCP < 2.5s,CLS < 0.1),每个修复方案按影响排序,延迟无法消除的地方已标注骨架屏/乐观UI备选方案。
Phase 9 — Submit it to a brutal, honest review (steve-jobs-design-review)
阶段9——接受严苛诚信的复盘评审(steve-jobs-design-review)
Purpose: Judge the whole experience cold against "insanely great, or not done" — and decide what to subtract.
Brief (fallback): Start from the customer experience and work back. Experience the product cold as a new user, name the One Thing it must do, count steps-to-value, and deliver a binary verdict with a ranked cut list and fix list. Focusing is saying no — every feature is a candidate for deletion. Audit the back of the fence: empty states, error copy, 404, billing, cancellation, receipt email — held to the hero-screen bar.
Invoke: Use the skill on the whole app after Phases 1-8. Ask for a cold walkthrough, the One Thing, the step count to core value, a binary verdict, a ranked cut and fix list, and a back-of-the-fence audit.
steve-jobs-design-reviewDecide with the user: (1) Accept the cut list — which features to actually remove. (2) Which back-of-the-fence fixes ship now versus later.
Artifact: Extend docs/PRODUCT.md (outcome/problem | job served | priority | status) with the cuts and fixes as prioritized rows; append any back-of-the-fence fixes to docs/DESIGN.md ; queue fixes that will ship in docs/EXPERIMENTS.md . Update the tracker.
## Outcome Roadmap## UX Audit Findings## Experiment BacklogDone when: the verdict is recorded, the cut list is agreed with each item's disposition, cuts and fixes are prioritized rows in , and the tracker closes Phase 9.
## Outcome Roadmap目标:以“极致出色,否则未完成”的标准冷静评判整体体验——并决定需要删减的内容。
简要说明(备选方案):从用户体验出发反向推导。以新用户的身份体验产品,明确它必须完成的核心任务,计算获得核心价值的步骤数,给出二元结论及排序后的删减和修复列表。聚焦意味着说不——每个功能都是删减候选。审核“幕后”内容:空状态、错误文案、404页面、账单、取消流程、收据邮件——需达到核心界面的标准。
调用:在阶段1-8完成后,针对整个应用使用技能。询问冷启动体验、核心任务、获得核心价值的步骤数、二元结论、排序后的删减和修复列表,以及“幕后”内容审核结果。
steve-jobs-design-review与用户共同决策:(1) 接受删减列表——实际移除哪些功能。(2) 哪些“幕后”修复立即上线,哪些延后。
产出物:扩展docs/PRODUCT.md中的(结果/问题 | 服务的任务 | 优先级 | 状态),将删减和修复列为优先级条目;将“幕后”修复添加到docs/DESIGN.md中的;将即将上线的修复添加到docs/EXPERIMENTS.md中的。更新追踪文件。
## Outcome Roadmap## UX Audit Findings## Experiment Backlog完成标志:结论已记录,删减列表已达成一致且每个条目有处理结果,删减和修复已作为优先级条目列入,追踪文件标记阶段9完成。
## Outcome RoadmapOptional Phases
可选阶段
| Skill | Add when | Artifact |
|---|---|---|
| ios-hig-design | the app ships natively on iOS | Extends docs/DESIGN.md |
| lean-ux | a risky fix deserves a cheap experiment before a full build | Extends docs/EXPERIMENTS.md |
| continuous-discovery | improvement ideas come from opinions, not weekly user contact | Extends docs/CUSTOMER.md |
| improve-retention | first-run activation friction shows up in the audits (full retention engine: grow-app) | Extends docs/PRODUCT.md |
| web-typography | the app is text-heavy and reading comfort drives the experience | Extends docs/DESIGN.md |
| inspired-product | the backlog is a feature list with no outcomes behind it | Extends docs/PRODUCT.md |
Optional phases follow the same operating rules — load and use each listed skill exactly as a core phase would; insert where the Add-when condition first becomes true.
| 技能 | 添加时机 | 产出物 |
|---|---|---|
| ios-hig-design | 应用原生上线iOS平台 | 扩展docs/DESIGN.md |
| lean-ux | 高风险修复需在全面开发前进行低成本实验 | 扩展docs/EXPERIMENTS.md |
| continuous-discovery | 改进想法来自主观意见,而非每周用户接触 | 扩展docs/CUSTOMER.md |
| improve-retention | 新用户引导摩擦在审计中显现(完整留存引擎:grow-app) | 扩展docs/PRODUCT.md |
| web-typography | 应用以文本为主,阅读舒适度影响体验 | 扩展docs/DESIGN.md |
| inspired-product | 待办列表仅为功能清单,无结果支撑 | 扩展docs/PRODUCT.md |
可选阶段遵循相同操作规则——完全按照核心阶段的方式加载和使用列出的技能;在“添加时机”条件首次满足时插入。
Common Mistakes
常见错误
| Mistake | Fix |
|---|---|
| Polishing visuals before removing friction — a beautiful screen on a confusing flow loses users at the same rate. | Run Phases 2-3 (ux-heuristics, design-everyday-things) first; no visual change ships without a Phase 1-3 finding behind it. |
| Adding color before the grayscale layout works. | Grayscale first, color last; if the screen fails desaturated, no palette saves it (refactoring-ui). |
| Treating "user error" as the user's fault and stacking on more warnings. | Prevent slips with constraints and forgive them with undo, not are-you-sure dialogs (design-everyday-things). |
| Rewriting copy from internal language nobody outside the team tested. | De-jargon against the SUCCESs pass, then ship the rewrite as an EXPERIMENTS card, not a guess (made-to-stick). |
| Fake scarcity or invented social proof in upgrade prompts. | Every scarcity cue and testimonial must be true; replace any tactic that needs invented evidence with one that uses evidence you have (influence-psychology). |
| Shipping the fixes and skipping the brutal end-to-end review. | Run Phase 9 cold as a new user; a binary verdict with a ranked cut list catches what phase-by-phase fixes miss (steve-jobs-design-review). |
| 错误 | 修复方案 |
|---|---|
| 先打磨视觉再消除摩擦——流程混乱但视觉精美的界面,用户流失率不会降低。 | 先运行阶段2-3(ux-heuristics、design-everyday-things);所有视觉变更需有阶段1-3的发现作为依据。 |
| 在灰度布局生效前添加颜色。 | 先灰度模式,后添加颜色;若界面在去饱和模式下效果不佳,任何调色板都无法挽救(refactoring-ui)。 |
| 将“用户错误”视为用户的问题,添加更多警告。 | 用约束避免失误,用撤销功能原谅失误,而非“你确定吗?”对话框(design-everyday-things)。 |
| 从团队内部语言重写文案,未经过外部用户测试。 | 依据SUCCESs原则去除行话,然后将重写版本作为EXPERIMENTS卡片上线,而非主观猜测(made-to-stick)。 |
| 升级提示中使用虚假稀缺或虚构社交证明。 | 所有稀缺提示和推荐语必须真实;替换所有需要虚构证据的策略,改用现有证据支持的策略(influence-psychology)。 |
| 上线修复后跳过严苛的端到端评审。 | 以新用户身份运行阶段9;带有排序删减列表的二元结论会发现分阶段修复遗漏的问题(steve-jobs-design-review)。 |
Completing the Journey
完成旅程
Exit checklist:
- Every phase in is
docs/IMPROVE-APP-PLAN.md,done, orskipped: reason.deferred: reason - CUSTOMER.md re-anchors the job and names where the app underdelivers on each dimension.
- DESIGN.md carries the UX audit findings, tokens/components, microinteraction inventory, and performance rows with owner and priority.
- POSITIONING.md holds the in-app copy and persuasion surfaces, every scarcity and social-proof claim true.
## Key Messages - Each shipped change is an EXPERIMENTS.md card or backlog row with a pre-committed metric, and PRODUCT.md holds the steve-jobs cut and fix list.
## Outcome Roadmap
Close the tracker: every phase / / , and Next Actions carried into
the owning artifacts rather than left in the plan.
doneskipped: reasondeferred: reasonForward routing: when the experience holds up and the goal shifts to habit, retention, and growth loops,
continue with the skill. When the audits keep hitting code-level causes (slow queries, crashes, untestable
modules), continue with the or skill. When the marketing site is the
next weakest surface, continue with the skill.
grow-appimprove-code-qualityremove-technical-debtimprove-website退出检查清单:
- 中的每个阶段均标记为
docs/IMPROVE-APP-PLAN.md、done或skipped: reason。deferred: reason - CUSTOMER.md重新锚定了核心任务,并明确了应用在每个维度未达预期的地方。
- DESIGN.md包含UX审计发现、令牌/组件、微交互清单,以及带有负责人和优先级的性能条目。
- POSITIONING.md中的包含应用内文案和说服界面,所有稀缺性和社交证明声明均真实。
## Key Messages - 每个上线的变更都是EXPERIMENTS.md中的卡片或待办条目,并带有预先设定的指标,PRODUCT.md中的包含steve-jobs删减和修复列表。
## Outcome Roadmap
关闭追踪文件:每个阶段标记为 / / ,下一步行动转入对应产出物,而非留在计划中。
doneskipped: reasondeferred: reason后续引导:当体验达标且目标转向用户习惯、留存和增长循环时,继续使用技能。当审计持续发现代码层面的问题(慢查询、崩溃、不可测试模块)时,继续使用或技能。当营销网站成为下一个薄弱环节时,继续使用技能。
grow-appimprove-code-qualityremove-technical-debtimprove-website