天ぷらmp4

UX成分多めにしたい。

「UX本読書」一冊目 誰のためのデザイン?

今年は去年より多めに自分の時間を持とうと思っています。

せっかくの時間なので今まで読めていなかったUX関連の本を読み倒したいと思っている今日この頃です。

といっても、ただ読んでも面白くないし身にもならないので読むたびに感想や、個人的なまとめを書こうかと思います!

 

さっそくですが、最初の一冊目

誰のためのデザイン? - 認知科学者のデザイン原論

(自分で所有している書籍をパシャリ)

f:id:golbaser-neko:20170104112813j:plain

この本を最初に読んだのは2013年頃、UXの基本を教えてくれた私の上司が勧めてくれました。

簡単に説明するなら、この本は「使いやすいデザインとは何か?」ということが書かれたもので、デジタルアナログ関係なく人間が使うありとあらゆる物の使いやすさについて書かれたものです。

この本が出版されたのは1988年のこと。今から数えるとおよそ28年前の本です。こんな古い本が現代のデザインに通用するのか?と思われそうですよね。

私も読む前はそう思っていたのですが、その心配はまったく杞憂でした。この本の内容はUXの世界でいえば算数のようなものです。1+1 = 2 が100年経っても変わらないように、この本の内容はUXにとってまさに原点であり基本の内容だったのです。

UXの原点

今回は、初めてこの本を読んでから3年経ち、初心も忘れてるだろうということで読み直しました。

読み直して最初に思ったことが

「UXの原点がここにはある!」

ということでした。

この本を読んだ後もデザイン関連、UX関連の本をいろいろ読みました。しかし、それらの本に書かれているUXの原則みたいなものがこの本にはすべて書かれていたのです。もちろん新しい本は最新のノウハウだとか、新しいシステムに最適化された内容なのでそれはそれで多くのことを学べますが、基本を学ぼうとするときにこの本に勝るものはないと思います。

よいデザインの原則

この本の第1章から説明される「よいデザインの原則」は主に手に取って使う道具に向けて書かれたものですが(そもそもWebなんて無い時代に書かれた本だし)、Webやシステムにも十分通用します。

可視性

現在のシステムの状態だとか、ステータスを分かりやすく見えるようにしておくということです。分かりやすくというのは、例えばWebで買い物をしようとしたときに「購入エラー」とだけ表示されるとユーザーには何が問題なのか見えません。「クレジットカードの期限が切れています。クレジットカードの有効期限をご確認ください」と表示されればユーザーにも何が問題だったのか見て理解できるようになります。

よい概念モデル

ここは少し難しく私も何回も読み直しました。

そもそも概念モデルとは?というと、例えば自転車の車輪を見たときに当然こう動くよね、と私たちが想像するそれが概念モデルということだそうです。もう少し例を出せば、ボタンを見れば押せると想像することや、消しゴムや消しゴムのようなマークを見ると何かを消すものだろうと考えるそれが概念モデルです。

なので、よい概念モデルとは見た目や経験からその道具やシステムがこう動くだろう、こう使うのだろうという予想を裏切らないようなデザインないしは説明を提供することと、その処理が実際に行う処理を明確に説明するデザインになっていることで実現できると理解しています。

例えば、パソコンなどには「ごみ箱に入れる」という機能があります。「ごみ箱」に入れたファイルは後から取り出すこともできますし、削除することもできます。これは私たちが「ごみ箱」に対して持っている概念モデルとも一致するのでよい概念モデルということができます。逆に「ごみ箱に入れる」という機能にもとに戻す機能が無かったとするなら、私たちが持っている概念モデルに反するので、悪い概念モデルということになります。

よい対応づけ

概念モデルの説明と少し重複しますが、ある要素をこう動かしたら別のある要素がこうなるだろう、という予想を裏切らないことでよい対応付けを実現できます。

例えばブラウザ右に表示されるスクロールバーを上下に動かすと上下に画面が移動します。これが左右だったらどうでしょうか?スクロールバーを上下に動かしているのに左右に移動したら混乱してしまいます。

フィードバック

考え方はこれが一番簡単かもしれません。行った操作や動作に対して適切に明確にフィードバックを返すということです。

ある動作に対して、エラーが発生すれば明確にエラーメッセージを返し、成功すれば成功したことを表示させます。

言うは易く行うは難し

簡単に、よいデザインの原則の部分を紹介しました。

こうしてみるとそこまで難しい話ではありません。むしろ至極当然のことのように感じるかもしれませんね。

ただ、「言うは易く行うは難し」です。私もUIやらUXやらの仕事をするようになって4年ほどの若輩ですが、この原則に反したデザインを何度も見てきましたし、自分で作ってしまったこともあります。

可視性やフィードバックなどは簡単だと思われるかもしれませんが、よく軽視される部分でもあります。操作のエラーが発生したときに適切なエラー表示をしないなどは本当によくあることです。

私が、ある某大手のショッピングサイトでアカウント連携という処理を行なった時のことです。画面上では「成功しました」と表示されました。しかし、実際に連携を確認すると「連携を確認できません。連携をする設定はこちら」という表示が出たのです。私はアカウント連携を5回ほど繰り返しましたが状況は変わらぬままでした。問い合わせをしたところ実際には処理が失敗しているということでした。ようするにエラー表示をすべきところを画面上では成功しました!と出るようになっていたのです!!

可視性やフィードバックはなぜ軽視されるのか

これはWebサイトやシステムを作ってきた経験からになりますが、開発の現場で1番優先されるのが「仕様書にある機能を実現すること」だからです。

機能を実現することが最優先ですし、むしろそれさえ達成させればOKですから、当然可視性やフィードバックなどは二の次になるわけです。

あとは工数の問題です。可視性やフィードバックを考えたり提供することが簡単だとしてもそれは1つ2つの場合です。実際に開発してみると数が非常に多いので、想像以上に工数を圧迫します。工数を考える人がそういった工数まで考慮していない場合がほとんどですから当然十分な可視性やフィードバックを確保した開発などできないのです。

間違った概念モデルを作り出してしまう

よい概念モデルもたまに大きくずれてしまいます。

1からデザインするというのは難しいものです。客観的には概念モデルをちゃんと判断できる人間でも、1から自分で作ってみると概念モデルを無視したものを作ってしまうというのは何度か見てきました。

これはこの本で明確に説明されていないのですが、使いづらい道具でも人間は勝手に概念モデルを作ってしまう、という内容があり、これが答えじゃないかと私は思っています。

概念モデルというのは未知のものが現れた時に勝手に作られてしまいます。使いづらいということはある意味得体のしれない動きをする、想像できない動きをする、ということですから、そういう未知のものに対して勝手に概念モデルを作ってしまうのです。

例えば非常に使いづらいシステムがあったとして、それが業務などで使わざるを得ないものは時間とともに勝手に概念モデルを作ってしまいます。そして、UXの改善という形でシステムを使いやすくしたときに悲劇が起こります!そのシステムに対する概念モデルは使いづらく作られた方の概念モデルなので、逆に使いづらい!という評価をされてしまうのです。

話を戻すと、システムのデザイナーにも同じような現象があるのではないかということです。わかりづらいデザインを作っていたとしても、自分でデザインを進めていくうちに間違った概念モデルが生成され問題を認識できなくなってしまうのではないかと。

上記の話は、あくまで私個人の考えなので話半分に読んでいただければよいですが、自分で作ったデザインを客観的に見れなくなるのはよくあることです(個人だけでなくチームでもそうです)。

じゃあどうするの?

さて、じゃあどうすれば良いのか?

ということについては、この本には「こうすべきだ!」という記述はあっても「こうやれば上手くいく!」という記述はありません。「こうすべきだ!」というのは原則だったり、理想だったりしてそこに到達する方法ではありません。そういった内容についてはまた後々ブログで書く「リーンUX」とか「デザイニングインターフェース」とかの紹介の時に書こうと思います。

デザイナーに対する警告

 この本にはデザイナーに対する皮肉だとか警告が多く含まれています。とはいえ日本のIT業界だとデザイナーらしいデザイナーもいない状態で開発することは日常茶飯事です。そう考えると画面を作るエンジニアにも参考になる警告かもしれません。

個人的に好きな警告を1つだけ紹介すると

「デザイナーは典型的なユーザーではない、また顧客=ユーザーとも限らない」

というものがあります。自分のデザインを客観的に見るのは非常に難しいことです。勝手に概念モデルを作ってしまうし、何より作ったデザインを知り尽くしているので知らない人がどう感じるかを想像することが難しいのです。

「顧客=ユーザーとは限らない」というのは、デザインを作ったとしてそれを見て承認を出すのは誰か?ということです。それは例えば上司だったり、社長だったり、チームメンバーだったりします。その人たちが必ずしもユーザーなのか?というのは慎重に判断しなければなりません。現代的な言葉を使えばそのシステムを使うペルソナとデザインの承認を出す人たちは一致するのか?ということです。一致しないのであれば実際のユーザーに見てもらうことを考えなければいけないかもしれません。

 ユーザー中心のデザイン

「ユーザー中心のデザイン」というと最近出てきた言葉のように感じてしまうのですが(IT業界だからですかね。。)、28年前のこの本にはすでにこのテーマが出てきます。

ユーザー中心のデザインについて簡単に説明するなら

「ユーザーが本当に必要としていることを快適に行うことができるデザイン」

ということだと思います。

この本のタイトルにも「誰のためのデザイン?」とあるように、結局デザインというのはそれを使う人、ユーザーのためにあるよ!ということですね。

この本全体が結局は「ユーザー中心のデザイン」をしよう!という呼びかけであり基本を教える本になっています。

まとめ

 さて、この本を読んで感じたことや自分が復習したいことなどを中心に書いてきました。そのため人が読んだときにどうかと言われるとどうかなあ?と思う分けですが、正月早々ということでご了承ください。

ただ、この本自体は非常に良い本です。デザイナーや画面設計をしなければならないエンジニアはもちろん、物づくりに携わるなら是非立場や役職問わず読んでほしいです。

UX的観点から言うと社長とか経営陣とかそういうレベルの人たちにも是非読んでほしいですね!

本書の中にもありますが、デザイナーだけでよいデザインは実現できません。理解のない経営陣や上司による命令や、ビジネス的システム的事情、さらにはデザイナー自身にによってもデザインは歪められてしまいます。それを無くすにはそれぞれが「ユーザー中心のデザイン」について少しでも理解していることが重要だと思います。

長々となってしまいましたが、「UX」とか「ユーザー中心のデザイン」について良くわからんけど何から勉強して良いかわからない!と思ったらこの本をまず読め!ということで締めたいと思います。