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

Slide 1

Slide 1 text

情報設計からのデザインアプローチユーザーの声を聞くよりも、もっとデータの声を聞け 2024年9月17日 HCD-Netセミナー『UIデザインプロセスの課題と対策』株式会社ツルカメ森田雄

Slide 2

Slide 2 text

講師紹介 • 森田雄（もりたゆう） • 株式会社ツルカメ代表取締役社長インフォメーションアーキテクト／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

Slide 3

Slide 3 text

HCDプロセス • HCD = Human Centered Design • 人間中心設計です。 • こんなHCD-Net主催のセミナーでいちいち説明するようなことではないですが… 2024/9/17 3

Slide 4

Slide 4 text

JIS Z 8530:2021より「人間中心設計の活動の相互関連性」の図 2024/9/17 4

Slide 5

Slide 5 text

HCDプロセス • HCDプロセスといえば、この図のようにユーザーの理解→要求 →設計→評価という活動のサイクルで、評価の後は必要な数だけ、各活動を繰り返すというものです。 • また、各活動ごとに成果物例が示され、たとえば理解は • アンケート • インタビュー • フォーカスグループ • フィールド調査 • エスノグラフィー調査 …といった具合です。 2024/9/17 5

Slide 6

Slide 6 text

ようするに • デザインプロセスの中心にユーザーがいるわけです。 • まあ名前の通りです。 2024/9/17 6

Slide 7

Slide 7 text

HCD以前は何中心だった？ • HCDは、もともとISO 13407:1999で示されたもので、これは、ユーザビリティの確保がその目論見でした。 • つまり、それ以前は、ユーザビリティがやばかった。 • …今も？ • 使用者のことを考えずに製品やサービスのインタフェースが作られていたといえるでしょう。 • …今も？ 2024/9/17 7

Slide 8

Slide 8 text

ところでWebの製品やサービスとは • Webサイト、Webアプリケーション、Webシステム、あるいはオンラインサービス、オンラインシステムなどなど • とりあえずここでは、総称して「Webサイト」と呼びます。 • Webサイトとユーザーの関係性について、おさらいします。 2024/9/17 8

Slide 9

Slide 9 text

• ユーザーがWebサイトを見ています。 2024/9/17 9

Slide 10

Slide 10 text

• ユーザーが見ているのは表示の最終出力たるWebサイトであり、そのWebサイトには元ネタがあります。 2024/9/17 10

Slide 11

Slide 11 text

• ユーザーが見ている最終出力たるWebサイトの、元ネタにも、さらに元ネタの元ネタたるデータがあります。 2024/9/17 11

Slide 12

Slide 12 text

• ユーザーが見ている最終出力たるWebサイトの元ネタの、そのさらに元ネタは、向こう側のユーザーによって作られています。 2024/9/17 12

Slide 13

Slide 13 text

2024/9/17 13 ユーザーが想像する Webサイトの範囲

Slide 14

Slide 14 text

2024/9/17 14 元ネタの作り手の想像の範囲

Slide 15

Slide 15 text

2024/9/17 15 根源を創りし者たち

Slide 16

Slide 16 text

2024/9/17 16 現実

Slide 17

Slide 17 text

2024/9/17 17 ユーザーが見ているWebサイトは氷山の一角に過ぎない。ユーザーに聞くのは限界がある。

Slide 18

Slide 18 text

2024/9/17 18 元ネタの作り手が想定しているユーザーも氷山の一角といえる。

Slide 19

Slide 19 text

2024/9/17 19 ここは企業活動に勤しんでる。

Slide 20

Slide 20 text

私たちデザイナーは UIもデザインするし、 UIを作り出すための元ネタもデザインするし、元ネタを作り出すためのさらなる元ネタもデザインするし、必要に応じて組織（元ネタの作り手）もデザインするわけです。 2024/9/17 20

Slide 21

Slide 21 text

2024/9/17 21 デザイナー

Slide 22

Slide 22 text

デザイナーが聞くべき声 • ユーザーの声は、まあ当たり前に聞きますね。 • 組織の声も、やり方は工夫しますが、聞きます。 • 最も聞くべきは、データの声です。 22 2024/9/17

Slide 23

Slide 23 text

2024/9/17 23 データの声（ここらへん）

Slide 24

Slide 24 text

2024/9/17 24 データの声は前後のどっちにも影響を与えるので是非聞こう！

Slide 25

Slide 25 text

データと情報 • 「データ」というのは、数値や文字列そのもののこと。 • データに、何らかの価値観や基準あるいはコンテクストを付与することで「情報」となります。 • …しかし、本セッションではもっと日本語的な言葉遣いとして「データ」および「情報」を扱いますので、だいたい同義であると思って聞いてください。 25 2024/9/17

Slide 26

Slide 26 text

ユーザーの声よりデータの声を聞け本編 2024/9/17 26

Slide 27

Slide 27 text

世にあまたあるシステム的な画面たち… 27 2024/9/17

Slide 28

Slide 28 text

頻出UIといえば • マイページならユーザー自身の名前であったり、管理画面ならユーザーリストであったり、お気に入りした人・見た人・履歴系の一覧にも、システム内の画面は名前であふれています。 • ということで、やはり名前入力欄でしょう。 • こんなのとかこんなのとか 28 2024/9/17

Slide 29

Slide 29 text

氏名の氏(姓)と名が分かれている入力欄 • 気づいた点はありますか？（空気感によっては会場から挙手で募る） 29 2024/9/17

Slide 30

Slide 30 text

気づいた点（代表例） • 氏名の入力で、氏と名に入力欄が分かれている。 • 氏と名のどちらも必須入力が求められている。 • ふりがな入力のほうで、ラベルは氏名なのにプレースホルダーでは姓名になっている。 • 文字種の表現だけでカタカナ入力を求めている。 • 入力欄のサイズが9～10文字くらい？（最大値なのか？） • ミドルネームの入力欄が無い。これらはいずれもユーザー目線での気づきです。 ※特にユーザー自身が平均的な日本人ユーザーの場合 2024/9/17 30

Slide 31

Slide 31 text

どうして氏名が分かれている？ • 日本人を想定している。 • そういう画面仕様（要件）だった。 • DBのテーブルがそうなってるから入力欄もそうなっている。これらはシステム都合に基づくデータの作り手目線の理由です。 31 2024/9/17

Slide 32

Slide 32 text

データの声を聞いてみると… • そもそも名前の構成要素は「氏」と「名」だけとは限らない。 • 日本国籍の戸籍名では「氏」と「名」で確定するが、そもそもいつから戸籍名に限定された？ • 欧米では出生の命名時から複数の名がつけられたり、複数の姓が連結されたりと、複名複合姓の場合がある。 • 姓がない国もある。 • 姓がなくて名が連なる国もある。 • パスポートでは仕様により強制的に統一フォーマットにされるようになっているが、パスポートネームに限定しているのか？ 32 2024/9/17

Slide 33

Slide 33 text

（補足）パスポートネームの様式 • 姓、名、ミドルネーム等、あわせて37文字まで。 • ICAO Doc 9303-3で、一次識別子、二次識別子の二つで構成されるように、旅券発行国が名前のどの部分を一次識別子にするかを決定せよとしている。 • 文字数制限もあるので、非常に長い名前でも強制的にどこかで切らねばならない。 • 誰もが必ずアルファベットの名前を持つことになる。 • しかしパスポートでどう扱われようと、当人の名前は元のまま変わることはない。 2024/9/17 33

Slide 34

Slide 34 text

（参考）JAL Q&A よくある質問「名前が長くWebでパスポートの表記通りに入力ができません。予約時に、名前入力の文字制限はありますか。」より 2024/9/17 34

Slide 35

Slide 35 text

「名前」というデータに言わせれば • 名前はもっと自由なものだ。 • 名前というデータの本質からいえば、フォーマットなどない。 2024/9/17 35

Slide 36

Slide 36 text

データの声に従うと、こうなる • 入力欄は１つ • 文字種と文字数の制限なし • 必須ではあるが、好きなように入力できる 2024/9/17 36

Slide 37

Slide 37 text

システム要件に基づくUIの試行錯誤 • データの声に従った通りの、いうなれば、データに対して誠実なUIは、それ自体でひとつの完成形です。 • 見る者（ユーザー）に、これは名前本来の自由な入力欄なのだということを知らしめるからです。 • しかしシステムには何らかの要件があり、それを実現する責務がありますので、要件をUIに付与し、試行錯誤してみましょう。 2024/9/17 37

Slide 38

Slide 38 text

DB的な都合で姓と名を分けたい • そもそもなぜDBがそういうテーブル設計になっているのか？ • 日本人しか使わない前提？ • そして戸籍名しか使えないという制約は誰にとって有益なのか？ • 通称やニックネームではなぜだめなのか？ • 絶対に戸籍名じゃないと…っていうのは、給与明細くらいか？ • 健康保険の仕様から、日本国籍の人は戸籍名が求められる • 日本国籍がない人は住民票記載の通称でOK • 東海林太郎は東海林太郎なのか、東海林太郎なのか？ • どうして区別したいのか？ • 給与明細か？ • 漫☆画太郎はどうなる 2024/9/17 38

Slide 39

Slide 39 text

マーケティングや分析の都合で分けたい • 姓と名を分けて嬉しいことってある？ • 姓でソーティングできるよ！ • 分けなくてもできるだろう。 • 姓がない人はどうすればいい？ • 複名複合姓の人はどうすればいい？ • 姓と名におさまらないデータを、姓か名の欄に入れ込ませるような、ユーザーのアイデンティティに踏み込む覚悟はあるのか？ • 個人を特定したい？ • フルネームでは特定できないのか？ • メールアドレスなど他のデータもとっているのでは？ • 内部的にはIDを発行するのでは？ 2024/9/17 39

Slide 40

Slide 40 text

対話時に姓が必要だから分けたい • DMの宛名の時に分かれてないと困る。 • 別にフルネームでいいだろう。 • サポートや営業の電話の時に分かれてないと困る。 • 別にフルネームでいいだろう。 • 本人確認するので名字をお願いしますとかいって本人に言わせよう。 • マイページに「こんにちは〇〇さん」って表示したいもん。 • 別にフルネームでいいだろう。 • 名前だけのほうがフレンドリーだし、表示幅の都合があるんだもん。 • 藤本太郎喜左衛門将時能さんはどうなるんだ。 2024/9/17 40

Slide 41

Slide 41 text

ユーザーの声はどうか？ • そもそもこのUIのユーザビリティは悪いのか？ • しいていうなら、 • 全角と半角のどちらで入力すればいいのか？ • 氏名のセパレーターは必要なのか？ • 最大文字数はあるのか？という疑問を呈するユーザーはいるかもしれない。 2024/9/17 41

Slide 42

Slide 42 text

サポートテキストを追加してみる？ • 余計に分かりにくい。 2024/9/17 42 全角半角どちらでも入力できます。氏と名の間にスペースを入れても入れなくてもいいです。最大で21,845文字まで入力できます（3byte文字の場合）。

Slide 43

Slide 43 text

結論（試行錯誤の結果） • データの声に誠実なUIは、 • システム都合に左右されないし、 • ユーザーは自然に、それをそういうものと受け入れる。 2024/9/17 43

Slide 44

Slide 44 text

名前の次に頻出しがちなUI • それはやっぱり日付です。 • 年月日。 • 場合によっては時分秒まで入りますが、いったん年月日。 • 入力には、大きく分けて • 直接入力 • セレクトボックス • カレンダーというパターンがあります。 2024/9/17 44

Slide 45

Slide 45 text

日付入力のUIといえば… • 昨今こういう指摘がありましたね。 2024/9/17 45 https://x.com/konotarogomame/status/1622864974401134592

Slide 46

Slide 46 text

この指摘は、ユーザーの声としての指摘 • かつ、特定の状況に依存した指摘です。 • たとえば、家系図管理システムでの、曾祖父母の誕生日入力といった文脈があれば、まあ問題ないともいえるわけです。 2024/9/17 46

Slide 47

Slide 47 text

「日付」というデータの声 • 日付は、国や時代によって異なる表記方法によって記述される暦日のこと。 • 現代ではISO 8601:2000（JIS X 0301:2002）で世界標準の表記方法が決まっている。 • 日本での書き方は YYYYMMDDThhmmss+0900 • 日本語的に書くと、YYYY年MM月DD日 hh時mm分ss秒など • これはもう人の定めしものなので、私（日付）としてはそれに従うまでです。 2024/9/17 47

Slide 48

Slide 48 text

日付の声は、システムの都合と合致 • したがって、まあそんなにおかしなUIにはならないわけです。 • しかし、データの作り手の想像の範囲が、えてしてユーザーにまで到達してないこともぼちぼち多く、先の指摘のようなことが起きるといえます。 2024/9/17 48

Slide 49

Slide 49 text

日付UIはコンテクストで決める • 日付というデータの声は、当たり障りのない殊勝なものでした。 • このように、データの声がプリミティブすぎてシステムの都合と一致する場合のUIは、コンテクストによって確定します。 2024/9/17 49

Slide 50

Slide 50 text

特定の日付を特定する場合 • 正直、3パターンのどれでもいい。 • しいていうなら、直接入力とカレンダーの組み合わせ。 • モバイル環境ではセレクトボックスもありえる。 • カレンダーを使うなら、文脈に応じて、カレンダーの起点日を想定される範囲の中の値にする（中央値でも良い） 2024/9/17 50

Slide 51

Slide 51 text

特定の日付を基準とした範囲を示す場合開始の日付が今日以降だと分かりやすい。もしくは過去の日付でも、固定の範囲が確定している時。このような場合、範囲指定もしくは、カレンダーUIが適している。 2024/9/17 51

Slide 52

Slide 52 text

UIを決めるのはユーザーではない • 基本的には、データの声によってUIが確定します。 • 少なくとも、UIの方向性は確定する。 • または、コンテクストを付与してUIが確定する場合があります。 • これは、データの声が作り手の都合と合致する時。 • ユーザーは、その確定したUIが使いやすいか、コンテクストがわかりやすいかを言います。 • 確定がマジで確定でいいかどうかに影響。 • 使いにくい時はデータを、わかりにくい時はコンテクストを疑う。 2024/9/17 52

Slide 53

Slide 53 text

コンテクストを定義する情報設計 • 情報設計がいうところの情報とは、情報アーキテクチャのこと。 • 情報アーキテクチャは「情報の構造を策定し、わかりやすさをデザインする技術」のことです。 53 2024/9/17 Richard Saul Wurman “Information Architects” Watson-Guptill Publications, Incorporated, 1996

Slide 54

Slide 54 text

情報設計でやること（ざっくり） • 単体または複数サイトの組み合わせ全体におけるハイレベルなサイト構造の設計 • 目的に合わせて適切な分類システム（スキーム）を考案し、情報の整理（組織化・グループ化）と構造化 • サイト単位の概念設計、課題抽出、問題解決の提案 • ナビゲーションスキームを考案し、ページの構成に必要な情報コンポーネントの設計、および仕組みの定義 • ページ単位での詳細な構造設計この一連の情報設計業務は、常にデータと向き合って行います。 2024/9/17 54

Slide 55

Slide 55 text

データの声を聞くとは── • データそのものにとって、もっとも自然な形を抽出する行為。 • かっこいい言い方を考え中です。 • 候補１）データのマテリアルオネスティ • 候補２）情報のアフォーダンス • UIで受け止める以上はシグニファイアのほうがいいかも？ 55 2024/9/17

Slide 56

Slide 56 text

実は誰もが聞いている、データの声 • Webサイトのコンテンツに、新着情報のようなものがあります。 • これは読み物系のBtoCサイトに顕著に存在しますが、BtoBの業務システムもコンテンツとしてしばしば持つものです。 • 新着情報の表示をする時、どういうふうにUIを決めますか？ 56 2024/9/17

Slide 57

Slide 57 text

• 多くの場合、新着情報のインデックスは時系列表示となります。 • LATCHでいうところのTの軸で構造化されるのです。 • 50音順でも、カテゴリー順でもありません。 • カテゴリー順は、絞り込み等の付加機能として実装されがち。 • でも50音順では無い。 57 2024/9/17

Slide 58

Slide 58 text

• 新着情報を時系列で並べることが本当にいいのか？ユーザーのためなのか？システム都合なのか？ • ユーザーテストによって導かれたわけでもなく、研究論文を読み漁ったでもなく、ただ、必然として時系列に並べたことでしょう。 • なぜ、そうなったのか？ 2024/9/17 58

Slide 59

Slide 59 text

それは、新着情報が、時系列で表示されたがっているからです。誰もがデータの声を聞いているのです。 2024/9/17 59

Slide 60

Slide 60 text

情報設計からのデザインアプローチとは • 情報設計業務を通じて、サイト内で扱うすべてのデータと真摯に向き合い、 • データの声を聞き、データがどう表示されたがっているか？どう扱われたがっているか？を読み解き、 • UIを確定するという考え方なのです。 2024/9/17 60

Slide 61

Slide 61 text

…という、話題提供でございました • 実際に、僕はこのデータの声を聞くというアプローチで、様々なサイトやシステムを設計しています。 • デザインシステムのディティールデザインにも有効です。 • 是非、みんなもやってみよう。聞こうよ！データの声！！ 2024/9/17 61

Slide 62

Slide 62 text

＜参考文献？関連図書？？＞ • “情報アーキテクチャ第4版” ピーター･モービル他 • “ギブソン生態学的視覚論” J.J.ギブソン • “生態学的知覚システム” J.J.ギブソン • “アフォーダンスの心理学” エドワード･S･リード • “意味論的展開” クラウス･クリッペンドルフ • “ジョブ理論” クレイトン M クリステンセン • “声なきものの声を聴く─ランシエールと解放する美学” 鈴木亘 • これ参考にしたのタイトルだけでしょ…… 2024/9/17 62

Slide 63

Slide 63 text

ご清聴ありがとうございました • 質疑応答、残り時間次第で実施します。 • 本スライドはSpeaker Deckに公開予定です。 https://speakerdeck.com/securecat 2024/9/17 63