「UX」という言葉が市民権を得始めてから数年、「UXが〜」「UXを上げるために〜」という枕詞で語られることが増えてきた。
User Experience == ユーザー体験をウェブやアプリで重要視するのが正義だと言われているのはなぜなのか、そもそも「UX」ってなんなのか、で、結局どうすればいいのか、整理してみた。
なんかISOで定義されているらしい
UXという言葉の定義はすでになされていて、
製品、システム、サービスを使用した、および／または、使用を予期したことに起因する人の知覚（認知）や反応
ということになっている。この言葉の定義からすると、「UXデザイン」とは、「製品、システム、サービスをデザインすること」ではなく、「それを{使った || 使う}人が感じることをデザインすること」ということになる。それはどういうことか。
「UXデザイナー」には気をつけろ; UX != UI
「こんにちは！UXデザイナーです！」と言う人のなかには、UXデザイナーではなく UIデザイナー の人がいる。
HTMLやCSSの書きかたを知っている（だけの）人が「フロントエンドエンジニアです！」と自称するケースを知っている人には、同じようなものだと言えば伝わるかもしれない。
ユーザー体験はUIに触れる前から始まる。ポケットからスマートフォンを取り出す、Googleで何かを検索する、検索結果のなかから自分が求めているであろうものを選ぶ。これらの所作がすべて「UX」に含まれると言われる。
もっと言うと、「それをしなければいけない状態」に陥った段階からUXは始まるだろうし、ウェブサイトやアプリで何かの目標を達成した１ヶ月後にそのことを思い出すのもUXだ。
カスタマージャーニーマッピング とか「UIデザイン云々以前のお話」たちが、 UX には含まれるのだから、「デザイナー」という単語に引きずられて、UI == UXになっているケースには注意が必要だ。
ユーザーの「なんとなく」を知っていて、言語化できること
どんなにHTMLがセマンティックで、モダンなレイアウトで、美しい写真やイラストを使っていて、操作性の高いUIでも、売れないときは売れないし、使ってもらえないときは使ってもらえない。そんなものである。
営業で交渉がうまくいかなかったときといっしょで、ユーザー == 顧客が 「なんとなくイラッとした」「なんとなく飽きた」「なんとなく違う」 という印象を抱く場合（つまりこれがUXなのだが）、その原因を具体的に言語化するのは難しい。
それは ウェブサイトやアプリの名前 だったり、 色合い・フォントや言葉選び・全体的な雰囲気 のような何がいけなかったのか特定が難しい抽象的な要素だったり、 その時気分が乗らなかったから のような、もう開発者にはどうしようもない1原因だったりする。
そういった一般的な問題とその解決策を知っていて、UIデザインや開発の段階で組み込むのが「UXデザイン」のひとつの仕事だと言えるだろう。
UXでは、事業の目標は達成できない場合がある
東京都はゴミの分別が割とめんどくさい。市区町村によって異なっていたり、ルールが複雑化していてノーヒントで正確な分別をするにはコストがかかる。
ゴミの分別をするためにUXデザインを導入して、インフォグラフィックを用いたわかりやすいダイアグラムで分別の仕方を理解してもらったり、ゴミを正確に分別して捨ててくれたら何か特典があるとか、いくつかの問題解決策とそれを実現する手法を提案・実施することは可能だ。
けれど、根本的な問題解決は そもそも分別なんかしなくていいことにする かもしれない。そうなると、事業の目標（ユーザーにゴミの分別を啓蒙すること）は達成されない。UXの最大化と、事業目標の最大化は、天秤にかけなければならない場合があるのだ。
良いデザイン != 良いUX
「なぜ楽天などのECサイトはごちゃごちゃしているのか」のように顕著な例がわかりやすいが、必ずしも美しく整理されたUIが最上のUXを導くとは限らない。
モダンでクールなデザインは、ユーザー体験ではなく開発者の満足度を向上させているだけの場合もあることを気をつけたい。[^モダン]
phpMyAdminを使いなれたphperにとっては、いまさらあの画面が例えばフラットデザインになったら気持ち悪いだろうし、ヴィレッジバンガードが蔦屋書店みたいになったらそもそも 価値 が変わってしまう。UXを「デザイン」する場合は、そのプロダクトの方針を充分に理解していないといけない。
とはいえ、「いまどきこんなデザインのやつを作るのかよ...」とモチベーションが下がったときに、自分を納得させるには不十分だ。そういうときはどうしたらいいのだろう。（後述）
一貫性のための定数化、コンポーネント化
UXを損なわないための最も簡単な手法として、 一貫性の確保 が挙げられる。書いてあることが微妙に違うとか、こことここで操作が微妙に異なるとか、そういった「なんとなくもやっとする」要素を排除するために、開発の着手段階であらかじめ足並みを揃えられるようにStringを定数にするとか、コンポーネントを用意しておくとか、そういったことが意外と価値になる場合がある。
結局どうすればいいのか
「クライアントが赤がいいと言ったから」は、制作会社のデザイナーあるあるだ。（俵万智の詩ではない。）
たとえばウェブのUIなら、それぞれの要素に意味を持たせるのがUXデザインのひとつだと言われている。
- この情報はユーザーにとって必要なのか？
- ここに配置することに何の意味があるのか？
- それをユーザーはどうしたらいいのか？（ユーザーにどうしてほしいのか？）
- そしたらユーザーはどう思うのか？どうなるのか？
ここまで考えたときに、「そもそも色の問題ではない」とか「これをやること自体に意味がない」などという結論に至ってしまうことがある。この場合に引き合いに出される 「UXハニカム」 という概念がある。
- Useful
- Usable
- Findable
- Credible
- Accessible
- Desirable
面倒でも、一度これらのすべてにチェックが入るか試してみるとよい。大抵の場合（私の場合、という意味だが）、３つくらいしか入らない場合が多いし、その３つも無理やり解釈したパターンだったりする。
これらを解決するために、「UX」の意味を理解している上司やマネージャがいると心強い。彼らは「そもそも論」に立ち返って戦ってくれるかもしれないし、折衷案を受け入れてくれるかもしれない。
尤も、
UX自体のゴールは存在しない。需要は常に変動しているし、トレンドも変わる。競合は常に現れるし、そもそも開発者やプロダクトオーナーの気分も次の日には変わっているかもしれないから、いまそのことに悩んでいても別の問題・課題がまた見つかる。
ウェブやアプリの寿命は（多くの場合）短い。理想を突き詰めてリリースできないのは本末転倒で、「悪くない」「迷わず目的を達成できました」くらいの 「UX」 でひとつの節目を迎えられるくらいのデザイン・開発を進めて、後日に、いわゆる「PDCA」に注力する余裕を持つことができるのが、UXの「バランス」なのではないだろうか。
-
どうしようもないかというと実際にはそうではなくて、「すぐに戻ってこれるようにする」「やろうとしていたことを思い出せるようにする」「気分が乗ったときにすぐにできるように動線を確保しておく」などが解決策になるのだろう。 ↩