【読書記録】インターフェースデザインの指針
おはようございます。
ここ最近、業務で新製品の詳細設計を行なっているのですが、画面仕様を決めていくのが難しくて、UIに関する本を読み漁っています。
本日は以下の本を読み終えたので、私自身の考えが覆された、印象に残ったポイントについて振り返ってみようと思います。
本書は論文や参考書、研究者の発表など、様々なリファレンスを参照して、UIに関する100の指針を説明してくれています。
参考文献から引用してきた具体的な事例と、抽象的な結論。そこからUI設計に落とし込んだ時の具体的な活用方法まで展開してくれているので、とても理解しやすく、自分の業務と親和性がある内容ならばすぐにでも実践できそうと感じたのでとてもおすすめです！
色々とシリーズ化されているみたいなので、他のシリーズも買ってみようかなと思っています。
（UIとかユーザビリティに関する参考書5冊くらい一気に買って、すぐそこに積まれているので、それが読み終わってからになりますが。。。）
1．重要なのはクリックの回数ではない
段階的開示を行うと、利用者は何度もクリックする必要が生じます。ウェブサイトの設計に関連して、「詳細情報に辿り着くまでにクリックする回数はできるだけ少なくしなければならない」という話を聞いたことがあるかもしれません。しかしクリックの回数は重要ではありません。むしろ、ユーザーは喜んでクリックします。クリックのたびに適度な情報を得ながら先へ進めるのであれば、クリックしていることを意識しないでしょう。何回クリックするかを数えるよりも、段階的開示を行うことを検討してみてください。
まずはこの記載です。個人的になかなか衝撃を受けました。
ユーザービリティの定義って、有効さ✖️効率✖️満足度と言われているので、私にとって、GUIにおけるユーザーのクリック数がここ「効率」に直結する指標になると考えていました。
私の会社でも、画面操作の効率性を考えるときに「クリック数」が前よりも増えているのでダメ。というようなレビュー指摘を受けることが多いです。まさに、クリック数はできるだけ少なく済ませなければならない。という考えが浸透しているのだと思います。
確かにタップ数を減らそうとすると、1つの画面に多くの要素を同時に表示することになるので、とてもごちゃごちゃになりがちです。入れたい要素がなかなか画面に入りきらなくて、文字フォントを小さくして調整したり。笑
あとよく言われるのは、大まかな情報だけで良い人もいれば、詳細な情報まで見たい人もいる。なので、詳細な情報を見たい人に合わせることが多いです。
丁寧にユーザーが見つけたい情報まで辿り着くまでの、頭の中の思考の流れを理解して、UIも同じ流れでだんだん詳細な情報に進めるように構成すれば、ユーザーにとってクリック操作は苦ではないということを理解しました。
まさにUXを理解することですね。ユーザー調査でいつ何の情報を必要とするのかをシナリオにして、それに合わせて画面構成を検討しなければなりません。
ユーザーに必要な情報を探させたり、考えさせたりするくらいならば、深く考えずにクリックさせていった方が良い。心に留めておきます。
2．一度に覚えられるのは4つだけ
「マジックナンバー7」という言葉を聞いたことがありました。人間が一度に記憶できる項目数は7が上限ということです。
私はこれをもとに、メニューやタブ、設定の選択肢は極力7つ以内になることを心がけて設計してきていました。
ところが、本書によるとどうやら少し違うようです。
現在の研究によると「魔法の数」は4なのです。
なにー！！という感想です。確かにマジックナンバー7を教えてくれたのは、6つくらい年上の先輩だったなぁと。そういえば今は3とか4の説も出てきているとおっしゃっていました。。
ただ同時に、まとまりに分けることでグループ化すれば、まとまりごとに1つとカウントされるような記憶の作りになっているようです。
ということは、例えばタブでどうしても数が5つや6つになってしまう場合は、何からの上位分類を作って、2段階の画面構成に変更してあげた方が良いということになりますね。
最近だと、画面左のタブバーとか、ヘッダーにタブを設けるのと、フッターにもタブのような画面遷移のコントロールを設けられたりしますね。
3．エラーメッセージの書き方
エラーメッセージをどう書くべきかというのもいつも議論になります。そのエラーが発生した時の対処法がユーザーに委ねられている場合なんかは、なかなか決められません。
本書では、エラーメッセージを作成する場合は、以下の要件を満たすようにと書かれていました。
・ユーザーが何をしたのかを告げる
・発生した問題を説明する
・修正方法を指示する
・受動態ではなく能動態を使い、平易な言葉で書く
・例を示す
この要件はこのまま印刷して、チェックリストとして職場のディスクに貼っておきたいくらいです。
この中でも意識しなければならないのが、「修正方法を指示する」と「例を示す」ことかなと思います。
やはりエラーってのは発生するだけでユーザーにとってストレスになることが多いと思うので、そこでできるだけユーザーに考えさせずに対処させてあげること。
そのためには、次のアクションをどうすれば良いかを事前に開発側で定義しておいて、それをエラーメッセージとして示してあげることが重要なんですね。
ソフトウェアの異常処理って、開発者にとっては設計していても全然楽しくないし、工程としてもメインの仕様設計をした後の仕上げみたいな所にあるので、軽視されがちかなと思います。ここでもう一息、気合を入れ直して丁寧に作ってあげないといけないなと思います。
4．まとめ
私にとって印象に残ったポイントを3つほどあげさせてもらいましたが、100個のうちの3個なので、他にも面白いなぁと感じた内容はたくさんありました。
本書を一通り読んで、総じて感じたこととしては、いかにソフトウェアのUIを、ユーザーが人間とコミュニケーションを取る場合と同じ感覚で使えるように設計するか、というところが、ユーザービリティを良くしていくための根本的なところなのかなということです。
とても面白かったので、この本はメルカリで売らずに部屋の本棚に保管しておこうと思います。
それでは。