ヤフー大阪オフィスで開催されている勉強会 Leap Study に参加してUXの話を色々と聞いてきました。その上で改めてUXの概念についてまとめておこうと思います。
まず UX(ユーザーエクスペリエンス) という定義は認知工学者のドン・ノーマンによって1998年に提唱され、その意味はヒューマンインターフェースやユーザビリティよりも幅広い概念を表すものとして定義されています。
我々の考えるユーザーエクスペリエンスは、その意味を「ユーザー体験」として直訳することが多いですが、これはユーザーが製品やサービスに触れた際に起こる脳内の様々な思考変動から得た結果を体験として捉えたものを指しています。
例えば
- きれいなもの
- 使いやすいもの
- わかりやすいもの
- 欲しいものがすぐに手に入った時の喜び
- クオリティの高いもの
など、これらを結果として判断するまでには、脳内で様々な情報のやり取りが行われます。その結果吐き出されたものが上記のような感情であり、製品サービスに触れる前、触れた瞬間、触れた後に導き出された感情がUXとなります。
当然上記のようなポジティブな結果ではなく、
- きれいではない
- 使いづらい
- わかりにくい
- 欲しい物がすぐに手に入らない
- クオリティが低い
といった結果もUXであり、企業はこれらの結果がより高い良いものになるようUXデザインの研究を行っています。
企業がUXデザインを研究する時に大事なことは、プロダクトがユーザーにとってどうであるか?に着目するだけではなく、ユーザーがそれに触れて体験する全てに対して着目しなければなりません。
例えば、従来のノートパソコンの10分の1サイズでかつ演算処理が断トツに早い性能を持ったパソコンを開発したとしても、ユーザーがそれに対して、小さすぎて文字の入力がしづらければ良いUXとはなりませんし、入力方法をそのパソコン用に開発したとしても、従来のキーボードに慣れたユーザーであれば、新しい入力方法に対して良い感情は中々持たないでしょう。
大事なのは、小さくて性能が高いことではなく、ユーザーにとってどうであるかという部分です。
この例の問題点はユーザビリティの低下にありますが、では、そのユーザビリティの改善を行うだけで、果たして良い結果が得られるでしょうか?
小さくて性能がよく、さらに既存ユーザーにとって利便性が高ければ良いUXが期待できます。しかし、そのパソコンが基盤むき出しであれば良いUXを与えられません。この時の問題は
- 基盤破損の起こりやすさが懸念される
- 見た目が美しくない
この2つです。
プロダクトの実用面だけに注目すれば、単にケースに収めることで解決できますが、そこまでではプロダクトを見たときの第一印象は「新しいパソコン」となります。
これを、更にユーザーの興味を惹こうとするなら、見た目の美しさという感性の部分も重要となります。
ビッグデータとUX
Leap Study の最初のセッションはビッグデータとUXの話でした。
ビッグデータは様々なデータを集めた集合体ですが、技術の発展によりそのデータ収集が行いやすくなっています。特に様々なセンサーの登場により、心電図や体温、脳波をキャッチし、データを蓄積することで感情面の計測が可能となり、それをビッグデータに取り込んでいくことで、UXの改善案を容易に見つけ出せるようになってきています。
ユーザーエクスペリエンスデザイン(UXD)を行う場合、まず問題となるのは人的コストの部分で、何をするにしてもミーティングや作業の時間、意思決定に要する時間といった時間の問題がでてきます。
企業としては製品やサービスをより良くすることがタスクになるのですが、現場の意識と上層部の意識にずれがあるとそこで摩擦が起こってしまいます。
例えばUXDに対する調査は時間がかかりますし、組織の上層部がUXDに対する理解が乏しいと、それを理解してもらうのに更に時間を要します。更に、短期的な利用に対する評価は行いやすいが、長期的な利用は評価しづらいといった問題や、調査を行っても感性面の評価については憶測の判断が多く決定打が無いといった問題があります。
しかし、ビッグデータを利用することでこういった問題を改善できるのも大きな特徴です。
- 調査をビッグデータにすることでレポートがしやすくなり、UXDの説明がしやすくなる
- ビッグデータにすることで、長期的な利用で起こるUXの変化が見られる
- データの取得方法で感性面を取得し見える化が可能になる
更にAIに対するトピックが増えている今日では、ビッグデータの親和性が非常に高く、Apple Watch のように日常で利用するAIは、ビッグデータと組み合わせる事で色々と面白いことができるのではないか? というワクワク感があって興味深いです。
UXのためのチームビルディング
次のセッションはチームビルディングの話でした。
UXDを行うにはひとりで行うのではなく、プロジェクト全員がそこに携わらなければなりません。ひとりで行うと、その人の考え、感覚で決まってしまうことも少なくなく、それを避けるためにチームが必要となります。
しかし、様々な人が集まるがゆえ、人によっての認識が違ってしまうことは普通にあることなので、まず全員の意識を共通化させることを考えます。
- 態度を共通化する
- ユーザーニーズについて共通認識を作る
- 職域横断: 職種ごとのタスク、役割にとらわれない
- 言葉の意味まで共通認識を持つ
- 自分たちの思い込みを払拭する
態度を共通化する
UXを考える際の態度を共通化します。当たり前だけど見落としがちなところです。例えば
- 発言者の意見を否定しない
- できることは前向きになんでもやる
- ユーザー調査を月に一度必ずやる
のようなことを全員の意識が同じであることを確認し、共通化します。また、この中にある「ユーザー調査を月に一度必ずやる」はチームの全員がこれに参加することで、最も重視すべきユーザーニーズは何か?に全員の意識が向きます。
プロジェクトの開発は、時間の経過とともにメンバーのモチベーション低下や他のタスクの進行などにより、それぞれの意識が低下しがちになります。
それを防ぐため、定期的な参加は非常に効果的で、継続した開発には欠かせません。
職域横断: 職種ごとのタスク、役割にとらわれない
職種や役割に依存してしまうと誰かに任せきりといった事になります。それで機能しているうちは良いのですが、「態度を共通化する」で述べた通り、様々な要因によって意識の低下にも繋がります。
それを防ぐためメンバー全員参加のミーティングや、役割にとらわれずに柔軟にタスクを進める手段は、プロジェクト進行の鈍化を防げます。
大事なのは、やること、取り決め、やったことの周知であり、それらを守ることでプロジェクト内での混乱を抑えます。
言葉の意味まで共通認識を持つ
サービスやプロダクトとしての共通認識として、言葉は非常に重要です。
まず、言葉というのは誰もがニュアンスの違いや認識の違いを防ぐためにあります。プロジェクト内でニュアンスや認識の違いがあると、プロジェクトの進行にも影響を与えてしまうので、言葉の意味までをしっかり認識を共通化しておきましょう。
こういうことはアタリマエのことかもしれませんが、プロジェクトの進行中に起こる認識の違いは割りと遭遇します。
そうならないよう、認識と、それの確認は怠らないようにしましょう。
自分たちの思い込みを払拭する
サービスをより良くしようとすると、アイデアが生まれます。しかし、そのアイデアは思い込みの場合もあるので、一旦払拭する必要もあります。
例えば、そのサービス利用者に若い人が少ないと感じ、それを補うためにチームに提案したとします。
そこでメンバーがユーザーインタビューを行い調査を行ったところ、ユーザーが求めたものが文字が小さいので見づらいという答えが圧倒的に多い結果を得ました。
そこで考えられるのは、UIのフォントサイズを上げる事になるはずですが、アイデアを最初にあげた人がアイデアを持ったままだと
「若い人を集めないといけないから、文字を大きくすると見た目が若い人向けじゃなくなってしまう」
という意見を出しかねません。ユーザー調査はユーザーの意見を直接聞けるフェーズで、貴重なフィードバックが得られます。そこでユーザーの求めていない改善を行うのは、良い結果を得ることに繋がらないので、まず自分たちの思い込みは払拭して耳を傾けるようチーム内で認識しておかねばなりません。
UIは細部が重要
最後のセッションはこちらになります。
UIをデザインする場合、ティティールへの配慮はとても重要で、グルーピングや配置の調整を怠ると、ユーザーに予期せぬ解釈を与えてしまい、利用中に使いづらい、分かりづらいという認識を与えてしまいます。誤解を与えないUIは非常に重要です。
まとめ
UXの話は色々と考える点や、見る視点など人によって差があるので、メンバー同士で話し合って認識を合わせることが重要です。その上で、デザイナーはどこに注意を払うのか。デベロッパーはそのデザインをどうやって形にし、ユーザーにストレスを与えないようにするには、どうすれば良いかなどを考える事が専門的な分担になってくると思います。
UXDで重要なのはチーム内のコミュニケーションで、これがなければ始まらないと考えています。
より良いプロダクトにするためにチーム全員で考える。これがUXDにとって一番重要なことではないでしょうか。
今ご自身が所属しているチームは、良いコミュニケーションが取れていますか?
Comments