Slide 1
Slide 1 text
No content
Slide 2
Slide 2 text
⽊下 裕哉
Yuya Kinoshita
デザイナー
フロントエンドエンジニア
yuyakinoshita.com
@yuyaink
Slide 3
Slide 3 text
はじめに
Slide 4
Slide 4 text
この資料のゴール
ユーザーインターフェイス設計の基礎について
振り返りのきっかけとなること
Slide 5
Slide 5 text
さらなる狙い
根拠を元にして
デザインを進められるようになること
Slide 6
Slide 6 text
主な対象者
Webサイト、アプリなどの
ユーザーインターフェイス設計に関わる⽅
UIデザイナー、フロントエンドエンジニア、ディレクターなど。
Slide 7
Slide 7 text
ユーザーインターフェイス設計について
•気付いたこと・考えたこと
•いただいた質問への回答
•チームメンバーにお伝えしていること
など、繰り返しブログやTwitterで発信している基礎部分を抜粋しました。
Slide 8
Slide 8 text
この資料では、
表層よりも構造に焦点を当てています。
Slide 9
Slide 9 text
内容は覚えなくて⼤丈夫です
Slide 10
Slide 10 text
何かに迷ったときの振り返り
のきっかけとしていただけた
ら幸いです。
Slide 11
Slide 11 text
Index 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
デザインの統⼀感、拡張性、耐久性
トーン&マナーを統⼀する
コンテンツをわかりやすく届けるデザインを意識する
要件ではなく⽬的の段階から関わる
ユーザーは全ての機能を使いたいわけではない
データ構造の初期設計が重要
⼀般的なユーザーインターフェイスの挙動と⽐べる
ユーザーの記憶⼒に依存しない
要素を増やすときこそ慎重に
要件定義で意識したい3つのこと
Slide 12
Slide 12 text
デザインの統⼀感、拡張性、耐久性
1
Slide 13
Slide 13 text
ユーザーにとってわかりやすい、使いやすい、
⻑期的に利便性が⾼い状態にするためにはどう
れば良いのか？ 必要になりそうな条件につい
て、観点を考えてみます。
Slide 14
Slide 14 text
例えばこんなことがありそう？
•デザインや使⽤感が統⼀されているか？
•ユーザーが学習したことを活かせるか？
•要素の増減に耐えられる構造になっているか？
構造の例：データ構造、コンポーネント設計、レイアウトなど。
Slide 15
Slide 15 text
例えばレイアウトで意識すること
Slide 16
Slide 16 text
データ数が増減しても成り⽴
つかを想定して設計を進めて
いくと、拡張性や耐久性を⾼
めやすくなります。
?
Slide 17
Slide 17 text
例えばデータが1個の場合、10個の場合、100
個の場合、1000個の場合、0個の場合に表⽰
（レイアウト）が成⽴するかを考えます。
. . .
Slide 18
Slide 18 text
データが0個の場合の例
Slide 19
Slide 19 text
Finder（macOS）
リスト表⽰の場合、項⽬数が
0個でも、ファイル名、変更
⽇、サイズ、種類などの欄の
⾒出しが表⽰されます（設定
により変わります）。
Slide 20
Slide 20 text
ファイル（iPadOS）
フォルダ内に存在するファイ
ルの項⽬数とiCloudの空き
容量が表⽰されています。
Slide 21
Slide 21 text
Googleドライブ
フォルダ内にファイルが存在
しない場合は、ユーザーの⾏
動を促すデザインが⽤いられ
ています。
•⽬を引くアイコン
•具体的なアクションを明⽰
•補⾜情報を併記
Slide 22
Slide 22 text
「データがまだ存在しないこと」と「この画⾯
で何をしたら良いか」を明確にします。
エンプティステートの例
Slide 23
Slide 23 text
初めてサービスを使う場合や存在するデータを
全て削除した場合など、データが0個になる状況
はあります。
データが0個の場合を想定しておくことで、ユーザーにとってより親切な情報
設計に近付くと考えています。
Slide 24
Slide 24 text
トーン&マナーを統⼀する
2
Slide 25
Slide 25 text
配⾊、余⽩、タイポグラフィ、インタラクショ
ンなどを含めた世界観（そのサービスや製品ら
しさ）を構成する要素と解釈しています。
トーン&マナーとは？
Slide 26
Slide 26 text
トーン&マナーを守るのはなぜ？
Slide 27
Slide 27 text
秩序を維持するためです。
Slide 28
Slide 28 text
統⼀感のあるデザインが維持
されることで違和感が少なく
なり、ユーザーが内容に集中
しやすくなると考えます。
Slide 29
Slide 29 text
トーン&マナーが統⼀されていないとどうなる？
Slide 30
Slide 30 text
トーン&マナーが守られない場合のデメリット
•デザインがバラバラな印象になる
•ページによって⾊の意味が変わり誤解しやすい
•ユーザーの集中⼒低下や不信感につながる
Slide 31
Slide 31 text
統⼀したトーン&マナーで全体を設計する
（デザインシステムの構築も1つの⼿段）
改善するには？
Slide 32
Slide 32 text
例えば
•配⾊ルールを統⼀する（使う⾊数を絞る）
•余⽩の⼤きさにルールを設ける（数を絞る）
•⽂字サイズのルールを設ける（数を絞る）
要素の数を絞り、限定していくことで秩序が維持されます。
Slide 33
Slide 33 text
要素を絞るばかりで表現⼒は下がらないの？
絞ってばかりだけど
Slide 34
Slide 34 text
表現⼒を維持できる場⾯のほうが多いと考えま
す。デザインに必要な表現⼒を維持した状態で
ユーザーにとってよりわかりやすくなり、メリ
ットがデメリットを上回ると判断しています。
要素を絞るばかりで表現⼒は下がらない？
Slide 35
Slide 35 text
経験則ですが、広告的な表現が求められる場合
であっても配⾊、余⽩、タイポグラフィのルー
ルを設計したほうがより良くなると考えます。
広告的な側⾯が強い場合でも？
ダイナミックな表現や崩しの表現が効果的なデザインでも、⼟台のデザインに
は秩序が重要だと考えています。
Slide 36
Slide 36 text
特にWebサイトやアプリケーションなど、繰り
返し使う道具としての側⾯が強いユーザーイン
ターフェイス設計では、デザインルールをエンジ
ニアリングに浸透する必要性が⾼まります。
そのため、より細かくルール化・仕組み化します。
Slide 37
Slide 37 text
コンテンツをわかりやすく届ける
デザインを意識する
3
Slide 38
Slide 38 text
コンテンツが主役
道具としてのユーザーインターフェイスの考え⽅
Slide 39
Slide 39 text
多くの場⾯でコンテンツが主役であり、ユーザ
ーインターフェイス（UI）はユーザーにコンテ
ンツを届けるための⼿段だと考えます。
コンテンツが主役
Slide 40
Slide 40 text
コンテンツとは具体的にどんなもの？
Slide 41
Slide 41 text
メインコンテンツ
サブコンテンツ
メインコンテンツを構成する要素
•動画
•関連動画
•動画ファイル（内容）
•サムネイル画像
•動画タイトル
•投稿者・概要欄テキスト
•コメント
YouTube
Slide 42
Slide 42 text
メインコンテンツ
サブコンテンツ
メインコンテンツを構成する要素
•商品
•関連商品リンク
•サムネイル画像
•商品名
•価格
•商品の詳細情報
•レビュー評価・コメント
Amazon
Slide 43
Slide 43 text
メインコンテンツ
メインコンテンツを構成する要素
サブコンテンツ
•記事
•記事本⽂（内容）
•記事タイトル
•サムネイル画像
•本⽂内の画像・動画
•コメント
•関連記事リンク
ブログ
Slide 44
Slide 44 text
サービスで提供するメインコンテンツは？
UIはユーザーにコンテンツを届けるための⼿段だと考えています。
•YouTubeなら動画
•Amazonなら商品
•ブログなら記事
Slide 45
Slide 45 text
コンテンツを活かす（わかり
やすく届ける）デザインが適
していることが多いのではな
いでしょうか。
デジタルを主体としたUIデザインでは
Slide 46
Slide 46 text
例えばどんな⽅法がある？
•シンプルなUIでコンテンツに注⽬しやすくする
•⽬的のコンテンツにたどり着きやすい導線に
•オブジェクト指向で設計し、拡張性を持たせる
メインコンテンツが何なのかを明確にすると、優先度を決めやすくなります。
Slide 47
Slide 47 text
要件ではなく⽬的の段階から関わる
（デザイナーが仕様設計にも関わる）
4
Slide 48
Slide 48 text
要件の前段の⽬的や要望を丁
寧に聞いたうえで、⻑期的に
何をどのようにすれば良いか
を考える（仕様を設計する）
ことが重要だと考えます。
Slide 49
Slide 49 text
なぜ要件ではなく
「⽬的や要望」を知りたいのか？
Slide 50
Slide 50 text
なぜ要件ではなく「⽬的や要望」を知りたいのか？
•根本的な問題解決への提案の質を⾼めるため
•⻑期的な視点での解決⽅法を提案しやすいため
•要望の段階で関わるほうが打ち⼿が多いため
要望の段階から関わることで、より根本的な解決策を提案しやすくなります。
Slide 51
Slide 51 text
なぜ⻑期的に考えるのか？
Slide 52
Slide 52 text
⻑期的な品質向上の観点でつくりあげていくこ
とで、ユーザーとサービス提供者の両⽅のメリ
ットが持続すると考えるからです。
なぜ⻑期的に考えるのか？
Slide 53
Slide 53 text
⻑期的な品質向上の観点とは？
3つ挙げてみます。
Slide 54
Slide 54 text
機能を増やさず、ユーザーにとってより良い価
値を提供できる⽅法があるかもしれない。
1
運⽤⽅法を変える、今あるものを磨く、情報を整理してシンプルにする、優先
度の低い要素を減らすなど、機能を増やす前にできることを考えてみます。
Slide 55
Slide 55 text
ビジネス要件、システム要件、インターフェイス
の使いやすさのバランスを維持するには？
2
⻑期的な視点でユーザーのための設計になっているかを検証します。仕様設計
から関わることで、複合的な改善点が⾒つかりやすくなります。
Slide 56
Slide 56 text
やろうとしていることがユーザーの希望からず
れていて、やらないほうが良いかもしれない。
3
そもそも何のためにやろうとしているのかを振り返ることで、全く違う解決
⽅法が⾒つかる可能性があります。特に機能を増やす検討をしている場合に。
Slide 57
Slide 57 text
横断した設計を意識する
役割によって担当範囲は変わる場合もありますが、デザイナーが複数の要件を
横断して設計することで⼀貫性を維持しやすくなると考えます。
戦略 要件
⽬的 構造 表層 運⽤
Slide 58
Slide 58 text
ユーザーは
全ての機能を使いたいわけではない
5
Slide 59
Slide 59 text
娯楽ではない限り、ほとんど
のユーザーはやりたいことを
最⼩の労⼒かつ最短でできる
ことを望んでいるのではない
でしょうか？
Slide 60
Slide 60 text
ユーザーは「これを使ったら
何となくできそう？」という
期待や予想、疑念の元にサー
ビスやソフトウェアを使って
いるのでは？
?
?
?
?
どうすればいいんだろう…？
これでいいのかな…？
Slide 61
Slide 61 text
その期待や予想、疑念に対し
てわかりやすくサポートでき
ることも価値だと考えます。
わかりやすい！
これならできそう！
Slide 62
Slide 62 text
例えば
•よく使う機能はアクセスしやすく設計する
•よりわかりやすい⾔葉で表現する
•誤解を招く表現を避けて選びやすくする
⼩さなことを丁寧に積み重ねることで、よりわかりやすい表現に近付きます。
Slide 63
Slide 63 text
ユーザーの決断⼒や労⼒の消耗をどれだけ減ら
せるかも意識したいです。例えばわかりやすい
初期状態（Default State）を考えるのも1つ
の改善です。
具体例は第1章のデータが0個の場合の例をご参照ください。
Slide 64
Slide 64 text
チュートリアル設計のおすすめ参考教材
Slide 65
Slide 65 text
引⽤元：
ナビつき！ つくってわかる はじめてゲームプログ
ラミング（Nintendo）
Slide 66
Slide 66 text
特に良いと思ったところ
•1つ1つの操作をハイライト表⽰して、親切にわかりやすくナビしてくれる。
•優しくわかりやすい⾔葉で表現。
•すごく褒めてくれる。
•おさらいの機会がある。
•恐らくオブジェクト指向による設計。
•⼊⼒⽅法が複数⽤意してある。
•⼼地良い操作性を追求。
•ユーザーが成⻑できる仕組みや考え⽅を教えてくれる。
Slide 67
Slide 67 text
詳しくはブログにまとめました
『ナビつき！ つくってわかる はじめてゲームプログラミング』の
チュートリアル設計やインターフェイスデザインの気付き
Slide 68
Slide 68 text
データ構造の初期設計が重要
6
Slide 69
Slide 69 text
サービス運⽤後の根本部分の
変更は影響範囲が広く、既存
ユーザーへ負担を強いること
になってしまいます。そのた
め初期設計が重要です。
Slide 70
Slide 70 text
初期設計が不⼗分な場合のデメリット
•機能の追加や編集が困難になる
•改善やメンテナンスがしづらく、無駄が多い
•⻑期的な拡張性が無く、作り直しが多発する
Slide 71
Slide 71 text
⻑期的な運⽤を前提に設計する
改善するには？
Slide 72
Slide 72 text
•データへのアクセス導線や双⽅向性の維持
•⼀元管理化
•共通コンポーネント化
意識したいこと
⻑期的に再編集・メンテナンスのしやすい構造を意識して設計したいです。
Slide 73
Slide 73 text
例：データへのアクセス⽅法を考える場合
•編集や削除のしやすさをどう維持するか？
•データの検索条件（Key）を何にするか?
•データの並び順をどうするか?
Slide 74
Slide 74 text
ユーザーによるデータへのアクセスのしやすさ
をどう設計するか、この点もデザイナーが意識
しておきたいと考えています。
Slide 75
Slide 75 text
⼀般的なユーザーインターフェイスの
挙動と⽐較する
7
Slide 76
Slide 76 text
macOS、Windows、iOS、iPadOSなどの
OS標準のユーザーインターフェイスやインタラ
クションも参考にします。
新機能のユーザーインターフェイスを設計する前に
Slide 77
Slide 77 text
操作性や使⽤感の標準を把握するため
それはなぜか？
ユーザーは何らかのOSに触れている可能性が⾼いと考えており、ユーザーが
使い慣れた操作性や使⽤感を知ることにも意味があると考えます。
Slide 78
Slide 78 text
例えば
•どこからデータを変更できるか
•アニメーションは何秒程度か
•データに対してどんなアクションが取れるか
こういったことを参考にしています。
Slide 79
Slide 79 text
⼀般的なインタラクションとかけ離れている場合のデメリット
•ユーザーが予想した挙動と異なり不安になる
•操作が完了したのかわからない
•UIに触れることがストレスになる
OS標準のUIに近い⾒た⽬で違う挙動なら、ストレスにつながると考えます。
Slide 80
Slide 80 text
まずはデータの流れの基本を知る
（共通の基本要素を抑える）
意識するポイントは？
Slide 81
Slide 81 text
データのアクションは作成、読み出し、変更、
削除の4つが基本であり、ユーザーがそれらのア
クションを⼿軽におこなえるように設計するこ
とが重要だと考えます。
Slide 82
Slide 82 text
データの基本アクション
•作成（Create）
•読み出し（Read）
•変更（Update）
•削除（Delete）
Data
Create
Update Delete
Read
4つの頭⽂字からCRUDとも
呼ばれるようです。
Slide 83
Slide 83 text
そのためデータに対するそれらのアクション、
データ構造、導線、インタラクションなどが使
いやすく⼼地の良いものになっているかを注意
して検証します。
※データ構造については次回の資料で深堀りする予定です。
Slide 84
Slide 84 text
ユーザーの記憶⼒に依存しない
8
Slide 85
Slide 85 text
ユーザーの記憶⼒に依存するデメリット
•必要な情報を同⼀のウィンドウ内で⾒られない
•不必要な画⾯遷移をしなければならない
•ユーザーの集中⼒や決断⼒を消耗させる
ユーザーへの不要なストレスによって、双⽅の機会損失につながってしまう。
Slide 86
Slide 86 text
ユーザーの記憶⼒に配慮した
ユーザーインターフェイスとは？
WordPressの記事⼊⼒ページを例に⾒てみます。
Slide 87
Slide 87 text
WordPress
WordPressの記事⼊⼒ペー
ジの右側には、記事情報を確
認・編集できる投稿情報エリ
アがあります。例えば次の要
素の確認・編集できます。
•URL
•公開⽇時
•カテゴリー
•アイキャッチ画像
•タグ
Slide 88
Slide 88 text
右側の投稿情報エリアを詳細ページで
表⽰できなかったとしたらどうなるか？
Slide 89
Slide 89 text
ページを何度も⾏き来することに…
記事編集ページ 記事⼀覧ページ
Slide 90
Slide 90 text
ユーザーの負担を減らす⽅法を考える
改善するには？
Slide 91
Slide 91 text
ユーザーが記憶しなくても情
報へアクセスしやすいように
する。
例：確認画⾯で⼊⼒済みの情報を表⽰する。
Slide 92
Slide 92 text
ユーザーがシステムの仕様や
構造などの前提知識を持たな
くても操作できること。
例：ボタンを押したときの挙動を予測できる。
Slide 93
Slide 93 text
ユーザーが操作できるように
なるための知識をその場から
学べる。
例：フォームに⼊⼒例を表⽰する。
Slide 94
Slide 94 text
特に⼊⼒フォーム画⾯では、「ユーザーが前の
画⾯の情報を覚えておく」という状態を避けら
れる情報設計や画⾯構成にすると、ユーザーの
負荷を減らせます。
Slide 95
Slide 95 text
要素を増やすときこそ慎重に
9
Slide 96
Slide 96 text
要素を増えすときこそ慎重に
レイアウトを検証したほうが
良いと考えます。
特にアプリケーションのユーザーインターフェイ
ス設計の場合。
Slide 97
Slide 97 text
なぜ要素を増やすときに慎重に検証するの？
⻑期的な負債になりやすい
デメリットが潜んでいるから
Slide 98
Slide 98 text
短期的な視点で要素を増やすことのデメリット
•1度増やした要素は簡単には削除できない
•不要な要素がどんどん増えていってしまう
•結果的にユーザー全体にとって不便になる
⼀部ユーザーからの要望機能が、多くのユーザーからは不要ということも。
Slide 99
Slide 99 text
特にボタンが増えるときにはアプリケーション
全体の整合性、画⾯が変わったときの他のボタ
ンやテキストと整合性にも影響するためです。
Create Edit Delete New?
?
Slide 100
Slide 100 text
今ある要素の場所を変えると、ユーザーに再学
習を強いてしまいます。操作に慣れているユー
ザーほど変化へのストレスが⾼いはずです。
?
?
?
?
Slide 101
Slide 101 text
要素増やしたいと思ったとき
こそ、本当にその要素を追加
するべきなのかどうかを慎重
に検討したいです。
Must?
Need
Simple?
For User?
Slide 102
Slide 102 text
要件定義で意識したい3つのこと
10
Slide 103
Slide 103 text
ユーザーにとってよりわかり
やすいサービスやユーザーイ
ンターフェイスに近付くよう
に、要件定義では次の3つの
ことを特に意識したいです。
Slide 104
Slide 104 text
疑問に思ったことは⾃分が納得できるまで仮説
と検証を繰り返して、明らかにする。
1
設計するデザイナーが意図のわからない要素や概念をユーザーが理解できる可
能性は低いです。何も知らないユーザーの視点を意識して検証したいです。
Slide 105
Slide 105 text
ユーザーにとってわかりやすい設計になってい
るかの問いを繰り返す。
2
サービス提供側の事情はユーザーにとって無関係です。客観的にユーザーにと
って親切でわかりやすい設計になっているかの検証を繰り返したいです。例え
ばユーザーはサービス提供側の通称⽤語、専⾨⽤語を知りません。
Slide 106
Slide 106 text
仕様、データ構造、導線などが、⼀般的なシス
テム仕様に沿っているかを確認する。
3
独⾃のシステムになればなるほどユーザーにとって使いにくくなっている可能
性が⾼いです。ネイティブOSのシステム仕様を知ることも参考になります。
Slide 107
Slide 107 text
デザイナーが
エンジニアリングに触れるメリット
Slide 108
Slide 108 text
余談ですが、デザイナーがエンジニアリングに
触れるメリットとして⼤きく次の3点があるよう
に思います。
Slide 109
Slide 109 text
データ構造について考える機会、触れる機会が
増える。データベースを取り扱うことで、データ
の⼊出⼒を考えて設計できるようになる。
1
データをどのようにユーザーに届けるかの観点が養われると考えます。
Slide 110
Slide 110 text
⻑期的に耐久性のある、システムとして⻑持ち
するデザインの予想がしやすくなる。
2
メンテナンスがしやすいデザイン表現が体感的に⾝につきやすくなると考え
ます。コードでメンテナンスしやすいデザインは⻑持ちしやすい印象です。
Slide 111
Slide 111 text
エンジニアリングの観点を組み合わせた解決⽅
法を思い付きやすくなる。
3
感覚的なものになりますが、ユーザーの使いやすさとシステム的な実現性の組
み合わせから解決⽅法に気付きやすくなる⾯があるのではと感じます。例えば
データ構造、データ属性、情報の取得先、速度の制約の観点など。
Slide 112
Slide 112 text
この資料で重要な
3ポイントをおさらい
Slide 113
Slide 113 text
データ数が増減しても成り⽴
つかを想定して設計を進めて
いくと、拡張性や耐久性を⾼
めやすくなります。
?
Slide 114
Slide 114 text
データの基本アクション
•作成（Create）
•読み出し（Read）
•変更（Update）
•削除（Delete）
Data
Create
Update Delete
Read
4つの頭⽂字からCRUDとも
呼ばれるようです。
Slide 115
Slide 115 text
要素増やしたいと思ったとき
こそ、本当にその要素を追加
するべきなのかどうかを慎重
に検討したいです。
Must?
Need
Simple?
For User?
Slide 116
Slide 116 text
最後に
この資料がユーザーインターフェイス設計の振
り返りとして、お役に⽴てたら幸いです。
Slide 117
Slide 117 text
ありがとうございました