フロントエンドエンジニアですが、現職ではUI設計、画面設計にも積極的に関わってきました。毎週のデザイン会議に参加し、UIデザイナー、PdMの方がよく口にしていた事などを整理して今回記事にまとめてみました。
情報
会議中情報という言葉が何度も出てきました。
情報と一言で言っても様々な性質があります。
情報の役割
誰が何の為に使う情報なのか？情報には役割、目的がある。
例：リスト表示されてる無数の情報から個別に識別するために固有の名前を表示する。
情報の状態
例：期限に近い、今日が期限、期限切れ、など状態は変化する。
情報の優先度
情報の重要度によって、見せる順番、目立たせる順番を変える。
情報の操作
ユーザーにどう操作してもらうか？自由に入力させるのか？決まった操作をさせるのか？
ワンクリックで終わらない複数の操作はフローで設計する必要がある。
情報の表示
表示の基本は、ミニマム/リスト表示と詳細表示の組み合わせ。
情報をブロックでまとめる
情報を役割のブロックでまとめるのが画面設計の基本。
実際にUI設計に落とし込む時のTips
一貫性
操作、表示共にアプリ/サービス内で一貫性を持たせる。ユーザーが一度操作を覚えれば、別の機能でも直感的に、安心して操作できる。表示においてもこの色はこの状態だ、この情報だとすぐに理解できる。
新ページ、新機能を増やしても、この一貫性のルールに統制していればユーザーがすぐに慣れてくれるし、拒否しない。
ただ、注意として全てのページにおいて完璧にデザインに一貫性がないとユーザーが混乱する訳ではない。開発者は普段から様々なページを横断して見ていますが、ユーザーが同じように使うケースは少ないので、全ページの一貫性にコストをかけすぎず、ある程度柔軟性を許容してバランスを取る事も大事と言われています。
共通概念
人間が当たり前のように持っていて、それに反して物理的な手間をかけさせない。
例えば、赤、黄色＝危険で、緑＝安全と多くの人が認識しているので、その共通概念を利用する。
圧迫感をなくす
ツールチップ、タブ、ポップアップ、モーダルなどを省スペース化のUIを使い、常時表示の情報量を減らす。また、情報のブロック間のマージンも多く取り、圧迫感をなくす。
文字の密度、情報の密度が高いとUX的に良くない。
まとめる、隠しておく
本当に必要な情報、頻繁に使う機能だけを常時表示してそれ以外はまとめたり、閉まっておく（プルダウン、隠しメニュー、表示/非表示、など）
こうやって情報量を削らないとどんどん増えてしまいがち。ソフトウェアはいくらでも増やせてしまう性質上気をつけないといけない。
ライティング
UXライティングも重要。使う言葉一つで理解度を左右し、UXに影響する。
ペルソナ、サービスの性格によって、言葉使いも変わる。
色
色で視認させる（人間の脳は形よりも色を強く認識する）ただ、色数を増やしすぎては逆効果なので、効果のある色に絞る色彩設計が必要。
人間の色に対する認知能力は先天的、かつてアフリカの森の中で果実、動物を見つけることに起因してると言われてる。
形、動き
ホバーなどでここで操作できるよとフィードバックする
形状の違いに対する認知能力も人間が古来から果実、穀物など違う形を選定してきたことに起因すると言われている。
注目のため、理解のため、装飾のために形を変え、動きをつける。
シンプル
単純にするではなく、明快にすること。
何が起こってるのか？を即座に理解でき、何をすればいいのか？を自信を持って判断できる事。
アプリケーションの機能は増やす理由は見えやすいが、減らす理由は見えにくい。
ただ、減らしていってシンプルにしたけど逆にわかりにくくなったら意味がない。
複雑なUIは作るのも大変だし、使うユーザーが喜ぶとも限らない。
そもそもユースケース、仕様を見直すべき。
目線
目線が定まらずどこを見たらいいのかわからない→目が疲れる→嫌がって使われない。
基本はページの中に一番最初に見て欲しい場所を決めて目線を定めやすくする。
具体的には、大量のリスト表示などでは、左右揃えを均一化する、色や文字の大きさで情報にメリハリをつける、ブロックも枠線、背景色などで分ける、など。
目線移動の方向を変えすぎないことも大事。
縦横を混在させすぎない、基本的にリストは縦方向、詳細は横方向。
直感的
予測とその結果が一致する、つまりユーザーが思った通りに動く事。
ただこれはそのユーザーの経験や共通概念に基づく事が多い。
アイコン
言葉よりアイコンの方が理解しやすいし、省スペースになる。
ただ、アイコン化しにくい言葉も多いので、無理にアイコン化しない方がいいケースもある。またアイコンを多用しすぎると逆に混乱するので、そういう場合はレイアウト設計を見直したり、まとめたりする方がいい。
ボタン
UIにおいて、重要なパーツの一つ。
ユーザーが重要な意志決定をする時に狙いを定めて操作するUI。
使う量も多く、種類も増えがちなので、しっかりした設計が必要。
余白
余白にも意味がある。近ければ関連性を強め、離せば弱められる。
更に離して、線を引き境界をつくれば別の情報として扱ってもらえる。
UI設計の進め方
画面に起こして初めて気付く事は多い
議論を前に進める為に、とにかく画面に起こし、それを叩き台に議論していくのがBestな進め方だと思いました。可視化してみて仕様の漏れや不整合に気づくし、必要なデータ、仕様などがクリアになってきて、設計議論が一気に前に進んでいきました。Figmaのプロトタイプツールで遷移、操作感も擬似的に作れるのでそういう機能も有効活用すればよりいいと思います。
仕様の背景をきちんと理解する
ユーザーがなぜその機能を欲しいのか？
ユーザーがなぜ間違った操作をしてしまうのか？
これらの背景をきちんとユーザーから話を聞いた上で画面設計することが重要。よくよく話を聞いてみると、機能を作るよりも別のソリューションで済む事も多くあります。
最初から作り込まない
最初からガッチリ作り込まないほうがいい、ユーザーの意見、反応を見て増改築をしていくスタンスがいい。最低限の機能だけでMVPを作って1日でも早くユーザーが触れる状態に持っていく事が大事だと思いました。
最後に
スティーブ・ジョブズ氏のこんな言葉があります。
Design is not just what it looks like and feels like.
Design is how it works.
ー Steve Jobs
デザインは何を見せるかではなく、「どう機能するか」を考えること。
なので日本語だとデザインより、設計と呼ぶ方が正しいと言われる所以です。
アプリケーション開発は情報という観点で言うと 目的の為に情報をどう機能させるのか？だと思いました。そして、基本的にはユーザー側とシステム側に責務が分かれる。
ユーザー側が情報をどう操作するか？→UIデザイナー、フロントエンドの責務
システム側が情報をどう持つか、どう扱うか？→バックエンドの責務
自分の場合は、フロントエンド開発はもちろん、UI設計も追求してユーザー体験のプロを目指していきたいと思います。
以上です、今後も新しい学びや気づきがあればこの記事を加筆修正していきます。
次はデザインシステム構築の時の学びを記事にしたいと思います。
参考文献：
・UIデザインの教科書