「家計簿アプリを作りたい」と言われたら、これまでは画面から考え始めていました。ホーム画面、入力フォーム、グラフ。ワイヤーを描いてから「こんな感じでどうですか」と聞く進め方です。
この順番は、途中で必ず詰まります。画面を描いた時点で、分類・予算・共有・年次レポートといった家計簿アプリの機能カタログがそのまま画面の数になってしまうからです。ユーザーが実際に終わらせたい仕事は、もっと小さいことが多いのに。
この順番を変えるために、画面より先に仕事を固める ux-thinking というSkillを作りました。実際に自分のセッションで使ってみたところ、質問の型に穴が見つかり、そのままSkill自体を書き直すことになりました。ここでは使い方と、実践から更新に至った経緯をまとめて書いておきます。
画面から入ると何が起きるか
画面を先に描くと、判断の軸がプロダクトの都合に寄ります。社内の分類、実装の切れ目、データの持ち方。これらは本来ユーザーの仕事とは関係ないのに、画面に出た瞬間、あたかも仕事の一部であるかのように見えてしまいます。
ux-thinkingでは、この軸をひとつに絞りました。その要素が更新するのは「ユーザーの仕事」か「プロダクトの都合」か。都合側をそのまま画面に出すのは、原則として設計の失敗として扱います。
同じくらい大事にしているのが、次の一手を常に一つにすることです。ユーザーが「今なにをすれば仕事が進むか」に即答できない位置は、回収されていない迷いです。迷いを残したまま選択肢だけ増やしても、仕事は前に進みません。
進め方と成果物
新規の画面や機能では、次の順を崩さないようにしています。
- 欲しい成果物を確認する。言われていなければ「仕事 → 画面の役割 → 画面の下書き」を提案する
- 足りない項だけを、一度にまとめて聞く
- 仕事を書く。シナリオの見出しまで出して、ここで一度止めて確認を取る
- 「これでよい」と言われるまで、画面の役割に進まない
- 画面の役割を出す。面の数は仕事を進めるのに必要な最小
- 求められれば画面の下書き（面×状態の中身。配置は書かない）を出す
- 求められればFigmaへ引き渡す
成果物の呼び方は途中で整理し直しました。仕事の合意までを「仕事」、画面ではなく出来事の列を「シナリオ」、役割合意のあとに配置なしで面の中身を書くものを「画面の下書き」、既存画面の診断表を「つまずき一覧」と呼んでいます。以前は仕事定義・旅・テキストスケッチ・摩擦台帳という名前でしたが、実体をそのまま指す言葉に統一しました。
まとめて聞く質問は、次の5つで足りることがほとんどです。
- 誰が、何を終わらせたいか。終わったと感じる瞬間はどこか
- 何がきっかけで、急いでいるか。途中で中断されるか
- 頻度はどれか（初めて／毎回。毎回なら毎日・毎週・毎月など）。高い側と低い側の両方があるか
- 既存の画面・言葉・制約はあるか。一人か共有か、どの端末か。同じ仕事が別の場所・別の端末に残るか
- 今回欲しい成果物はどれか
一問ずつ尋問しないこと、答えのない項をペルソナの創作で埋めないことも決めています。
実際の使い方: 予約機能を例に
言葉で説明するより、実際にどんなやり取りになるかを見たほうが早いです。「カレンダーアプリに予約機能を足したい」という依頼で試した例です。
まず、画面案を出さずに質問だけ返します。
ワイヤーの前に、仕事を固めたいです。分かっている範囲で答えてください。
1. 誰が、何を終わらせたいですか。終わったと感じる瞬間はどこですか
（予約画面を開くこと自体ではない）
2. 何がきっかけで、急いでいますか。途中で中断されますか
3. 頻度はどれですか（初めて／毎回）。高い側と低い側はありますか
4. 既存の画面・言葉・制約はありますか。一人か共有か、どの端末ですか
5. 今回欲しいのは、仕事、画面の役割、画面の下書き、既存の診断、コピー案のどれですか
答えが返ってきたら、仕事とシナリオをまとめて出し、画面の役割に進んでよいか確認します。
## 仕事
- 誰: 家族の予定を入れる保護者。予約という言葉は使っていない
- 状況: 金曜の夜、チャットを見ながら。途中で中断される
- 終わらせたい変化: 候補の日時が、相手の承諾つきで自分のカレンダーに確定して載る
- 成功の瞬間: 確定した一件がカレンダーに見え、相手にも届いていると分かる
- 一文: When 金曜の夜に家族の予定を決めたいとき, I want to 一件を相手に確定してもらう,
so I can 週末の動きをカレンダーで見られる
## シナリオ
1. きっかけ: 相手から「土曜空いてる？」とメッセージが来る
2. 期待: 土曜の候補を入れて、相手が承諾し、自分のカレンダーに載る
（中略、完了後まで8項目を書く）
この内容で画面の役割に進めてよいですか。
合意が取れたら画面の役割です。レイアウトではなく、各面が何の仕事を担うかだけを書きます。
## 画面の役割
### 面1: カレンダー（入口）
- この面の仕事: 最初の予定を入れる、または確定済みを見る
- 次の一手: 予定を入れる（空のとき） / 予定を開く（あるとき）
- 出すもの: 日付、既存の予定、主ボタン
- 出さないもの: ワークスペース作成、チーム名、タイムゾーン
- 必要な状態: 空（入口）、読込、成功（予定あり）、権限不足
ここで止まらず「各面の中身を」と言われたら、面×状態ごとに見出し・本文・主ボタン・入力だけを書きます。配置には触れません。
### 面1 / 空
- 見出し: まだ予定がない
- 本文: 最初の一件を入れると、週末の動きが見える
- 主ボタン: 予定を入れる
- 入力: なし
- 出さないもの: ワークスペース作成、チーム名
Figmaを求められたときだけ、面×状態のフレーム一覧を先に示してから低忠実度で描きます。ファイルURLが一緒に来ても、一覧の確認を省略しません。
| フレーム | 主ボタン | 置くもの | 置かないもの |
| ------------------- | ---------------- | -------------------------------- | ---------------------- |
| Calendar / Empty | 予定を入れる | 日付、空の説明 | ワークスペース作成 |
| Put event / Editing | 確定の依頼を送る | 日付、時刻、相手 | 繰り返しの詳細 |
| Put event / Error | 確定の依頼を送る | フィールド横の直し方、入力は残す | 空フォームへのリセット |
この一覧でFigmaに起こします。文言は画面の下書きのまま。端末はスマホ390。
ファイルは新規ですか、既存ですか。
質問から画面の下書きまで、地の文の画面案を一度も挟まずに進めます。これが狙っている流れです。
家計簿アプリで試して、Skillを直した話
以前、実際に「家計簿アプリを作りたい」という依頼でこのSkillを使いました。5問に答えると、こういう仕事になりました。
When カード請求が確定したとき, I want to カード以外も含めた支払と収入から口座の差額を確定する, so I can 今月の残り（または不足）が分かり、ATMでは口座の差額と手持ちの現金の合算が見られる
出てきた面は3つだけでした。
- 面1 今月の口座の差額（確定の入口と完了）
- 面2 今月の出入りを確定する（カード5枚・家賃・引き落としと収入を揃える）
- 面3 合算を見る（口座の差額と手持ちの現金を足す、ATM前提）
カード5枚、家賃、引き落としといった項目ごとに画面を割ることはしませんでした。面を分けるのは仕事が変わるところだけ、という規律があるためです。分類・予算・共有・年次レポートといった家計簿アプリらしい機能も、仕様にない面として最初から出てきません。
ただ、このセッションには実際につまずきが2つありました。
1つ目は、算出のもとになる数字の名前です。「口座の差額 + 手持ちの現金 = 合算」という式が固まる前に、「入れる金額」という仮の名前で面を進めてしまっていました。式が空のまま名前だけ先に決めると、あとで呼び方がぶれます。
2つ目は、確定作業はパソコン、ATMでの確認はスマホという二端末の扱いです。当時は面を分ける基準が「仕事が変わるところ」としか書かれておらず、端末が変わるだけの場合にどう扱うかが曖昧でした。
この2つのつまずきは、Skillの側の質問項目が足りていなかったことが原因でした。そこでSkill自体を書き直し、次を明示的に追加しています。
- 数字を見て終わる仕事では、仕事を書く段階で「見たい数字は何か、材料は何か、材料はいつ揃うか」を同じターンで聞く。式が空のまま面のコピーや名前を固定しない
- シナリオの「完了後」に、同じ仕事が別の場所・別の端末に残るかを書く。そこで端末や次の一手が変わるなら、そこで面を分ける
自分の使い方でつまずいた場所が、そのまま質問項目としてSkillに戻る格好になりました。
つまずきを数える
既存画面を診断するときは、使いづらさを次の6種類のどれかとして数えます。「なんとなく複雑」で止めません。
| 種別 | 何が増えているか | 典型 |
|---|---|---|
| 決定摩擦 | 選ばなければならないこと | 同等に見えるボタンが並ぶ |
| 入力摩擦 | 今持っていない情報を聞かれること | 任意なのに必須に見える |
| 認知摩擦 | 用語・配置・結果が予想と違うこと | 社内語、アイコンだけ |
| 待ち摩擦 | 何が起きているか分からない待ち | 無言の読込 |
| 回復摩擦 | ミスから仕事へ戻れないこと | 入力が消える |
| 信頼摩擦 | この操作で何が起きるか分からないこと | 破壊的操作なのに軽い |
処方は、足すより先に削るか並べ替えるかです。削るのはその場で仕事に使わない入力や同等の選択肢、並べ替えるのは最初の成功のあとへ設定を送ることです。足すのは、次の一手の指名や回復手段が本当に欠けているときに限ります。
使ってみて気づいたこと
一番効いたのは、仕事を書いた段階で一度止まる強制力でした。画面の役割に進む前にここで止まるので、「カード5枚あるから画面も5つ」のような、データの種類をそのまま画面数にする発想が生まれる前に潰せます。
もうひとつは、状態を画面の役割の時点で埋めてしまうことです。面2には入力中・読込・入力エラー・システムエラー・中断・成功の6状態が最初から並びます。成功画面だけ描いて終わる進め方だと、エラー時に入力が消えるかどうかのような判断は後回しになりがちですが、役割を書く段階で「中断しても入力は残す」まで決まってしまいます。
そして、自分で使ってみて足りなかった部分がSkillの改善に直結したのが大きな収穫でした。数字の仕事や二端末のような、抽象的なルールだけでは拾いきれない具体例を実際に通してみないと、質問項目の穴には気づけません。
まとめ
- 画面から入ると、プロダクトの都合が仕事に見えてしまう
- 質問 → 仕事 → 画面の役割 → 画面の下書き、の順で止まりながら合意を取る
- 面は仕事が変わるところ、または端末が変わるところでだけ分ける
- 数字で終わる仕事は、式と材料が揃うまで面の名前を固定しない
- 実際に使ってつまずいた場所を、そのまま質問項目としてSkillに戻す
参考