情報設計からのデザインアプローチ ～ユーザーの声を聞くよりも、もっとデータの声を聞け～

HCD-Net主催 UIデザインプロセスの課題と対策 ～UIデザインをリードするための実践的アプローチ～(2024年9月17日開催)
https://peatix.com/event/4070934/
上記イベントの講演④にて使用したスライドを公開用に編集したものです。

作者：森田 雄 / 株式会社ツルカメ
https://x.com/securecat
https://turucame.jp/

1. 情報設計からの デザインアプローチ ユーザーの声を聞くよりも、もっとデータの声を聞け 2024年9月17日 HCD-Netセミナー『UIデザインプロセスの課題と対策』 株式会社ツルカメ 森田 雄
2. 講師紹介 • 森田 雄（もりた ゆう） • 株式会社ツルカメ 代表取締役社長 インフォメーションアーキテクト／UXデザイナー • 四半世紀以上に渡ってWebデザイン界隈で受託をやっています • 情報アーキテクチャ、UXデザイン、アクセシビリティの自称専門家／野生の研究者です • HCD-Net 賛助会員／アニュアルレポート実行委員 • デジタルマーケティング研究機構 幹事／人材育成プロジェクト サブリーダー • 広告電通賞 選考委員／イノベーティブ・アプローチ 副委員長 • AKQA UKA株式会社 プリンシパル・エクスペリエンス・デザイナー • ちなみに今年は、何やらWeb Designingづいてて、 • 2024年 4月号 第1特集【事例と解説から学ぶデザインシステム】 • 2024年 6月号 第2特集【Webアクセシビリティ最前線】 • 2024年10月号 About Face第4版発売記念企画【About Face 推薦文】 などと載りまくりです。どうぞご笑覧ください。 2 2024/9/17
3. HCDプロセス • HCD = Human Centered Design • 人間中心設計です。 • こんなHCD-Net主催のセミナーでいちいち説明するようなこと ではないですが… 2024/9/17 3
4. JIS Z 8530:2021より「人間中心設計の活動の相互関連性」の図 2024/9/17 4
5. HCDプロセス • HCDプロセスといえば、この図のようにユーザーの理解→要求 →設計→評価という活動のサイクルで、評価の後は必要な数だ け、各活動を繰り返すというものです。 • また、各活動ごとに成果物例が示され、たとえば理解は • アンケート • インタビュー • フォーカスグループ • フィールド調査 • エスノグラフィー調査 …といった具合です。 2024/9/17 5
6. ようするに • デザインプロセスの中心にユーザーがいるわけです。 • まあ名前の通りです。 2024/9/17 6
7. HCD以前は何中心だった？ • HCDは、もともとISO 13407:1999で示されたもので、これは、 ユーザビリティの確保がその目論見でした。 • つまり、それ以前は、ユーザビリティがやばかった。 • …今も？ • 使用者のことを考えずに製品やサービスのインタフェースが作 られていたといえるでしょう。 • …今も？ 2024/9/17 7
8. ところでWebの製品やサービスとは • Webサイト、Webアプリケーション、Webシステム、あるいは オンラインサービス、オンラインシステムなどなど • とりあえずここでは、総称して「Webサイト」と呼びます。 • Webサイトとユーザーの関係性について、おさらいします。 2024/9/17 8
9. • ユーザーがWebサイトを見ています。 2024/9/17 9
10. • ユーザーが見ているのは表示の最終出力たるWebサイトであ り、そのWebサイトには元ネタがあります。 2024/9/17 10
11. • ユーザーが見ている最終出力たるWebサイトの、元ネタにも、 さらに元ネタの元ネタたるデータがあります。 2024/9/17 11
12. • ユーザーが見ている最終出力たるWebサイトの元ネタの、その さらに元ネタは、向こう側のユーザーによって作られていま す。 2024/9/17 12
13. 2024/9/17 13 ユーザーが想像する Webサイトの範囲
14. 2024/9/17 14 元ネタの作り手の 想像の範囲
15. 2024/9/17 15 根源を 創りし者たち
16. 2024/9/17 16 現実
17. 2024/9/17 17 ユーザーが見ているWebサイトは 氷山の一角に過ぎない。 ユーザーに聞くのは限界がある。
18. 2024/9/17 18 元ネタの作り手が 想定しているユーザーも 氷山の一角といえる。
19. 2024/9/17 19 ここは企業活動 に勤しんでる。
20. 私たちデザイナーは UIもデザインするし、 UIを作り出すための元ネタもデザインするし、 元ネタを作り出すためのさらなる元ネタもデザインするし、 必要に応じて組織（元ネタの作り手）もデザインするわけです。 2024/9/17 20
21. 2024/9/17 21 デザイナー
22. デザイナーが聞くべき声 • ユーザーの声は、まあ当たり前に聞きますね。 • 組織の声も、やり方は工夫しますが、聞きます。 • 最も聞くべきは、データの声です。 22 2024/9/17
23. 2024/9/17 23 データの声 （ここらへん）
24. 2024/9/17 24 データの声は前後のどっちにも 影響を与えるので是非聞こう！
25. データと情報 • 「データ」というのは、数値や文字列そのもののこと。 • データに、何らかの価値観や基準あるいはコンテクストを付与 することで「情報」となります。 • …しかし、本セッションではもっと日本語的な言葉遣いとして 「データ」および「情報」を扱いますので、だいたい同義である と思って聞いてください。 25 2024/9/17
26. ユーザーの声よりデータの声を聞け 本編 2024/9/17 26
27. 世に あまたあるシステム的な画面たち… 27 2024/9/17
28. 頻出UIといえば • マイページならユーザー自身の名前であったり、管理画面なら ユーザーリストであったり、お気に入りした人・見た人・履歴 系の一覧にも、システム内の画面は名前であふれています。 • ということで、やはり名前入力欄でしょう。 • こんなのとか こんなのとか 28 2024/9/17
29. 氏名の氏(姓)と名が分かれている入力欄 • 気づいた点はありますか？ （空気感によっては会場から挙手で募る） 29 2024/9/17
30. 気づいた点（代表例） • 氏名の入力で、氏と名に入力欄が分かれている。 • 氏と名のどちらも必須入力が求められている。 • ふりがな入力のほうで、ラベルは氏名なのにプレースホルダーでは 姓名になっている。 • 文字種の表現だけでカタカナ入力を求めている。 • 入力欄のサイズが9～10文字くらい？（最大値なのか？） • ミドルネームの入力欄が無い。 これらはいずれもユーザー目線での気づきです。 ※特にユーザー自身が平均的な日本人ユーザーの場合 2024/9/17 30
31. どうして氏名が分かれている？ • 日本人を想定している。 • そういう画面仕様（要件）だった。 • DBのテーブルがそうなってるから入力欄もそうなっている。 これらはシステム都合に基づくデータの作り手目線の理由です。 31 2024/9/17
32. データの声を聞いてみると… • そもそも名前の構成要素は「氏」と「名」だけとは限らない。 • 日本国籍の戸籍名では「氏」と「名」で確定するが、そもそも いつから戸籍名に限定された？ • 欧米では出生の命名時から複数の名がつけられたり、複数の姓 が連結されたりと、複名複合姓の場合がある。 • 姓がない国もある。 • 姓がなくて名が連なる国もある。 • パスポートでは仕様により強制的に統一フォーマットにされる ようになっているが、パスポートネームに限定しているのか？ 32 2024/9/17
33. （補足）パスポートネームの様式 • 姓、名、ミドルネーム等、あわせて37文字まで。 • ICAO Doc 9303-3で、一次識別子、二次識別子の二つで構成さ れるように、旅券発行国が名前のどの部分を一次識別子にする かを決定せよとしている。 • 文字数制限もあるので、非常に長い名前でも強制的にどこかで 切らねばならない。 • 誰もが必ずアルファベットの名前を持つことになる。 • しかしパスポートでどう扱われようと、当人の名前は元のまま 変わることはない。 2024/9/17 33
34. （参考）JAL Q&A よくある質問 「名前が長くWebでパスポートの表記通りに入力ができません。予約時に、名前入力の文字制限はありますか。」より 2024/9/17 34
35. 「名前」というデータに言わせれば • 名前はもっと自由なものだ。 • 名前というデータの本質からいえば、フォーマットなどない。 2024/9/17 35
36. データの声に従うと、こうなる • 入力欄は１つ • 文字種と文字数の制限なし • 必須ではあるが、好きなように入力できる 2024/9/17 36
37. システム要件に基づくUIの試行錯誤 • データの声に従った通りの、いうなれば、データに対して誠実 なUIは、それ自体でひとつの完成形です。 • 見る者（ユーザー）に、これは名前本来の自由な入力欄なのだ ということを知らしめるからです。 • しかしシステムには何らかの要件があり、それを実現する責務 がありますので、要件をUIに付与し、試行錯誤してみましょ う。 2024/9/17 37
38. DB的な都合で姓と名を分けたい • そもそもなぜDBがそういうテーブル設計になっているのか？ • 日本人しか使わない前提？ • そして戸籍名しか使えないという制約は誰にとって有益なのか？ • 通称やニックネームではなぜだめなのか？ • 絶対に戸籍名じゃないと…っていうのは、給与明細くらいか？ • 健康保険の仕様から、日本国籍の人は戸籍名が求められる • 日本国籍がない人は住民票記載の通称でOK • 東海林太郎は東海林 太郎なのか、東海 林太郎なのか？ • どうして区別したいのか？ • 給与明細か？ • 漫☆画太郎はどうなる 2024/9/17 38
39. マーケティングや分析の都合で分けたい • 姓と名を分けて嬉しいことってある？ • 姓でソーティングできるよ！ • 分けなくてもできるだろう。 • 姓がない人はどうすればいい？ • 複名複合姓の人はどうすればいい？ • 姓と名におさまらないデータを、姓か名の欄に入れ込ませるような、ユー ザーのアイデンティティに踏み込む覚悟はあるのか？ • 個人を特定したい？ • フルネームでは特定できないのか？ • メールアドレスなど他のデータもとっているのでは？ • 内部的にはIDを発行するのでは？ 2024/9/17 39
40. 対話時に姓が必要だから分けたい • DMの宛名の時に分かれてないと困る。 • 別にフルネームでいいだろう。 • サポートや営業の電話の時に分かれてないと困る。 • 別にフルネームでいいだろう。 • 本人確認するので名字をお願いしますとかいって本人に言わせよう。 • マイページに「こんにちは〇〇さん」って表示したいもん。 • 別にフルネームでいいだろう。 • 名前だけのほうがフレンドリーだし、表示幅の都合があるんだもん。 • 藤本太郎喜左衛門将時能さんはどうなるんだ。 2024/9/17 40
41. ユーザーの声はどうか？ • そもそもこのUIのユーザビリティは悪いのか？ • しいていうなら、 • 全角と半角のどちらで入力すればいいのか？ • 氏名のセパレーターは必要なのか？ • 最大文字数はあるのか？ という疑問を呈するユーザーはいるかもしれない。 2024/9/17 41
42. サポートテキストを追加してみる？ • 余計に分かりにくい。 2024/9/17 42 全角半角どちらでも入力できます。 氏と名の間にスペースを入れても入れなくてもいいです。 最大で21,845文字まで入力できます（3byte文字の場合）。
43. 結論（試行錯誤の結果） • データの声に誠実なUIは、 • システム都合に左右されないし、 • ユーザーは自然に、それをそういうものと受け入れる。 2024/9/17 43
44. 名前の次に頻出しがちなUI • それはやっぱり日付です。 • 年月日。 • 場合によっては時分秒まで入りますが、いったん年月日。 • 入力には、大きく分けて • 直接入力 • セレクトボックス • カレンダー というパターンがあります。 2024/9/17 44
45. 日付入力のUIといえば… • 昨今こういう指摘がありましたね。 2024/9/17 45 https://x.com/konotarogomame/status/1622864974401134592
46. この指摘は、ユーザーの声としての指摘 • かつ、特定の状況に依存した指摘です。 • たとえば、家系図管理システムでの、曾祖父母の誕生日入力と いった文脈があれば、まあ問題ないともいえるわけです。 2024/9/17 46
47. 「日付」というデータの声 • 日付は、国や時代によって異なる表記方法によって記述される 暦日のこと。 • 現代ではISO 8601:2000（JIS X 0301:2002）で世界標準の表記 方法が決まっている。 • 日本での書き方は YYYYMMDDThhmmss+0900 • 日本語的に書くと、YYYY年MM月DD日 hh時mm分ss秒など • これはもう人の定めしものなので、私（日付）としてはそれに 従うまでです。 2024/9/17 47
48. 日付の声は、システムの都合と合致 • したがって、まあそんなにおかしなUIにはならないわけです。 • しかし、データの作り手の想像の範囲が、えてしてユーザーに まで到達してないこともぼちぼち多く、先の指摘のようなこと が起きるといえます。 2024/9/17 48
49. 日付UIはコンテクストで決める • 日付というデータの声は、当たり障りのない殊勝なものでし た。 • このように、データの声がプリミティブすぎてシステムの都合 と一致する場合のUIは、コンテクストによって確定します。 2024/9/17 49
50. 特定の日付を特定する場合 • 正直、3パターンのどれでもいい。 • しいていうなら、直接入力とカレンダーの組み合わせ。 • モバイル環境ではセレクトボックスもありえる。 • カレンダーを使うなら、文脈に応じて、カレンダーの起点日を 想定される範囲の中の値にする（中央値でも良い） 2024/9/17 50
51. 特定の日付を基準とした範囲を示す場合 開始の日付が今日以降だと分かりやすい。 もしくは過去の日付でも、固定の範囲が確定している時。 このような場合、範囲指定もしくは、カレンダーUIが適してい る。 2024/9/17 51
52. UIを決めるのはユーザーではない • 基本的には、データの声によってUIが確定します。 • 少なくとも、UIの方向性は確定する。 • または、コンテクストを付与してUIが確定する場合がありま す。 • これは、データの声が作り手の都合と合致する時。 • ユーザーは、その確定したUIが使いやすいか、コンテクストが わかりやすいかを言います。 • 確定がマジで確定でいいかどうかに影響。 • 使いにくい時はデータを、わかりにくい時はコンテクストを疑う。 2024/9/17 52
53. コンテクストを定義する情報設計 • 情報設計がいうところの情報とは、情報アーキテクチャのこ と。 • 情報アーキテクチャは「情報の構造を策定し、わかりやすさを デザインする技術」のことです。 53 2024/9/17 Richard Saul Wurman “Information Architects” Watson-Guptill Publications, Incorporated, 1996
54. 情報設計でやること（ざっくり） • 単体または複数サイトの組み合わせ全体におけるハイレベルな サイト構造の設計 • 目的に合わせて適切な分類システム（スキーム）を考案し、 情報の整理（組織化・グループ化）と構造化 • サイト単位の概念設計、課題抽出、問題解決の提案 • ナビゲーションスキームを考案し、ページの構成に必要な情報 コンポーネントの設計、および仕組みの定義 • ページ単位での詳細な構造設計 この一連の情報設計業務は、常にデータと向き合って行います。 2024/9/17 54
55. データの声を聞くとは── • データそのものにとって、もっとも自然な形を抽出する行為。 • かっこいい言い方を考え中です。 • 候補１）データのマテリアルオネスティ • 候補２）情報のアフォーダンス • UIで受け止める以上はシグニファイアのほうがいいかも？ 55 2024/9/17
56. 実は誰もが聞いている、データの声 • Webサイトのコンテンツに、新着情報のようなものがありま す。 • これは読み物系のBtoCサイトに顕著に存在しますが、BtoBの 業務システムもコンテンツとしてしばしば持つものです。 • 新着情報の表示をする時、どういうふうにUIを決めますか？ 56 2024/9/17
57. • 多くの場合、新着情報のインデックスは時系列表示となりま す。 • LATCHでいうところのTの軸で構造化されるのです。 • 50音順でも、カテゴリー順でもありません。 • カテゴリー順は、絞り込み等の付加機能として実装されがち。 • でも50音順では無い。 57 2024/9/17
58. • 新着情報を時系列で並べることが本当にいいのか？ ユーザーのためなのか？ システム都合なのか？ • ユーザーテストによって導かれたわけでもなく、 研究論文を読み漁ったでもなく、 ただ、必然として時系列に並べたことでしょう。 • なぜ、そうなったのか？ 2024/9/17 58
59. それは、 新着情報が、 時系列で表示されたがっているからで す。 誰もがデータの声を聞いているのです。 2024/9/17 59
60. 情報設計からのデザインアプローチとは • 情報設計業務を通じて、サイト内で扱うすべてのデータと 真摯に向き合い、 • データの声を聞き、データがどう表示されたがっているか？ どう扱われたがっているか？を読み解き、 • UIを確定するという考え方なのです。 2024/9/17 60
61. …という、話題提供でございました • 実際に、僕はこのデータの声を聞くというアプローチで、様々 なサイトやシステムを設計しています。 • デザインシステムのディティールデザインにも有効です。 • 是非、みんなもやってみよう。 聞こうよ！ データの声！！ 2024/9/17 61
62. ＜参考文献？関連図書？？＞ • “情報アーキテクチャ 第4版” ピーター･モービル 他 • “ギブソン 生態学的視覚論” J.J.ギブソン • “生態学的知覚システム” J.J.ギブソン • “アフォーダンスの心理学” エドワード･S･リード • “意味論的展開” クラウス･クリッペンドルフ • “ジョブ理論” クレイトン M クリステンセン • “声なきものの声を聴く─ランシエールと解放する美学” 鈴木 亘 • これ参考にしたのタイトルだけでしょ…… 2024/9/17 62
63. ご清聴ありがとうございました • 質疑応答、残り時間次第で実施します。 • 本スライドはSpeaker Deckに公開予定です。 https://speakerdeck.com/securecat 2024/9/17 63