redamoon UX 思考スキル
使いやすさは見た目の好みではなく、ユーザーが自分の仕事を中断せずに進められるかどうかです。このスキルは、画面や機能のカタログから入らず、終わらせたい仕事から導線・状態・コピーを設計・診断するためのガイドです。
このスキルが出す本丸は、見た目のワイヤーではありません。ワイヤーを描く前に合意する仕様です。名前は 仕事（終わらせたい変化）と シナリオ（画面ではなく出来事の列）です。画面に落とす最初の形は 画面の下書き（面×状態の見出し・本文・主ボタン。配置は書かない）です。既存の診断では つまずき一覧（仕事が止まる場所の表。会計の台帳ではない）を使います。Figma は、画面の下書きのあとの任意の後段です。仕様が固まる前にファイルを開きません。
ビジュアルの美的判断（配色の好み、装飾）は扱いません。コントラスト・余白・文字サイズは、認知負荷と可読性の問題として扱います。実装手段（CSS、コンポーネント名）ではなく、必要なインタラクションと状態を述べます。
会話例と埋まっている成果物は examples.md、出力の型は reference.md、ファイル化するときの型は templates/ux_spec.md を参照します。
When to Use
- ワイヤーや画面案の前に、質問して仕様を固めたいとき（いちばん多い入口）
- 「この機能を足したい」を、ユーザーの仕事に翻訳し直すとき
- 新機能・新画面・新フローの UX を考えるとき
- 「使いづらい」「迷う」「導線が悪い」を診断・修正するとき
- 「この画面どう思う？」「UX レビューして」と依頼されたとき
- 空状態・読込・エラー・権限不足などの状態を設計するとき
- ボタンラベル、空状態文、エラー文などの UX コピーを書くとき
- 画面の役割のあと、配置なしで各面の中身（画面の下書き）を書きたいとき
文書の構成や手順書の書き方は documentation-writing に従います。コピーの日本語そのものの推敲は japanese-prose-revision に従います。このスキルは、操作の体験だけを扱います。
Instructions
成果物
チャットに出すのが基本です。ファイル化は、ユーザーが保存先を指定したときに限ります。デフォルトの保存先は設けません。
| 成果物 | いつ出すか | 中身 | 出さないもの |
|---|---|---|---|
| 質問 | 仕事が固定できないとき。ワイヤー前の最初の一手 | 埋まっていない項だけ。一度にまとめて聞く | 創作したペルソナ、先回りした画面案 |
| 仕事 | 質問の答えが揃ったあと。ワイヤー・実装の前に合意する仕様 | 誰、状況、仕事、成功の瞬間、制約、シナリオ。数字の仕事なら見たい数字と材料 | レイアウト、コンポーネント |
| 画面の役割 | 仕事が合意されたあと（下の止め方） | 各面が何の仕事か、次の一手、出すもの / 出さないもの、必要な状態 | 格子のワイヤー、配色、余白の好み |
| 画面の下書き | 役割のあと、ユーザーが各面の中身を求めたとき | 面×状態の見出し・本文・主ボタン・入力。配置は書かない | 余白・グリッドの提案 |
| 診断 | 既存画面・既存フローがあるとき | つまずき一覧、状態の穴、処方（削る→並べ替える→足す） | ヒューリスティックの点数表だけ |
| コピー案 | 文言を直す・書くとき | ボタン、ラベル、空状態、エラー、確認 | トーンの感想だけ |
| Figma ワイヤー | 画面の下書きのあと、ユーザーが Figma を求めたとき | 1面×必要な状態の低忠実度フレーム。文言は画面の下書きのまま | 仕様にない面、装飾、成功画面だけ、購読ライブラリの完成コンポーネント |
「ワイヤーを作って」「Figma で起こして」と言われても、仕事が固定されていなければ質問から始めます。役割が一覧になったら、Figma に渡す前に面×状態の一覧を示します。ファイル URL は「どのファイルか」の指定であり、一覧の確認の省略ではありません。
会話の経緯を残してほしいと言われたら、決定と開いていた問いだけを短く書く。仕様本文の複製や、別テンプレのセッション記録を発明しない。途中で直したことは仕様の「まだ開いている問い／途中で直したこと」に足す。
ワイヤー前の進め方
新規の画面や機能では、この順を守ります。
- 欲しい成果物を確認する。 言われていなければ「仕事 → 画面の役割 → 画面の下書き」を提案する。Figma は求められたときだけ
- 足りない項だけを、一度にまとめて聞く。 一問ずつ尋問しない。ペルソナを創作して穴を埋めない
- 仕事を書く。 シナリオの見出しまで。数字の仕事なら見たい数字と材料も書く。ここで止めて確認を取る
- 画面の役割に進む条件。 「これでよい」と言われるか、当初の成果物に役割が含まれ かつ 開いている問いが全て埋まったとき。開いている問いへの回答が来たら、先に仕事を更新して出す。回答そのものを沈黙の合意にしない。式や材料が空のまま、面のコピーや名前を固定しない
- 画面の役割を出す。 面の数は仕事を進めるのに必要な最小。社内のモデル境界で面を増やさない。仕事が場所や端末で変わるなら、そこで面を分ける
- ユーザーが画面の下書きを求めたら、役割を入力として各面×状態の中身（主ボタン、入力、見出し）を書く。配置の好みには入らない。成果物表の「画面の下書き」である
- ユーザーが Figma を求めたら、下の「Figma への引き渡し」に従う。求められていなければ Figma を開かない
まとめて聞く質問は、次で足りることが多いです。答えがある項は聞き直しません。
- 誰が、何を終わらせたいか。終わったと感じる瞬間はどこか（画面到着ではない）
- 何がきっかけで、急いでいるか。途中で中断されるか
- 頻度はどれか（初めて／毎回。毎回なら毎日・毎週・毎月など）。高い側と低い側の両方があるか
- 既存の画面・言葉・制約はあるか。一人か共有か、どの端末か。同じ仕事が別の場所・別の端末に残るか
- 今回欲しい成果物はどれか（仕事 / 画面の役割 / 画面の下書き / 既存の診断 / コピー案。複数可）
終わったときに 数字を見て終わる 仕事なら、同じターンで足す。式が分からないまま画面の役割に進まない。
- 見たい数字は何か。その材料は何か。材料はいつ揃うか（確定日か、その場か）
基本原理
- 仕事から入る。 画面・機能・技術制約は、仕事を特定したあとに初めて材料になる。先に画面を描くと、プロダクトの都合が仕事に見える
- 判定の軸は一つだけ。 その要素が更新するのは「ユーザーの仕事」か、「プロダクトの都合」か。都合側（社内分類、実装の切れ目、データの持ち方）をそのまま画面に出すのは、原則として設計失敗である
- 次の一手を常に一つにする。 ユーザーが「今なにをすれば仕事が進むか」に即答できない位置は、未回収の迷いである。迷いが残ったまま選択肢を増やすと、仕事は進まない
- 状態を全部設計する。 データが入った成功画面だけを描いたなら、プロダクトの半分しか設計していない。空・読込・エラー・部分成功・権限不足・オフラインが本体である
- 摩擦は数える。 「なんとなく使いづらい」で止めない。決定・入力・認知・待ち・回復・信頼のどれが増えているかを特定する
- コピーは操作である。 ラベル・空状態・エラー文は装飾ではなく、次の一手を指名する操作系である
- 装置は宣言しない。 「直感的に」「シームレスに」「ストレスフリーに」は診断でも設計でもない。誰が、どの仕事で、何回の操作で、何が分かれば次に進めるのかを書く
使い方の順序
入口が違っても、仕事の特定が先です。不足情報があれば成果物を埋めず、質問を出します。
- 入口を判定する（ワイヤー前の仕様固め / 新規設計 / 既存の診断 / 不満の翻訳 / コピーだけ）
- 仕事を特定する（誰が、どの状況で、何を終わらせたいか、成功の瞬間）
- シナリオを書く（画面ではなく出来事の列。開始前から完了後まで）
- 仕事を確認する（新規ではここで一度止める）
- 画面の役割を書く、または既存なら つまずき一覧 と 状態の穴
- 求められたら 画面の下書き（面×状態の中身。配置は書かない）
- 次の一手とフィードバックを点検する
- 処方を優先度付きで出す（削る → 並べ替える → 足す、の順）
- 検証の問いを残す（何が起きれば、この設計が当たっていると言えるか）
大きな提案の前に、仕事とシナリオの見出しだけを先に示します。画面案から入ると、議論が部品の好みに落ちます。
仕事の特定
機能要望をそのまま設計対象にしない。「X を追加して」は、仕事の言い換えが終わるまで保留します。
次を一文で固定します。埋まらない項は、ユーザーに聞きます。
| 項 | 聞くこと | 悪い固定の仕方 |
|---|---|---|
| 誰 | 役割と、今持っている知識。初心者かどうかは仕事ごとに決まる | 架空の人物設定を冠する |
| 状況 | 何がきっかけで、何を急いでいるか。中断されるか | 「いつでも使えるように」でぼかす |
| 仕事 | 終わらせたい変化。画面を開くこと自体は仕事ではない | 機能名を仕事だと思う |
| 成功 | ユーザーが「終わった」と感じる瞬間。ダッシュボード到着ではない | 社内 KPI を成功と呼ぶ |
| 数字 | 見たい数字、材料、材料が揃う時点（数字の仕事のとき） | 式が空のまま面の名前を先に決める |
| 制約 | 端末、既存の言葉、頻度、一人か複数か、別の場所に残る仕事 | 制約を後回しにして理想画面を描く |
仕事は「When（状況）、I want to（動機）、so I can（成果）」で短く書いてよい。成果がプロダクトの機能名になった時点で、書き直しです。
数字を見て終わる仕事では、成功の瞬間の数字を名付ける。材料と、材料が揃う時点が空なら、開いている問いに残す。推測したラベル（「入れる金額」など）で面を固定しない。
最初の成功（仕事が一度でも前に進んだ瞬間）までの手数を、設計の主指標にします。設定の完了、チュートリアルの完了、空のホーム画面の表示は、成功ではありません。
シナリオの書き方
画面一覧ではなく、出来事の列で書きます。
- きっかけ（プロダクトの外で起きていること）
- 期待（ユーザーが「こうなればいい」と思っている結果）
- 最初の接触（何を見て、何ができると認識するか）
- 最初の成功
- 迷いどころ（次の一手が複数に見える位置）
- 失敗したとき（入力ミス、権限、通信、途中離脱）
- 完了の確認（終わったと分かるフィードバック）
- 完了後に残る仕事（共有、やり直し、次の一件）
既存画面があるときは、この列に現状を当て、途切れている位置を先に指します。途切れを指さずに改善案を出すと、部品の差し替えになります。
同じ仕事を、頻度の高い側と低い側の両方で一度ずつ辿ります。毎日なら「毎日」と「初めて」。月次なら「初回の確定」と「翌月の同じ仕事」。片方に最適化した導線は、もう片方を置いていきやすい。仕事が確定のあと、別の場所（ATM など）に残るなら、シナリオの「完了後」にその出来事を書く。そこで端末や次の一手が変わるなら、面を分ける。
画面の役割の書き方
仕事が合意されたあと、面ごとに次を一行ずつ固定します。面は画面でもステップでもよく、レイアウトではありません。
| 項 | 書くこと |
|---|---|
| この面の仕事 | シナリオのどの出来事を進めるか。社内エンティティの名前ではない |
| 次の一手 | 主操作。結果の動詞 |
| 出すもの | その一手に必要な情報・入力だけ |
| 出さないもの | 今の仕事に使わない設定、別の仕事の入口 |
| 必要な状態 | 空、読込、成功、エラー、権限、中断のうち、この面で起きること |
面の分割は、仕事が変わるところでだけ行います。データの種類が違うだけでは面を増やしません。
画面の下書きの書き方
画面の役割が合意されたあと、Figma の前に出す中間成果物です。枠の位置ではなく、見出し・本文・主ボタンを文章で置くことです。「各面の中身」「テキストで画面を」「下書き」「スケッチ」と言われたらこれを出します。役割の表だけ、またはいきなり Figma、には飛ばない。
面×必要な状態ごとに、次だけ書く。配置・余白・グリッドは書かない。
| 項 | 書くこと |
|---|---|
| 見出し | 今の仕事が何か。社内語ではない |
| 本文 | いま何が無いか、または何が確定しているか。次の一手が分かること |
| 主ボタン | その面の「次の一手」をそのまま。1面に一つ。無ければ「なし」と理由 |
| 入力 | この状態で入れるもの。無ければ「なし」 |
| 出さないもの | 役割に書いた出さないものをここでも守る |
空・読込・エラー・中断も別ブロックにする。成功だけ書いて終わらない。主ボタンは結果の動詞にする（「送信」にしない）。同じ仕事には、仕事の節で固定した言葉だけを使う。
埋まっている例は examples.md の「画面の下書き」を参照する。
Figma への引き渡し
画面の下書き（または画面の役割）が合意され、ユーザーが Figma でのワイヤーを求めたときにだけ進みます。このスキルは仕様を渡し、描画は Figma を操作する手段（MCP や Plugin API など、その環境で使えるもの）に委ねます。手段が使えないときは、画面の下書きに止め、Figma を開けないと伝えます。画面の下書きがまだなら、フレームを起こす前にそれを出す。
渡す入力は、仕事と画面の役割（画面の下書きがあればそれ）です。ペルソナや装飾の指示は渡しません。
- 起こすフレームの一覧を先に示す（面 × 必要な状態）。仕様にない面は足さない
- ファイル URL は「どのファイルか」の指定である。一覧の確認とは別にする。URL と「入れて」が同時でも、同じターンで一覧を出してから描く
- 端末サイズが未合意なら、仕事の制約（PC / スマホ）から幅を決めて一覧に書き、サイズだけで会話を止めない。既存ファイルに画面があればその幅に合わせる
- 低忠実度で描く。グレーの枠、見出し、本文、主ボタン、入力欄。影・グラデーション・ブランドカラーは使わない。ファイルに購読されているデザインシステム（Material など）は、低忠実度では使わない
- 主ボタンの文言は、その面の「次の一手」をそのまま使う。プレースホルダの「Button」にしない
- 「出さないもの」に書いた要素は置かない
- 成功画面だけ描いて終わらない。空・読込・エラーなど、役割に書いた状態を別フレームにする
- フレーム名は仕事の言葉にする（
口座の差額 / 空、合算を見る / オフライン）。社内モデル名にしない
既存ファイルにすでにワイヤーや画面があるときは、その間隔と端末サイズに合わせます。コンポーネントライブラリの完成品は低忠実度の代替にしない。新規で画面が空のときは、仕事の制約から幅だけ決める。デザインシステムを発明しません。
Figma 上で要素を足したくなったら、先に画面の役割へ戻って面か状態を増やすかを決めます。キャンバスで仕様を上書きしません。
つまずき一覧
仕事が止まる場所の表です。会計の台帳ではありません。種別（決定摩擦など）は、止まった理由の分類です。
使いづらさは、次のどれかとして数えます。一つの位置に複数が重なることが多いので、まとめて「複雑」と呼ばない。
| 種別 | 何が増えているか | 典型 |
|---|---|---|
| 決定摩擦 | 選ばなければならないこと | 同等に見えるボタンが並ぶ、設定項目が多い |
| 入力摩擦 | 今持っていない情報を聞かれること | 任意なのに必須に見える、後でしか分からない値 |
| 認知摩擦 | 用語・配置・結果が予想と違うこと | 社内語、アイコンだけ、画面の役割が二つ |
| 待ち摩擦 | 何が起きているか分からない待ち | 無言の読込、連続する確認 |
| 回復摩擦 | ミスから仕事へ戻れないこと | 入力が消える、戻ると最初から |
| 信頼摩擦 | この操作で何が起きるか分からないこと | 破壊的操作なのに軽い、課金なのに結果が見えない |
一覧には、位置・種別・仕事が止まる理由・今の次の一手、を一行で書きます。感覚的な評点は不要です。仕事を止める摩擦を先に処理し、好みの摩擦は後回しにします。
摩擦の処方は、足すより先に削るか、並べ替えるかです。
- 削る：その場で仕事に使わない入力、同等の選択肢、説明で補っている一手
- 並べ替える：最初の成功のあとへ設定を送る、破壊的操作を主ボタンから外す
- 足す：次の一手の指名、結果のフィードバック、回復手段。足すのは穴があるときに限る
説明文やオンボーディングで複雑さを正当化しません。説明が必要な操作は、操作の方が間違っていることが多い。
状態の設計
主画面ごとに、少なくとも次を埋めてからレイアウトの話に入ります。
| 状態 | ユーザーが見ている世界 | 次の一手 |
|---|---|---|
| 初期（空） | まだ何もない。失敗ではない | 最初の成功へ進む行動 |
| 読込 | 仕事は進んでいる最中 | 待てばよいか、止めてよいかが分かる |
| 成功 | 期待した変化が起きた | 次の一件か、完了してよいか |
| 部分成功 | 一部だけ終わった | 残りをどうするか |
| 入力エラー | 直せる問題がある | 直す位置と直し方 |
| システムエラー | ユーザーのせいではない | やり直すか、別の手段か |
| 権限不足 | この人では進めない | 誰に何を頼むか、別の入口か |
| オフライン / 中断 | 途中で切れた | どこまで残っていて、何から再開するか |
空状態を「データがありません」で終わらせない。空は失敗画面ではなく、最初の成功への入口です。エラー文は原因の帰属を間違えない。入力の問題はフィールドの横で直し方を言い、システムの問題をユーザーの操作ミスとして書かない。
破壊的操作（削除、公開、課金、送信）は、結果を先に見せるか、取り消せるようにする。確認ダイアログを増やすことは、安全の代替ではありません。ダイアログは、結果が見えないときか、取り消しが効かないときにだけ使います。
次の一手とフィードバック
画面・ダイアログ・メールのそれぞれで、次を即答できるようにします。
- 今、何の仕事の途中か
- 次にやることは一つに見えるか
- それをやると何が起きる vis で分かるか（アフォーダンスと結果の予告）
- やったあと、仕事が前に進んだと分かるか（フィードバック）
- 間違えたら、どこから戻れるか
主ボタンは、仕事を前に進める動詞で名指します。メカニズム（「送信」「実行」「OK」）ではなく、結果（「予約を確定する」「下書きを公開する」）です。副操作（キャンセル、あとで）は、主ボタンと視覚的にも言葉のうえでも競わせません。
同じ仕事に、同じ言葉を使い続けます。一覧では「ワークスペース」、詳細では「プロジェクト」のように、画面が変わるたびに別名へ後退しない。
コピー
コピーは、次の一手を指名するために書きます。雰囲気を足す文、プロダクトの自己紹介、ユーザーを責める文は書きません。
- ボタン：結果の動詞。1画面に主ボタンは一つ
- ラベル：ユーザーが持っている呼び方。社内のモデル名をそのまま出さない
- 空状態：いま何が無いか + 最初の成功への行動。励ましのスローガンは不要
- エラー：何が起きたか + どう直すか。システムエラーに「もう一度入力してください」は使わない
- 確認：何が起きるか。起きないことの説明で埋めない
- ヘルプ：その場の迷いを解く一文。概念の解説は、操作の外へ出す
「直感的」「簡単」「誰でも」はコピーにも診断にも使いません。誰の、どの仕事で、何が分かれば次に進めるのかに言い換えます。
アクセシビリティ（下限）
後付けの品質項目ではありません。次を満たさない設計は未完成です。
- 名前：アイコンだけ、プレースホルダだけの入力にしない。操作にはテキストの名前がある
- コントラストと拡大：色だけ、小さな文字だけで区別しない
- キーボードとフォーカス：マウス前提の操作を主経路にしない
- エラーの関連：何が違うのかを、対象フィールドと関連づけて伝える
- 動き：点滅や自動再生で仕事を邪魔しない。ユーザーが止められる
対象ユーザーに支援技術が含まれるかどうかは、仕事の特定で聞きます。聞かない場合でも、上の下限は外しません。
やってはいけないこと
- 機能のカタログを画面にする（ナビゲーションが増えるだけで仕事は進まない）
- 判断を設定画面へ逃がす（良い初期値を決める代わりにスイッチを増やす）
- 成功経路だけ描く
- 「オンボーディングで説明する」で複雑さを残す
- 確認ダイアログを増やして安全にした気になる
- ユーザーの時間で、プロダクト側の不確実性を吸収する（任意入力の必須化、重複確認）
- ダークパターン（誤誘導の同意、やめにくい解約、焦らせるカウントダウン）
- ペルソナや感情マップの作成自体を成果にする。仕事・シナリオ・摩擦・状態が動かない成果は、思考の痕跡ではない
- 式が空のまま、推測した数字の名前で面を固定する
- ファイル URL を理由に、面×状態の一覧を出さずに描き始める
- 低忠実度のワイヤーに、購読中のデザインシステムを載せる
診断の出し方
平坦な文章スキルと同じく、症状から処方を引きます。先に部品の改善案を並べません。
| 症状 | 原因 | 処方 |
|---|---|---|
| どこを押せばよいか分からない | 次の一手が複数、または無名 | 主ボタンを一つにし、結果の動詞で名指す |
| 正しいのに使われない | 最初の成功が遠い | 設定や学習を成功のあとに送る。空状態を入口にする |
| 入力で離脱する | 今持っていない情報を聞いている | 必須を仕事に必要な最小へ削る。残りはあとで |
| エラーで詰まる | 原因の帰属が違う、直し方が無い | フィールド横で直し方を言う。システムエラーは再試行か別手段 |
| 毎回同じ設定をする | 初期値が仕事に合っていない | デフォルトを仕事側に寄せ、設定を主経路から外す |
| 既存ユーザーが迷う | 用語・配置が画面ごとに違う | 仕事の言葉で統一し、役割が二つの画面を割る |
| レビューが好みの話になる | 仕事が固定されていない | 仕事と成功の瞬間を先に合意し、部品の議論を止める |
出力の型、状態インベントリ、ヒューリスティックの早見は reference.md にあります。会話の例は examples.md にあります。ヒューリスティックは点検の補助であり、仕事の特定の代替ではありません。