UXマニフェストを読み解く
こんにちは。@i09sakaiです。
アジャイル開発に携わる方なら見たことがあるであろうアジャイルマニフェストってありますよね。マニフェスト界で、一番参照され続けている素晴らしいものです。
そこで、UXマニフェストもあるのではないかと調べた結果、見つかりました。その内容を見ていきましょう。
UXマニフェスト本文を読み解く
「縦割りの仕事」よりも「協業」を
・UXデザインはチームで一丸となって行うべき
・他のUXデザイナー、開発者（エンジニア）、専門家、ユーザ、ビジネス関係者とコラボレーションすべき
・ユーザのニーズと技術的な制約、ビジネスゴールの重なりがUXである
日本の企業は特に多いと思いますが、全てが分業制。製品に関わる部門として企画部、マーケティング部、開発部、デザイン部、営業部、カスタマーサクセス部などありますが、結構バラバラに動いてませんか？営業は売上をあげることだけ考えたり、開発はユーザの意見を聞かず自分たちの作りたいものを推し進めたり、マーケティングと営業のターゲットユーザが異なったり、、、まずは全関係者を集めて方針、意識を揃えていく必要があります。
「静的なドキュメント」よりも「インタラクティブなプロトタイプ」を
・静的なドキュメントは参照されない、絶えず更新が必要、変更が生じる
・プロトタイプはデザインを伝える最も良い方法で、ユーザがクリック、タップなどしたときに、どのような反応（インタラクション）をするか細かいところまで表現できる
・開発者はプロトタイプがどのようにシステムを作ればいいか教えてくれるので開発しやすい
・ビジネス関係者は本物のようなデザインを見ることができるのでイメージしやすい
・UXデザイナーはデザインがユーザに好感を持ってもらえるのかなどフィードバックをもらえる
・プロトタイプを作るツールがたくさんあるので簡単に素早くお金をかけず細かい部分まで作ることができる
開発目線でいうと、要件定義書、基本設計書、詳細設計書、DB設計書、画面設計書などたくさんのドキュメントを作ります。しかし、関係者はドキュメントを見てもよく分からずイメージが湧いてませんし、認識がずれていることが多々あります。システムが出来上がって実物を見た途端、「あれ？違うぞ」と気付くのです。もう手遅れです。そうならないためにも、プロトタイプを作る必要があります。ペーパープロトタイプでもツールを使ってもいいと思います。ツールは「Adobe XD」, 「Figma」などを使いましたが、Figmaがお勧めです。色んなライブラリが用意してあるので、エンジニアが開発しやすいプロトタイプになります。
「ビジネス関係者のためのデザイン」よりも「ユーザのためのデザイン」を
・もちろんお金を払うビジネス関係者に最終的に満足してもらわなければならない。ただし、関係者が満足するかどうかは、結局ユーザが喜んだかどうかに起因する
・関係者がビジネスゴールを真っ先に考え、開発チームが技術制約を考えるのだ。だから、UXデザイナーがユーザのためを考えてデザインすべきだ。関係者のためにデザインすると、ユーザニーズが抜け落ちる
結構あるあるだと思います。経営層の力に圧し負けて作ったり、開発しやすさだけで作ったりすると、すぐにユーザのことを考えていないシステムが出来上がります。根拠を示して戦いましょう。
「ユーザが欲しがるもの」よりも「ユーザが必要とするもの」を
・ユーザは常に正しいとは限らない、単にユーザに聞くだけでは本当のユーザのニーズは見つからない
・ユーザの課題、目的、不満、動機、業務などについて完全に理解しなければならない
・ユーザに聞いたり観察したりして全プロセスをデザインするべきで、推測はできない
ユーザに「何が欲しいですか？」と聞くと、色んな機能を言ってくれます。しかし、よくよく業務の流れや使い方など聞いてみると、全然必要ないものなんです。なので、＋αの意見として答えてくれる、くらいで聞いた方が良いと思います。むしろ、話を詳しく聞いてみると、「こっちのほうが必要じゃない？」に気づくチャンスになると思います。
「ユーザが言ったこと」よりも「ユーザがやったこと」を
・ユーザ調査やユーザリサーチなどでユーザと対話することがあるが、言われたことをそのまま真に受けてはいけない
・ユーザは悪気なく、無意識にできるフリをする（できないことを認めたくない）、経験のすべてを覚えていないことがある
・ピーク・エンドの法則にあるように人間は経験したことに対して感情のピーク（最高または最低）とその経験が終わった時のことで経験の全体を判断する
・観察が大事でユーザが言ったことと行動に違いがあるときは、そのまま信じないようにする
ユーザビリティテストを実施したときにユーザの言うことを信じてはならないと痛感しました。ユーザビリティテスト実施後、カイゼン活動を行いました。UIを変えたり、営業の説明方法を変えたり、ドキュメントを用意したり、、、。そのカイゼン活動後に再度ユーザビリティテストを行ったときのことです。タスク実施後のインタビューの中で「用意したドキュメントがなくても問題なく実施できたかどうか」を問いました。もちろんタスクを実施してもらっている間は観察しているので、ドキュメントを参照していたことは知っています。そうすると被験者は「不要だった、ドキュメントがなくても実施できた」と言ったんです。そのため、「システム上のどこからその情報を見つけられますか？」と聞くと、「分からない」と。つまり、タスクを実施できた、という終わった時の経験を語っていたんです。
「仮説」よりも「ユーザーのインサイト」を
・ユーザリサーチはユーザのインサイトを引き出す
・ユーザのインサイトは素晴らしいUXデザインの根本となる
・仮説は必ずしも悪いものではないが、始める前か途中でユーザ調査などを行い確認する必要がある
仮説だけ建て、確認・検証していないシステムは多いのではないかと思います。検証せずにシステム作るって、誰も使わなかったときのリスクを考えられていないんです。リスクを考えるなら多少の時間とお金を使ってでも、少し検証すべきだと思います。検証をそんなに難しく考えなくていいと思います。ターゲットユーザに似た知り合いや顧客にちょっとお願いしてみたら、意外と協力してくれると思います。
「ユーザー中心デザイン純粋主義」よりも「現実主義」を
・UXデザインの理想を追い求める必要はない
・UXデザインにこだわりすぎてプロジェクトが上手くスタートしなかったり、費用が異常に掛かったり、進捗が遅くなったりする。しかもUXデザインのプロセスを全部やったからといって必ずしも良いものができるとは限らない（タイミングやビジネスゴールなどによって）
・プロセスや手法にこだわりすぎず、現実的に考えてできる範囲を柔軟に取り組もう、やりすぎるな、純粋主義者になるな
UXデザインって色んな人が色んなプロセスや手法を定義しています。ただ、正解はなくて、臨機応変に対応しなければなりません。しっかり調査・企画段階からお金や時間を掛けられると嬉しいですが、実際にはなかなかありません。短い時間でいかに効率的なプロセスで、状況にあった手法を使うかが大事になってきます。必ずユーザビリティテストは12人にしなければ、ユーザ調査に1ヵ月かけなければ、という頭でっかちなUXデザイナーにならないよう努めましょう！
この記事が気に入ったらサポートをしてみませんか？