今日の問い
画面を作り始める前に、誰の何が良くなるかを一文で言えますか。
30秒でつかむ
UIは接点、UXは利用の前後まで含む体験です。先に決めるのは色やボタンではありません。誰が、どんな状況で、何を前へ進めたいのかです。
この講座では、一つのプロダクトを36回かけて育てます。まず題材を一つ選び、仮の利用者と進歩を書きます。ここでは正解より、あとで確かめられる仮説が大切です。
DESIGN LENS
画面ではなく、人に焦点を合わせる
UIを考える前に、誰が、どんな状況で、何を前へ進めたいのかへ焦点を合わせます。アイコンは装飾ではなく、本文の判断軸をひと目で思い出すための手がかりです。
30秒図解 · LESSON 01
流れ図
接点ではなく、経験全体を見る
UIは体験の一部。UXは利用前から利用後まで続きます。
- 01利用前の期待
- 02画面との接点
- 03目的の達成
- 04利用後の記憶
CLUE · 見抜く手掛かり
画面外の前後を描けているか
TRAP · ありがちな罠
見た目の完成を問題解決と呼ぶ
原則
見栄えの良い画面でも、利用者の目的を外せば使われません。反対に、素朴な画面でも、迷いを減らして目的達成を助ければ価値があります。
Jesse James Garrettは、Webの体験を事業目的と利用者ニーズから捉え、そこから要件や構造、画面へ具体化する枠組みを示しました。表面から考えると理由が後付けになり、目的から考えるとUIの判断に筋が通ります。
EXPERIENCE VIEW
接点の前後まで、一つの体験として見る
予約画面だけでなく、使う前の期待、操作中の迷い、完了後に残る安心までをつなげて見ます。UIはその体験の一部分です。
最初の一文は、次の型で十分です。
「忙しい保護者が、受診前の不安を減らし、相談すべき内容を整理できるようにする」
この段階では、機能名を入れません。「チャットで」「ダッシュボードで」と書くと、解決策に思考が引っ張られるからです。
2つの案を比べ、画面を作る前に行う判断を選んでください。
2つの案を比べ、画面を作る前に行う判断を選んでください。
Webの体験は見た目だけでなく、利用者ニーズと事業目的から一貫して設計するという原則を支える。
良い例と惜しい例
DESIGN DECISION
見た目ではなく、目的への寄与で比べる
良い案と惜しい案の違いは、装飾の完成度ではありません。利用者の進歩を説明できるかで判断します。
最初に定義するもの
惜しい例は実装案で、成功したかを判断しにくい表現です。良い例は利用者、状況、進歩が見えるため、後から複数のUI案を比較できます。
AIへの指示例
目的: 初診の保護者が、必要事項を確認して予約を完了できる体験を定義する
制約: 画面や機能はまだ提案せず、利用者、状況、望む進歩だけを扱う
参照: 現在の予約手順と、現場から聞いた迷いやすい点
受入条件: 「誰が、どんな状況で、何を前へ進めるか」の一文を3案示し、各案の未確認事項を添える
確認問題
セルフチェック
1. 新しい予約体験の設計で、最初に固定すべきものはどれですか。
最終制作へ反映する
MAKE IT REAL
理解したことを、次の行動へ変える
読んで終わらせず、仮の利用者と望む進歩を成果物として残します。次のレッスンから更新できる最初の設計根拠になります。
仮の利用者と進歩
assumed-user.mdを作り、選んだプロダクトについて、利用者、利用状況、望む進歩を一文ずつ書く。
Acceptance criteria
- 特定の利用者と利用状況が書かれている
- 機能名を使わず、利用後に起きてほしい変化が書かれている
今日のまとめ
- UIは接点であり、UXは利用の前後まで含む体験
- 見た目より先に、利用者、状況、望む進歩を仮説にする
- 次は、抽象的な目的を5つの層へつなげる