ユーザーインターフェイス設計の基礎を振り返る / Basics of User Interface Design

インターフェイス設計において、要件定義やデータ構造設計の基礎に焦点を当てた内容です。より長期的にサービスを維持していくために、デザインに取り掛かる前の考え方や基礎についてまとめました。

関連記事：『ナビつき！ つくってわかる はじめてゲームプログラミング』のチュートリアル設計やインターフェイスデザインの気付き
https://yuyakinoshita.com/blog/2021/06/14/learning-from-tutorial-design-gbg/

----
Website: https://yuyakinoshita.com
Twitter: https://twitter.com/yuyaink

Transcript

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