UIデザイナーが「UX」についての質問に答えるための解答集 #1
自社開発でUIデザイナーをしている。すると、UIとUXの区別も付かない人にUXについて説明する機会が多い。そこで、個人的に解答集を作った。誤りがあるかもしれないが、専門領域ではないので大目に見てほしい…
UXの概要
UXって何？
製品が開発されるとき、「その製品が何をするものなのか」に関心が行ってしまいがちだが、「どのように機能するか」を考えて設計しないと実際うまく機能しない。これを、ユーザーエクスペリエンスと呼ぶ。
なぜUXが重要？
一早く市場に参入し、製品を多機能にすることで、一時的に他社との競争で優位に立とうとした企業が多かったため、世の中の製品は複雑化してしまった。（特にwebは顕著）最近は競争上の持続可能な優位性を意識する企業が増えたので、ユーザーエクスペリエンスが流行っている。
以下、得られる効果の一例。
- 顧客ロイヤリティ
- 投資利益率 Return on Investment（ROI）
- 通常、お金で測る。
- コンバージョンレート Conversion Rate（CVR）
サイトがどれだけ効果的にビジネスゴールを達成しているかを測定
- 従業員の作業効率向上
- 時間・精度
- モチベーションの向上・従業員の定着率
UXが成功していると言えるには何が必要？
- 効率の向上
- 人がより早く作業できるようにすること
- より少ないミスで済むようにすること
そのために考慮すべきことは？
- ユーザー中心のデザイン User-Centered Design（UCD）
- 製品開発のあらゆるステップでユーザーを考慮に入れる
- 時間や費用のために妥協しなくてはいけない場合、ユーザーエクスペリエンスを構成する要素を分解し、複数の観点から見て、妥協の影響を把握すること
＞妥協してリリースした結果、ユーザーに使われないのでは、妥協してリリースした分が無駄になる。これは思い当たる節があって辛い話。潤沢な工数があるわけではないので、「上手く妥協できるようになる」ことがチームに必要なスキルだと思う。
UX開発の工程
5段階モデルとは？
UXの向上を考慮した開発において、必要な工程を5つに分けたモデル。
一度で全てを理解してもらうことは難しそうなので、直近は次の部分だけを強調することにする。
段階が上に行くにつれ、問題の抽象度が減り具体性が増していく。各階層は下の層に依存している。（上下が噛み合っていないとプロジェクトは脱線する）各階層で使用できる選択肢は、下の課題で下した決定によって制約を受ける。
上の階層で下の階層での決定を、再評価する結果になることがある
具体例
下の階層からの制約を理解していなかった事例
まず、事業部で要件を定義するのがスケジュール通りに行かず、骨格や構造のデザインを先に進めていた。案の定、焦る気持ちを満たすための自己満足にしかならなかった。他の作業をして過ごすべきだった。
要件段階と構造段階の齟齬の事例
しばらくして要件が来た。構造の設計が半分行われた状態で。ここで、構造の設計を直して事業部を説得する作業に骨が折れた。
要件の切り分けの失敗事例
また、本来であれば、事業部から出た要件を整理する必要があった。今思うと、要件が多すぎて、1つのプロジェクトでやる量ではなかった。せめて半分に分けるべきだった。エンジニアにもっと早く入ってもらうべきだった。
要求定義の失敗事例
要件が出てきた時、ユーザーニーズの仮説を検証しないまま、先に進んだ。結果、リリース後、ユーザーから多くのクレームが寄せられた。CVRも一時的に落ちた。
事業部もデザイナーもエンジニアも総出で火消しに走った。どんなクレームが来るか想定ができていれば、軌道修正ができたかもしれない。数字がどのくらい落ちるか予想できれば、焦って火消しをして、プロダクトがぐちゃぐちゃにならずに済んだはずだ。もう、このぐちゃぐちゃをどうするかで、皆で頭を抱えている。
もっと早く、この概念を知っていれば・・・もしくは、この概念を知っている人材を確保できていれば・・・と悔やまれる。
代償は大きかったが、人材の観点から見れば、この失敗を経験した人がチームにいるので、次はもっとマシになるはずだ・・・
この記事が気に入ったらサポートをしてみませんか？