ユーザーインターフェイス設計の基礎を振り返る / 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

1. View Slide

2. ⽊下 裕哉
   Yuya Kinoshita
   デザイナー
   フロントエンドエンジニア
   yuyakinoshita.com
   @yuyaink
   

   View Slide

3. はじめに
   

   View Slide

4. この資料のゴール
   ユーザーインターフェイス設計の基礎について
   振り返りのきっかけとなること
   

   View Slide

5. さらなる狙い
   根拠を元にして
   デザインを進められるようになること
   

   View Slide

6. 主な対象者
   Webサイト、アプリなどの
   ユーザーインターフェイス設計に関わる⽅
   UIデザイナー、フロントエンドエンジニア、ディレクターなど。
   

   View Slide

7. ユーザーインターフェイス設計について
   •気付いたこと・考えたこと
   •いただいた質問への回答
   •チームメンバーにお伝えしていること
   など、繰り返しブログやTwitterで発信している基礎部分を抜粋しました。
   

   View Slide

8. この資料では、
   表層よりも構造に焦点を当てています。
   

   View Slide

9. 内容は覚えなくて⼤丈夫です
   

   View Slide

10. 何かに迷ったときの振り返り
    のきっかけとしていただけた
    ら幸いです。
    

    View Slide

11. Index 1.
    2.
    3.
    4.
    5.
    6.
    7.
    8.
    9.
    10.
    デザインの統⼀感、拡張性、耐久性
    トーン&マナーを統⼀する
    コンテンツをわかりやすく届けるデザインを意識する
    要件ではなく⽬的の段階から関わる
    ユーザーは全ての機能を使いたいわけではない
    データ構造の初期設計が重要
    ⼀般的なユーザーインターフェイスの挙動と⽐べる
    ユーザーの記憶⼒に依存しない
    要素を増やすときこそ慎重に
    要件定義で意識したい3つのこと
    

    View Slide

12. デザインの統⼀感、拡張性、耐久性
    1
    

    View Slide

13. ユーザーにとってわかりやすい、使いやすい、
    ⻑期的に利便性が⾼い状態にするためにはどう
    れば良いのか？ 必要になりそうな条件につい
    て、観点を考えてみます。
    

    View Slide

14. 例えばこんなことがありそう？
    •デザインや使⽤感が統⼀されているか？
    •ユーザーが学習したことを活かせるか？
    •要素の増減に耐えられる構造になっているか？
    構造の例：データ構造、コンポーネント設計、レイアウトなど。
    

    View Slide

15. 例えばレイアウトで意識すること
    

    View Slide

16. データ数が増減しても成り⽴
    つかを想定して設計を進めて
    いくと、拡張性や耐久性を⾼
    めやすくなります。
    ?
    

    View Slide

17. 例えばデータが1個の場合、10個の場合、100
    個の場合、1000個の場合、0個の場合に表⽰
    （レイアウト）が成⽴するかを考えます。
    . . .
    

    View Slide

18. データが0個の場合の例
    

    View Slide

19. Finder（macOS）
    リスト表⽰の場合、項⽬数が
    0個でも、ファイル名、変更
    ⽇、サイズ、種類などの欄の
    ⾒出しが表⽰されます（設定
    により変わります）。
    

    View Slide

20. ファイル（iPadOS）
    フォルダ内に存在するファイ
    ルの項⽬数とiCloudの空き
    容量が表⽰されています。
    

    View Slide

21. Googleドライブ
    フォルダ内にファイルが存在
    しない場合は、ユーザーの⾏
    動を促すデザインが⽤いられ
    ています。
    •⽬を引くアイコン
    •具体的なアクションを明⽰
    •補⾜情報を併記
    

    View Slide

22. 「データがまだ存在しないこと」と「この画⾯
    で何をしたら良いか」を明確にします。
    エンプティステートの例
    

    View Slide

23. 初めてサービスを使う場合や存在するデータを
    全て削除した場合など、データが0個になる状況
    はあります。
    データが0個の場合を想定しておくことで、ユーザーにとってより親切な情報
    設計に近付くと考えています。
    

    View Slide

24. トーン&マナーを統⼀する
    2
    

    View Slide

25. 配⾊、余⽩、タイポグラフィ、インタラクショ
    ンなどを含めた世界観（そのサービスや製品ら
    しさ）を構成する要素と解釈しています。
    トーン&マナーとは？
    

    View Slide

26. トーン&マナーを守るのはなぜ？
    

    View Slide

27. 秩序を維持するためです。
    

    View Slide

28. 統⼀感のあるデザインが維持
    されることで違和感が少なく
    なり、ユーザーが内容に集中
    しやすくなると考えます。
    

    View Slide

29. トーン&マナーが統⼀されていないとどうなる？
    

    View Slide

30. トーン&マナーが守られない場合のデメリット
    •デザインがバラバラな印象になる
    •ページによって⾊の意味が変わり誤解しやすい
    •ユーザーの集中⼒低下や不信感につながる
    

    View Slide

31. 統⼀したトーン&マナーで全体を設計する
    （デザインシステムの構築も1つの⼿段）
    改善するには？
    

    View Slide

32. 例えば
    •配⾊ルールを統⼀する（使う⾊数を絞る）
    •余⽩の⼤きさにルールを設ける（数を絞る）
    •⽂字サイズのルールを設ける（数を絞る）
    要素の数を絞り、限定していくことで秩序が維持されます。
    

    View Slide

33. 要素を絞るばかりで表現⼒は下がらないの？
    絞ってばかりだけど
    

    View Slide

34. 表現⼒を維持できる場⾯のほうが多いと考えま
    す。デザインに必要な表現⼒を維持した状態で
    ユーザーにとってよりわかりやすくなり、メリ
    ットがデメリットを上回ると判断しています。
    要素を絞るばかりで表現⼒は下がらない？
    

    View Slide

35. 経験則ですが、広告的な表現が求められる場合
    であっても配⾊、余⽩、タイポグラフィのルー
    ルを設計したほうがより良くなると考えます。
    広告的な側⾯が強い場合でも？
    ダイナミックな表現や崩しの表現が効果的なデザインでも、⼟台のデザインに
    は秩序が重要だと考えています。
    

    View Slide

36. 特にWebサイトやアプリケーションなど、繰り
    返し使う道具としての側⾯が強いユーザーイン
    ターフェイス設計では、デザインルールをエンジ
    ニアリングに浸透する必要性が⾼まります。
    そのため、より細かくルール化・仕組み化します。
    

    View Slide

37. コンテンツをわかりやすく届ける
    デザインを意識する
    3
    

    View Slide

38. コンテンツが主役
    道具としてのユーザーインターフェイスの考え⽅
    

    View Slide

39. 多くの場⾯でコンテンツが主役であり、ユーザ
    ーインターフェイス（UI）はユーザーにコンテ
    ンツを届けるための⼿段だと考えます。
    コンテンツが主役
    

    View Slide

40. コンテンツとは具体的にどんなもの？
    

    View Slide

41. メインコンテンツ
    サブコンテンツ
    メインコンテンツを構成する要素
    •動画
    •関連動画
    •動画ファイル（内容）
    •サムネイル画像
    •動画タイトル
    •投稿者・概要欄テキスト
    •コメント
    YouTube
    

    View Slide

42. メインコンテンツ
    サブコンテンツ
    メインコンテンツを構成する要素
    •商品
    •関連商品リンク
    •サムネイル画像
    •商品名
    •価格
    •商品の詳細情報
    •レビュー評価・コメント
    Amazon
    

    View Slide

43. メインコンテンツ
    メインコンテンツを構成する要素
    サブコンテンツ
    •記事
    •記事本⽂（内容）
    •記事タイトル
    •サムネイル画像
    •本⽂内の画像・動画
    •コメント
    •関連記事リンク
    ブログ
    

    View Slide

44. サービスで提供するメインコンテンツは？
    UIはユーザーにコンテンツを届けるための⼿段だと考えています。
    •YouTubeなら動画
    •Amazonなら商品
    •ブログなら記事
    

    View Slide

45. コンテンツを活かす（わかり
    やすく届ける）デザインが適
    していることが多いのではな
    いでしょうか。
    デジタルを主体としたUIデザインでは
    

    View Slide

46. 例えばどんな⽅法がある？
    •シンプルなUIでコンテンツに注⽬しやすくする
    •⽬的のコンテンツにたどり着きやすい導線に
    •オブジェクト指向で設計し、拡張性を持たせる
    メインコンテンツが何なのかを明確にすると、優先度を決めやすくなります。
    

    View Slide

47. 要件ではなく⽬的の段階から関わる
    （デザイナーが仕様設計にも関わる）
    4
    

    View Slide

48. 要件の前段の⽬的や要望を丁
    寧に聞いたうえで、⻑期的に
    何をどのようにすれば良いか
    を考える（仕様を設計する）
    ことが重要だと考えます。
    

    View Slide

49. なぜ要件ではなく
    「⽬的や要望」を知りたいのか？
    

    View Slide

50. なぜ要件ではなく「⽬的や要望」を知りたいのか？
    •根本的な問題解決への提案の質を⾼めるため
    •⻑期的な視点での解決⽅法を提案しやすいため
    •要望の段階で関わるほうが打ち⼿が多いため
    要望の段階から関わることで、より根本的な解決策を提案しやすくなります。
    

    View Slide

51. なぜ⻑期的に考えるのか？
    

    View Slide

52. ⻑期的な品質向上の観点でつくりあげていくこ
    とで、ユーザーとサービス提供者の両⽅のメリ
    ットが持続すると考えるからです。
    なぜ⻑期的に考えるのか？
    

    View Slide

53. ⻑期的な品質向上の観点とは？
    3つ挙げてみます。
    

    View Slide

54. 機能を増やさず、ユーザーにとってより良い価
    値を提供できる⽅法があるかもしれない。
    1
    運⽤⽅法を変える、今あるものを磨く、情報を整理してシンプルにする、優先
    度の低い要素を減らすなど、機能を増やす前にできることを考えてみます。
    

    View Slide

55. ビジネス要件、システム要件、インターフェイス
    の使いやすさのバランスを維持するには？
    2
    ⻑期的な視点でユーザーのための設計になっているかを検証します。仕様設計
    から関わることで、複合的な改善点が⾒つかりやすくなります。
    

    View Slide

56. やろうとしていることがユーザーの希望からず
    れていて、やらないほうが良いかもしれない。
    3
    そもそも何のためにやろうとしているのかを振り返ることで、全く違う解決
    ⽅法が⾒つかる可能性があります。特に機能を増やす検討をしている場合に。
    

    View Slide

57. 横断した設計を意識する
    役割によって担当範囲は変わる場合もありますが、デザイナーが複数の要件を
    横断して設計することで⼀貫性を維持しやすくなると考えます。
    戦略 要件
    ⽬的 構造 表層 運⽤
    

    View Slide

58. ユーザーは
    全ての機能を使いたいわけではない
    5
    

    View Slide

59. 娯楽ではない限り、ほとんど
    のユーザーはやりたいことを
    最⼩の労⼒かつ最短でできる
    ことを望んでいるのではない
    でしょうか？
    

    View Slide

60. ユーザーは「これを使ったら
    何となくできそう？」という
    期待や予想、疑念の元にサー
    ビスやソフトウェアを使って
    いるのでは？
    ?
    ?
    ?
    ?
    どうすればいいんだろう…？
    これでいいのかな…？
    

    View Slide

61. その期待や予想、疑念に対し
    てわかりやすくサポートでき
    ることも価値だと考えます。
    わかりやすい！
    これならできそう！
    

    View Slide

62. 例えば
    •よく使う機能はアクセスしやすく設計する
    •よりわかりやすい⾔葉で表現する
    •誤解を招く表現を避けて選びやすくする
    ⼩さなことを丁寧に積み重ねることで、よりわかりやすい表現に近付きます。
    

    View Slide

63. ユーザーの決断⼒や労⼒の消耗をどれだけ減ら
    せるかも意識したいです。例えばわかりやすい
    初期状態（Default State）を考えるのも1つ
    の改善です。
    具体例は第1章のデータが0個の場合の例をご参照ください。
    

    View Slide

64. チュートリアル設計のおすすめ参考教材
    

    View Slide

65. 引⽤元：
    ナビつき！ つくってわかる はじめてゲームプログ
    ラミング（Nintendo）
    

    View Slide

66. 特に良いと思ったところ
    •1つ1つの操作をハイライト表⽰して、親切にわかりやすくナビしてくれる。
    •優しくわかりやすい⾔葉で表現。
    •すごく褒めてくれる。
    •おさらいの機会がある。
    •恐らくオブジェクト指向による設計。
    •⼊⼒⽅法が複数⽤意してある。
    •⼼地良い操作性を追求。
    •ユーザーが成⻑できる仕組みや考え⽅を教えてくれる。
    

    View Slide

67. 詳しくはブログにまとめました
    『ナビつき！ つくってわかる はじめてゲームプログラミング』の
    チュートリアル設計やインターフェイスデザインの気付き
    

    View Slide

68. データ構造の初期設計が重要
    6
    

    View Slide

69. サービス運⽤後の根本部分の
    変更は影響範囲が広く、既存
    ユーザーへ負担を強いること
    になってしまいます。そのた
    め初期設計が重要です。
    

    View Slide

70. 初期設計が不⼗分な場合のデメリット
    •機能の追加や編集が困難になる
    •改善やメンテナンスがしづらく、無駄が多い
    •⻑期的な拡張性が無く、作り直しが多発する
    

    View Slide

71. ⻑期的な運⽤を前提に設計する
    改善するには？
    

    View Slide

72. •データへのアクセス導線や双⽅向性の維持
    •⼀元管理化
    •共通コンポーネント化
    意識したいこと
    ⻑期的に再編集・メンテナンスのしやすい構造を意識して設計したいです。
    

    View Slide

73. 例：データへのアクセス⽅法を考える場合
    •編集や削除のしやすさをどう維持するか？
    •データの検索条件（Key）を何にするか?
    •データの並び順をどうするか?
    

    View Slide

74. ユーザーによるデータへのアクセスのしやすさ
    をどう設計するか、この点もデザイナーが意識
    しておきたいと考えています。
    

    View Slide

75. ⼀般的なユーザーインターフェイスの
    挙動と⽐較する
    7
    

    View Slide

76. macOS、Windows、iOS、iPadOSなどの
    OS標準のユーザーインターフェイスやインタラ
    クションも参考にします。
    新機能のユーザーインターフェイスを設計する前に
    

    View Slide

77. 操作性や使⽤感の標準を把握するため
    それはなぜか？
    ユーザーは何らかのOSに触れている可能性が⾼いと考えており、ユーザーが
    使い慣れた操作性や使⽤感を知ることにも意味があると考えます。
    

    View Slide

78. 例えば
    •どこからデータを変更できるか
    •アニメーションは何秒程度か
    •データに対してどんなアクションが取れるか
    こういったことを参考にしています。
    

    View Slide

79. ⼀般的なインタラクションとかけ離れている場合のデメリット
    •ユーザーが予想した挙動と異なり不安になる
    •操作が完了したのかわからない
    •UIに触れることがストレスになる
    OS標準のUIに近い⾒た⽬で違う挙動なら、ストレスにつながると考えます。
    

    View Slide

80. まずはデータの流れの基本を知る
    （共通の基本要素を抑える）
    意識するポイントは？
    

    View Slide

81. データのアクションは作成、読み出し、変更、
    削除の4つが基本であり、ユーザーがそれらのア
    クションを⼿軽におこなえるように設計するこ
    とが重要だと考えます。
    

    View Slide

82. データの基本アクション
    •作成（Create）
    •読み出し（Read）
    •変更（Update）
    •削除（Delete）
    Data
    Create
    Update Delete
    Read
    4つの頭⽂字からCRUDとも
    呼ばれるようです。
    

    View Slide

83. そのためデータに対するそれらのアクション、
    データ構造、導線、インタラクションなどが使
    いやすく⼼地の良いものになっているかを注意
    して検証します。
    ※データ構造については次回の資料で深堀りする予定です。
    

    View Slide

84. ユーザーの記憶⼒に依存しない
    8
    

    View Slide

85. ユーザーの記憶⼒に依存するデメリット
    •必要な情報を同⼀のウィンドウ内で⾒られない
    •不必要な画⾯遷移をしなければならない
    •ユーザーの集中⼒や決断⼒を消耗させる
    ユーザーへの不要なストレスによって、双⽅の機会損失につながってしまう。
    

    View Slide

86. ユーザーの記憶⼒に配慮した
    ユーザーインターフェイスとは？
    WordPressの記事⼊⼒ページを例に⾒てみます。
    

    View Slide

87. WordPress
    WordPressの記事⼊⼒ペー
    ジの右側には、記事情報を確
    認・編集できる投稿情報エリ
    アがあります。例えば次の要
    素の確認・編集できます。
    •URL
    •公開⽇時
    •カテゴリー
    •アイキャッチ画像
    •タグ
    

    View Slide

88. 右側の投稿情報エリアを詳細ページで
    表⽰できなかったとしたらどうなるか？
    

    View Slide

89. ページを何度も⾏き来することに…
    記事編集ページ 記事⼀覧ページ
    

    View Slide

90. ユーザーの負担を減らす⽅法を考える
    改善するには？
    

    View Slide

91. ユーザーが記憶しなくても情
    報へアクセスしやすいように
    する。
    例：確認画⾯で⼊⼒済みの情報を表⽰する。
    

    View Slide

92. ユーザーがシステムの仕様や
    構造などの前提知識を持たな
    くても操作できること。
    例：ボタンを押したときの挙動を予測できる。
    

    View Slide

93. ユーザーが操作できるように
    なるための知識をその場から
    学べる。
    例：フォームに⼊⼒例を表⽰する。
    

    View Slide

94. 特に⼊⼒フォーム画⾯では、「ユーザーが前の
    画⾯の情報を覚えておく」という状態を避けら
    れる情報設計や画⾯構成にすると、ユーザーの
    負荷を減らせます。
    

    View Slide

95. 要素を増やすときこそ慎重に
    9
    

    View Slide

96. 要素を増えすときこそ慎重に
    レイアウトを検証したほうが
    良いと考えます。
    特にアプリケーションのユーザーインターフェイ
    ス設計の場合。
    

    View Slide

97. なぜ要素を増やすときに慎重に検証するの？
    ⻑期的な負債になりやすい
    デメリットが潜んでいるから
    

    View Slide

98. 短期的な視点で要素を増やすことのデメリット
    •1度増やした要素は簡単には削除できない
    •不要な要素がどんどん増えていってしまう
    •結果的にユーザー全体にとって不便になる
    ⼀部ユーザーからの要望機能が、多くのユーザーからは不要ということも。
    

    View Slide

99. 特にボタンが増えるときにはアプリケーション
    全体の整合性、画⾯が変わったときの他のボタ
    ンやテキストと整合性にも影響するためです。
    Create Edit Delete New?
    ?
    

    View Slide

100. 今ある要素の場所を変えると、ユーザーに再学
     習を強いてしまいます。操作に慣れているユー
     ザーほど変化へのストレスが⾼いはずです。
     ?
     ?
     ?
     ?
     

     View Slide

101. 要素増やしたいと思ったとき
     こそ、本当にその要素を追加
     するべきなのかどうかを慎重
     に検討したいです。
     Must?
     Need
     Simple?
     For User?
     

     View Slide

102. 要件定義で意識したい3つのこと
     10
     

     View Slide

103. ユーザーにとってよりわかり
     やすいサービスやユーザーイ
     ンターフェイスに近付くよう
     に、要件定義では次の3つの
     ことを特に意識したいです。
     

     View Slide

104. 疑問に思ったことは⾃分が納得できるまで仮説
     と検証を繰り返して、明らかにする。
     1
     設計するデザイナーが意図のわからない要素や概念をユーザーが理解できる可
     能性は低いです。何も知らないユーザーの視点を意識して検証したいです。
     

     View Slide

105. ユーザーにとってわかりやすい設計になってい
     るかの問いを繰り返す。
     2
     サービス提供側の事情はユーザーにとって無関係です。客観的にユーザーにと
     って親切でわかりやすい設計になっているかの検証を繰り返したいです。例え
     ばユーザーはサービス提供側の通称⽤語、専⾨⽤語を知りません。
     

     View Slide

106. 仕様、データ構造、導線などが、⼀般的なシス
     テム仕様に沿っているかを確認する。
     3
     独⾃のシステムになればなるほどユーザーにとって使いにくくなっている可能
     性が⾼いです。ネイティブOSのシステム仕様を知ることも参考になります。
     

     View Slide

107. デザイナーが
     エンジニアリングに触れるメリット
     

     View Slide

108. 余談ですが、デザイナーがエンジニアリングに
     触れるメリットとして⼤きく次の3点があるよう
     に思います。
     

     View Slide

109. データ構造について考える機会、触れる機会が
     増える。データベースを取り扱うことで、データ
     の⼊出⼒を考えて設計できるようになる。
     1
     データをどのようにユーザーに届けるかの観点が養われると考えます。
     

     View Slide

110. ⻑期的に耐久性のある、システムとして⻑持ち
     するデザインの予想がしやすくなる。
     2
     メンテナンスがしやすいデザイン表現が体感的に⾝につきやすくなると考え
     ます。コードでメンテナンスしやすいデザインは⻑持ちしやすい印象です。
     

     View Slide

111. エンジニアリングの観点を組み合わせた解決⽅
     法を思い付きやすくなる。
     3
     感覚的なものになりますが、ユーザーの使いやすさとシステム的な実現性の組
     み合わせから解決⽅法に気付きやすくなる⾯があるのではと感じます。例えば
     データ構造、データ属性、情報の取得先、速度の制約の観点など。
     

     View Slide

112. この資料で重要な
     3ポイントをおさらい
     

     View Slide

113. データ数が増減しても成り⽴
     つかを想定して設計を進めて
     いくと、拡張性や耐久性を⾼
     めやすくなります。
     ?
     

     View Slide

114. データの基本アクション
     •作成（Create）
     •読み出し（Read）
     •変更（Update）
     •削除（Delete）
     Data
     Create
     Update Delete
     Read
     4つの頭⽂字からCRUDとも
     呼ばれるようです。
     

     View Slide

115. 要素増やしたいと思ったとき
     こそ、本当にその要素を追加
     するべきなのかどうかを慎重
     に検討したいです。
     Must?
     Need
     Simple?
     For User?
     

     View Slide

116. 最後に
     この資料がユーザーインターフェイス設計の振
     り返りとして、お役に⽴てたら幸いです。
     

     View Slide

117. ありがとうございました
     

     View Slide