improve-app

アプリを改善する

アプリはすでに公開され、ユーザーも画面も実際のフローも揃っていますが、スムーズであるべきところに粗さが残っています。このジャーニーでは、9つのフェーズを通じて、ユーザーが感じることを根拠に基づく順序で改善します。アプリが担うべき役割を再確認し、摩擦を取り除き、見た目と細かな体験を磨き、言葉を洗練させ、誠実に訴求し、最後に思い切って削れるほど厳しいレビューを行います。対話形式で進み（エージェントは決定する前に質問します）、いつでも再開できます（状態は docs/ に保存されます）。コードレベルの原因はコード改善のジャーニーに回します。この取り組みでは、プロダクト体験を改善します。

基本原則

ユーザーが感じることを、根拠に基づく順序で改善します。アプリが担うべき役割を再確認し、見た目を磨く前に摩擦を取り除き、言葉を洗練させ、誠実に訴求し、最後に思い切って削れるほど厳しいレビューを行います。 分かりにくいフローの画面をどれだけ美しくしても、ユーザーが離れる割合は変わりません。フェーズの順序こそが重要です。

このスキルはフェーズを順序立て、意思決定のための質問を行い、決定内容を記録します。9つの構成スキルが手法を担います。それぞれのフレームワークをその場で考えるのではなく、各スキルを呼び出してください。

ジャーニーマップ

フェーズ	スキル	答える質問	成果物
1	jobs-to-be-done	アプリはどんな役割を担うために選ばれ、どこで期待に応えられていませんか？	docs/CUSTOMER.md を更新 — GATE
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 を更新

運用ルール

1. まず再開します。 何よりも先に、docs/IMPROVE-APP-PLAN.md と Journey Map 内のすべての成果物を読みます。トラッカーが存在する場合は、ジャーニーの状態を3～5行で要約し、どのフェーズに入るかを尋ねます。ユーザーが開始地点を確認したら完了です。トラッカーのあるジャーニーは再開し、決して最初からやり直しません。
2. 初回実行時のみインテークを行います。 トラッカーがない場合は、以下のインテークを実施してから、すべてのフェーズのステータスを pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason のいずれかに設定した docs/IMPROVE-APP-PLAN.md を作成します。トラッカーが存在し、ユーザーがフェーズ計画を確認したら完了です。
3. フェーズへの移行。 フェーズの内容、必要となる決定事項、作成する成果物、おおよその作業量を伝えます。続行／スキップ／延期の選択肢を提示します。GATE とマークされたフェーズは延期できますが、スキップはできません。続行する場合は、フェーズを in-progress に設定します。ユーザーが選択したら完了です。
4. スキルの呼び出しと代替手段。 フェーズのスキルを読み込み、使用します。各フェーズの Invoke 行にはスキルのスラッグが記載されているため、そのスキルを使ってフェーズを実施します。利用できない場合は、npx skills add wondelai/skills/<slug> --global を提示します。ユーザーが拒否した場合は、Brief に従ってフェーズを実施します。どちらの方法で進めるかを明示します。
5. フェーズ内での決定。 「Decide with the user」にあるすべての質問を、具体的な選択肢と推奨案を添えて尋ねます。選択内容はトラッカーの Key Decisions に記録します。決定を確認せずに進めることは不備です。
6. フェーズの終了。 書き込む前に、成果物の草案を提示して承認を得ます。承認後、docs/ ファイルを作成または拡張し、トラッカー（ステータス、Key Decisions、Next Actions）を更新します。ファイルが書き込まれ、フェーズの行が done になったら完了です。
7. 成果物の取り扱い。 書き込む前に読みます。ファイルがない場合のみ作成し、それ以外は拡張して、自分のセクションを追加または更新し、他の人の内容は保持します。ファイル名は docs/ 内で大文字にします。すべての推奨事項は、担当者と優先度を含むチェックボックスまたは表の行として記載します。docs/ ファイルを初めて作成する際は、references/artifact-templates.md を参照します。すべてのセクション見出しを含む完全なひな形から作成し、その後、フェーズで指定されたセクションに内容を記入します。
8. 再設計の前にエビデンスを確認し、説得は誠実に行います。 フェーズ1～3の監査またはエビデンス行に裏付けられていない UI やコピーの変更はリリースしません。根拠となる調査結果のない変更は、監査に差し戻します。リリースした変更はすべて、事前に確定した指標とともに docs/EXPERIMENTS.md に記録します。アプリ内の希少性を訴える表現、ソーシャルプルーフの主張、アップグレードの約束は、すべて事実でなければなりません。捏造したエビデンスを必要とする施策は、手元にあるエビデンスを活用する施策に置き換えます。

インテーク

トラッカーを作成する前に、次の質問をしてください。

1. アプリは何で、ユーザーはどのような仕事を任せるためにアプリを使っていますか？ — ユーザー自身の言葉で教えてください。（フェーズ 1 の基準となり、以降のすべてのフェーズの実施条件になります。）
2. 最も粗さを感じるのはどこですか — わかりにくい画面、反応しない操作、素人っぽい UI、弱いコピー、しつこいアップグレードの案内、動作の遅さなどです。（開始するフェーズを決め、修正フェーズを前倒しします。）
3. どのような証拠がありますか — 録画、サポートチケット、レビュー、ファネルの離脱、利用状況の分析などです。（「なし」の場合は、任意の継続的なディスカバリーフェーズに進みます。）
4. アプリはどのプラットフォームで動作しますか — Web、ネイティブ iOS、または両方ですか？（フェーズ 8 と任意の ios-hig-design の実施条件になります。ブラウザー上での利用がなく、ネイティブの動作がスムーズな場合はフェーズ 8 をスキップします。）
5. アプリ内で販売またはアップセルを行う場所はどこですか — ペイウォール、アップグレードの案内、トライアルの案内、バッジなどです。また、希少性やソーシャルプルーフに関する主張は現時点で真実ですか？（フェーズ 7 の範囲と誠実さに関するガードレールを定めます。）
6. 最も多くのユーザーが離脱する、または最も多くの問い合わせが寄せられるフローはどれですか？（フェーズ 2〜3、5、8 の対象を絞ります。）
7. すでにポジショニング、デザイン、顧客に関するドキュメント（POSITIONING.md、DESIGN.md、CUSTOMER.md）がありますか？（フェーズ 1、4、6、7 で活用します。）

フェーズをスキップする目安：ブラウザー上での利用がなく、ネイティブの動作がスムーズな場合はフェーズ 8 をスキップします。アプリ内にアップセルを行う場所がない場合はフェーズ 7 をスキップします。UI がすでに一貫したトークンスケールに沿ってグレースケールでも明瞭に読める場合はフェーズ 4 をスキップします。アプリ内のコピーがすでに具体的で、専門用語を使っていない場合はフェーズ 6 をスキップします。フェーズ 1 は絶対にスキップしないでください。フェーズ 1 は他のすべてのフェーズの指針となるためです（延期はできますが、スキップはできません）。次に、テンプレートから docs/IMPROVE-APP-PLAN.md を作成し、計画を確認します。docs/IMPROVE-APP-PLAN.md が存在し、すべてのフェーズにステータスが設定され、ユーザーが計画を確認した時点で完了です。

フェーズ

フェーズ 1 — アプリに期待される役割を再確認する（jobs-to-be-done）— ゲート

目的： 画面を変更する前に、ユーザーがアプリに期待する役割と、期待に応えられていない点を明らかにします。フェーズ 2〜9 で修正できるのは、フェーズ 1〜3 の監査または調査結果で指摘された項目だけです。

概要（フォールバック）： 顧客は、特定の状況で前進するために製品を使います。「[状況] のとき、[動機] を満たしたい。そうすれば [成果] を得られる」という形で、アプリの名前は出さずに、期待される役割を記述します。期待される役割には、機能的、感情的、社会的という 3 つの側面があります。いずれかを省くと、ユーザーが使い続ける理由が失われます。初回利用と継続利用（Big Hire と Little Hire）を区別し、利用しないことや、その場しのぎの回避策も含めて代替手段を整理します。

実行： アプリ、その利用データ、インテークで特定した最も粗さの目立つフローを使って、jobs-to-be-done スキルを実行します。期待される役割の記述、3 つの側面それぞれについてアプリが期待に応えられていない点、ユーザーが切り替える代替手段を確認します。

ユーザーと決定： (1) 製品名を使わずに期待される役割を記述できているか確認します。(2) 機能的、感情的、社会的な側面のうち、最も期待に応えられていないのはどれですか？(3) 離脱の原因は Big Hire（オンボーディング）での失敗ですか、それとも Little Hire（日常利用）での失敗ですか？

成果物： docs/CUSTOMER.md に ## Job Statement、## Job Dimensions（機能的／感情的／社会的な各側面と、それぞれについて期待に応えられていない点の注記）、## Competing Alternatives（代替手段 | 選ばれる理由 | 弱点。利用しない場合も含む）を追加します。トラッカーを更新します。

完了条件： 製品名を使わずに期待される役割が記述され、3 つの側面すべてに期待に応えられていない点の注記があり、代替手段が記録され、フェーズ 1 が完了と示されていることです。この条件を満たして初めて、フェーズ 2〜9 に進めます。

フェーズ 2 — ユーザーが考え込む原因となる摩擦を取り除く（ux-heuristics）

目的： ユーザーが離脱するフローの認知負荷を減らします。インターフェースによってユーザーが立ち止まり、考え込んでしまう箇所を特定します。

概要（代替案）： 「考えさせない」——ユーザーは画面をざっと見て、ほどほどに満足できる選択肢を選び、何とかやり遂げます。Nielsen の 10 のヒューリスティックに基づいてヒューリスティック評価を実施します。各問題を 0〜4 で評価し、深刻度 × ユーザーが遭遇する頻度の順に並べ、見た目の問題より重大な問題を優先します。主要画面にトランクテストを適用し（どのアプリか、どの画面か、自分の選択肢は何か、今どこにいるか、検索はどこか）、文章量を半分にし、さらに半分に減らします。また、インライン検証と、「何が、なぜ、どうすればよいか」を伝えるエラーメッセージでフォームを改善します。

実行： フェーズ 1 のジョブとディメンションを使って、離脱率が最も高いフローに ux-heuristics スキルを適用します。深刻度を付けた評価、主要画面ごとのトランクテストの結果、ラベル、フォーム、エラーメッセージの書き換えを依頼します。

ユーザーと決めること： 深刻度 4 と 3 の問題のうち、今すぐ修正するものとバックログに回すものはどれですか？修正は簡単さではなく、深刻度 × 頻度に基づいて実施することを確認します。

成果物： docs/DESIGN.md の ## UX Audit Findings を拡張します（issue | heuristic | severity 0-4 | fix | status）。各修正を ICE とともに docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： すべての問題に 0〜4 の深刻度と修正案が付いていること。各主要画面でトランクテストに合格するか、その結果が記録されていること。深刻度 4 の問題に担当者が割り当てられていること。

フェーズ 3 — エラーを設計で防ぐ（design-everyday-things）

目的： 間違った操作をしにくくし、あらゆる結果を明確にします。ユーザーが間違った操作をしてしまうのは、ユーザーではなくデザインが誤解を招いたからです。

概要（代替案）： 人間のエラーなどなく、あるのは悪いデザインだけです。2 つのギャップを埋めます。実行のギャップ（「どうすればよいか？」）は、明確なシグニファイアと制約で解消します（自由入力ではなく日付ピッカーを使う、有効になるまで送信ボタンを無効にする）。評価のギャップ（「何が起きたか？」）は、0.1 秒未満のフィードバックと、目に見えるシステムの状態で解消します。スリップ（意図は正しいが、操作を間違えた）とミステイク（意図が間違っていた）を区別します。「本当によろしいですか？」というダイアログより元に戻す操作を優先し、何が問題だったか、どう直せばよいかを伝え、決してユーザーを責めないエラーメッセージを書きます。

実行： コアフロー（オンボーディング、主要な操作、破壊的な操作）に design-everyday-things スキルを適用します。シグニファイアが弱い箇所、制約によってエラーを不可能にできる箇所、フィードバックの不足、メッセージの書き換えを確認します。

ユーザーと決めること： エラーメッセージを制約に置き換えるべき箇所はどこですか？確認ダイアログを元に戻す操作に置き換えるべき箇所はどこですか？

成果物： docs/DESIGN.md の ## UX Audit Findings を拡張します（heuristic = Norman gulf；issue | severity 0-4 | fix | status）。修正を docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： 各コアフローのシグニファイア／制約／フィードバックに関する修正が記録されていること。エラーメッセージが「何が、なぜ、どうすればよいか」のチェックリストを満たしていること。破壊的な操作で元に戻せること。

Phase 4 — 機能を損なわず、見た目も明快にする（refactoring-ui）

目的： 画面にプロフェッショナルな視覚的階層を与え、せっかく改善したフローが素人っぽさで台無しにならないようにします。

概要（代替案）： 優れた UI は才能ではなく、仕組みで生まれます。まずグレースケールでデザインし、色を使う前にサイズ、ウェイト、コントラストで階層を確立します。調整要素は掛け合わせず、組み合わせます（1つのヒーロー要素だけは3つすべてを使います）。間隔のスケール（4/8/16/24/32/48/64）を徹底し、グループ間の間隔はグループ内より広くします。テキストは45～75文字、フォームは300～500pxの幅に収めます。色は最後に追加し、色相ごとに5～9段階のシェードを用意し、グレーには色味を加えて純粋な黒は避けます。

実行： Phase 2～3での調査結果と現在のデザイントークンを使って、主要な画面に refactoring-ui スキルを適用します。グレースケールでの階層の調整、間隔のスケールの修正、体系的なカラーパレット、そして具体的なトークン／CSSの変更を依頼します。

ユーザーと決めること： 現在のデザインシステム内で修正するか、新しいトークンを導入するかを決めます。グレースケールでレイアウトが明確になるまで、色の作業は待つことを確認します。

成果物： docs/DESIGN.md の ## Tokens（間隔のスケール・パレットのシェード・シャドウ）と ## Components（コンポーネント | 決定事項 | ステータス）を拡張します。修正内容を docs/EXPERIMENTS.md の ## Experiment Backlog に追加します。トラッカーを更新します。

完了条件： 主要な画面がグレースケールで明確に見え、間隔のスケールが適用され、各画面で主要なアクションが1つ際立ち、トークンに関する決定が記録されていること。

Phase 5 — すべての操作に手応えを与える（マイクロインタラクション）

目的： ユーザーが日々触れる操作にフィードバックを与え、仕方なく使う製品と愛される製品との差を生み出します。

概要（代替案）： すべてのマイクロインタラクションには、トリガー、ルール、フィードバック、ループとモードの4つの要素があります。よくある失敗は、フィードバックがない、または遅れることです。直接操作には100ms未満で応答する必要があります。通常は別のトーストを出すのではなく、ユーザーが触れた要素をアニメーションさせます（ボタンが押し込まれ、「保存中…」と表示されるなど）。空、読み込み中、一部完了、完了、エラー、無効のすべての状態を洗い出し、イベントの重要度に応じて調整しながら、伝達に必要な最小限のフィードバックを使います。

実行： 最もよく使われる操作（保存、送信、切り替え、削除、読み込み）に microinteractions スキルを適用します。トリガー／ルール／フィードバック／ループの監査、それぞれに必要な具体的なフィードバック、すべての状態のマップ、そして象徴的な演出を1つ依頼します。

ユーザーと決めること： （1）どの操作から磨き上げるか。（2）手間をかける価値のある象徴的な演出を1つ選び、削除テストを適用します。つまり、それがなくなると製品が実質的に悪く感じられるかを確認します。

成果物： docs/DESIGN.md の ## Microinteraction Inventory（操作 | トリガー／ルール／フィードバック／ループ | 修正 | ステータス）を拡張します。修正内容を docs/EXPERIMENTS.md の ## Experiment Backlog に追加します。トラッカーを更新します。

完了条件： 監査した各操作の4つの要素と必要なフィードバックが記録され、すべての状態がマップされ、象徴的な演出が削除テストに合格し、修正内容がステータス付きの行として記録されていること。

フェーズ 6 — アプリ内の言葉を磨く（記憶に残る表現）

目的： オンボーディング、空の状態、エラー、CTA、ツールチップなど、アプリ内でユーザーが読む文言を、具体的でわかりやすく、専門用語のないものにします。

概要（フォールバック）： 知識の呪いを克服します。製品を知ると、知らなかった頃を想像できなくなります。アプリ内の主要な文言を SUCCESs（Simple：シンプル、Unexpected：意外性、Concrete：具体性、Credible：信頼性、Emotional：感情、Stories：ストーリー）で評価します。抽象的な表現より、具体的な表現が効果的です。「エンゲージメントを高める」ではなく、「ユーザーは1日に8回アプリを開きます」とします。シンプルさとは、司令官の意図、つまり画面に必ず伝えなければならない唯一のことです。ラベルに説明書が必要なら、書き直します。

実行： made-to-stick スキルを、オンボーディング文言、空の状態、エラーメッセージ、CTA、ツールチップ、およびフェーズ1のジョブに関する表現に適用します。各画面の司令官の意図と、専門用語を取り除いた具体的な書き換え案を添えて、画面ごとの SUCCESs スコアを求めます。

ユーザーと決めること： どの抽象表現をどの具体的な内容に置き換えるか、また各画面で必ず伝えるべき唯一のことは何かを決めます。

成果物： docs/POSITIONING.md の ## Key Messages（画面＝アプリ内画面 | メッセージ | ステータス）に SUCCESs スコアと具体的な書き換え案を追加します。文言のテストを docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： アプリ内の各画面に SUCCESs スコアと具体的な書き換え案があり、専門用語がなく、画面ごとの司令官の意図が明記され、メッセージが画面ごとに記録されています。

フェーズ 7 — 意思決定の場面で誠実に説得する（影響心理学）

目的： ペイウォール、アップグレードの案内、トライアルの案内、ソーシャルプルーフ、バッジなど、アプリ内のマーケティング画面で、巧妙な手口ではなく、真実に基づく根拠を使って説得します。

概要（フォールバック）： 人は思考の近道を使って判断します。「はい」という決断を促す7つの原則があります。返報性、一貫性、社会的証明、権威、好意、希少性、連帯感です。ユーザーが判断する場面（ペイウォール、アップグレード、トライアル終了時）でこれらを適用します。原則を組み合わせ、すべての主張を真実に基づかせ、決断を取り消せるようにします。倫理上の基準として、捏造した証拠、偽りの希少性、隠れた費用を伴うダークパターンは失格です。ユーザーが手法を知らない場合にしか通用しない戦術は、説得ではなく操作です。

実行： influence-psychology スキルを、インテークで挙がったアップセル画面に適用します。各意思決定の場面に適した原則、各原則に沿った誠実な文言、決断を取り消せるかどうかの確認を求めます。根拠がない手がかりにはフラグを立てます。

ユーザーと決めること： （1）各画面で中心となる原則。（2）希少性または社会的証明を示す手がかりごとに、現在も真実かどうかを確認します。真実でなければ削除するか、公開前に真実にします。

成果物： 説得のための文言を docs/POSITIONING.md の ## Key Messages（画面 | メッセージ | ステータス）に追加します。各変更について、改善を目指す指標とともに docs/EXPERIMENTS.md の ## Experiment Backlog に登録します。トラッカーを更新します。

完了条件： アップセル画面ごとに中心となる原則と誠実な文言が明記され、希少性や社会的証明に関する主張はすべて真実であることが確認されているか、削除されています。決断は取り消し可能で、変更は実験として登録されています。

フェーズ 8 — ユーザーが触れる部分を素早く感じられるようにする（high-perf-browser）

目的： ユーザーが遅さを感じる操作や初期表示を改善します。速度は体験の一部であり、バックエンドだけの課題ではありません。

概要（フォールバック）： ボトルネックは帯域幅ではなくレイテンシです。問題の大半は、往復通信が多すぎることにあります。フィールド指標を目標にします。重要な操作では INP を 200ms 未満にする（長いタスクを分割し、重要でない JavaScript の実行を遅らせる）。初期表示では LCP を 2.5s 未満にする（ヒーロー画像をプリロードし、fetchpriority を引き上げる）。CLS は 0.1 未満にする（明示的な寸法を指定してスペースを確保する）。実際のレイテンシが残る場合は、スケルトンスクリーンと楽観的 UI で隠し、サーバーの応答前にインターフェースが反応するようにします。

実行： 利用可能であれば、最も遅い重要な操作と初期表示に high-perf-browser スキルを使用し、トレースまたは Lighthouse を実行します。INP の長いタスク、LCP の要素、レイアウトシフトの原因、およびスケルトンや楽観的 UI を適用する箇所を含め、影響度順の修正リストを求めます。

ユーザーと決めること： どの操作と画面から測定するかを決め、フィールド指標の目標を譲れない基準として確認します。

成果物： docs/DESIGN.md の ## UX Audit Findings（heuristic = performance；issue | severity 0-4 | fix | status）に INP/LCP/CLS の行を追加し、修正を docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： INP/LCP/CLS のベースラインがパフォーマンス項目として記録され、目標（INP < 200ms、LCP < 2.5s、CLS < 0.1）が設定され、レイテンシが残る箇所にはスケルトン／楽観的 UI のフォールバックを明記したうえで、各修正が影響度順に並んでいること。

フェーズ 9 — 厳しく率直なレビューを受ける（steve-jobs-design-review）

目的： 「途方もなく素晴らしいか、まだ未完成か」という基準で、体験全体を先入観なく評価し、何を削るかを決めます。

概要（フォールバック）： 顧客体験を起点に、そこから逆算します。新規ユーザーとして先入観なく製品を体験し、果たすべき唯一のことを明確にし、価値を得るまでのステップ数を数え、削除項目と修正項目を優先順位付きで示した二択の評価を下します。焦点を絞るとは、断ることです。あらゆる機能が削除候補です。フェンスの裏側も監査します。空の状態、エラー文、404、請求、キャンセル、領収書メールも、ヒーロー画面と同じ基準で評価します。

実行： フェーズ 1～8 の完了後、アプリ全体に steve-jobs-design-review スキルを使用します。先入観のないウォークスルー、唯一のこと、コア価値に至るまでのステップ数、二択の評価、優先順位付きの削除・修正リスト、フェンスの裏側の監査を求めます。

ユーザーと決めること： （1）削除リストを受け入れるか、実際に削除する機能はどれか。（2）フェンスの裏側の修正のうち、今すぐリリースするものと後回しにするものはどれか。

成果物： docs/PRODUCT.md の ## Outcome Roadmap（outcome/problem | job served | priority | status）に、削除項目と修正項目を優先順位付きの行として追加します。フェンスの裏側の修正があれば、docs/DESIGN.md の ## UX Audit Findings に追記します。リリースする修正を docs/EXPERIMENTS.md の ## Experiment Backlog に登録します。トラッカーを更新します。

完了条件： 評価が記録され、削除リストと各項目の処遇について合意し、削除項目と修正項目が ## Outcome Roadmap の優先順位付きの行として記載され、トラッカーでフェーズ 9 が完了していること。

オプションのフェーズ

スキル	追加するタイミング	成果物
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 を拡張

オプションのフェーズにも同じ運用ルールが適用されます。記載された各スキルをコアフェーズと同じ方法で読み込み、使用します。「追加するタイミング」の条件が最初に満たされた時点で挿入してください。

よくある間違い

間違い	修正方法
摩擦を取り除く前に見た目を磨くこと。わかりにくいフロー上の美しい画面では、同じ割合でユーザーを失います。	まずフェーズ 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）。

ジャーニーの完了

終了チェックリスト：

• docs/IMPROVE-APP-PLAN.md のすべてのフェーズが done、skipped: reason、または deferred: reason になっている。
• CUSTOMER.md でユーザーの目的を再確認し、各観点でアプリが期待に応えられていない箇所を示している。
• DESIGN.md に UX 監査の指摘、トークン／コンポーネント、マイクロインタラクションの一覧、担当者と優先度を記載したパフォーマンス項目が含まれている。
• POSITIONING.md の ## Key Messages にアプリ内コピーと説得のための表示要素が記載され、希少性や社会的証明に関する主張がすべて事実である。
• リリースした変更がそれぞれ、事前に確定した指標を記載した EXPERIMENTS.md のカードまたはバックログ項目になっており、PRODUCT.md の ## Outcome Roadmap に steve-jobs の削除・修正リストが記載されている。

トラッカーを完了させます。すべてのフェーズを done ／ skipped: reason ／ deferred: reason にし、Next Actions はプランに残さず、担当する成果物に反映します。

次の進め方：エクスペリエンスの品質が保たれ、目標が習慣化、継続率、成長ループに移ったら、grow-app スキルを続けて使用します。監査でコードレベルの原因（遅いクエリ、クラッシュ、テスト不可能なモジュール）が繰り返し見つかる場合は、improve-code-quality または remove-technical-debt スキルを続けて使用します。マーケティングサイトが次に最も弱い部分である場合は、improve-website スキルを続けて使用します。