社内向けに作った「UXデザイン用語の体系的な整理」メモを公開します
こんにちは。クラウドワークスでスマホアプリチームのPO（プロダクトオーナー）をしている @yuta3594 です。
以前は専任でUXリサーチャーをやっていました。最近、自分がつくった社内ドキュメントを整理していたのですが、ちょうど3年前に作ったものが誰かの役に立ちそうだったので、noteで公開することにしました。
（誰かの役に立ちそうと言っても、UXデザインについて説明する時にこの資料を使えばラクそうだなと、主に自分のために公開したかっただけなのですがw）
実際に自分で使ったことのある手法しか取り上げてないので、「いやいや他にもこういうのあるよ！」や、別に体系的に整理されてなくない？などのツッコミも多数あると思いますがご容赦ください。
以下、ほぼコピペです。
タイトル：UXデザイン用語の体系的に整理してみた
目的
個人として、チームとして、UXデザインに関する理解を高めるため
想定読者
デザインGのメンバー
デザインGと一緒に活動することになった人
UXデザインについて知りたい人
はじめに
UXデザインは意味が広く、何とも説明しづらい面があります
一つの手法として「人間中心設計（HCD=Human Centered Design）」があるので、主にこの説明をしていきます
最後に、デザイン思考との違いや、イノベーションについてコラムも添えます
HCDの概念図
Research（リサーチ）
HCDでは、まずユーザーを知ることから始まります。
ユーザーを知るために、ユーザーリサーチを行います。
ユーザーリサーチには、定量調査と定性調査があります。
定量調査
一言で言えば数字。
応募率がどうなってるとか、報酬確定率がどうなってるとか
何がユーザーにとって価値なのか（What）
がわかります。
定性調査
一言でいえば生の声。
なんで副業をしたいのか、どんなシーンでアプリを使っているのか、とか
なぜそれがユーザーにとって価値なのか（Why,How）
がわかります。
クラウドワークスでは、デザイナーが主導して定性調査を行い、PO主導して定量調査を行い、それらを合わせて施策を検討しています。
定性調査で採用することが多い「インタビュー」と、その後の「分析」について下記で解説します。
エスノグラフィや、フォーカス・グループなど、まだ試せていない調査方法もいくつかあります。
■ インタビュー
クラウドワークスではデプスインタビューを採用することが多いです。
インタビューの種類は コチラ。
ユーザーと1対1で90分程度話すことで、1人について深く深く聞いていきます。
広く薄く話を聞くよりも、狭く濃く聞くことにしてます。
それにより、行動や考えの因果関係が明らかになります。（ここが超重要）
因果関係がわかることで、ソリューションの検討が可能になります。
例えば、
「水が欲しい」と言っている人がいる
「飲むため」なのか
「手を洗うため」なのか
「花にあげるため」なのか
で、提供するソリューションが変わると思います。
「手を洗うため」なら、洗ったあとに手を拭くタオルも一緒に提供してあげるのが親切ですよね。
なんなら、手を洗うためなら、水以外のソリューションもあるかもしれない。
■ 分析
ただインタビューをするだけでは、膨大な発話データが有象無象としたままです。
行動や考えの因果関係を明らかにするために、分析をおこなって整理します。
そのために 「KJ法」 を採用することが多いです。
「上位下位関係分析」などもあります。
Define（現状の明確化）
ユーザーの情報が得られたら、次に対象とするユーザーを定義します。
チームとしてどんなユーザーのためにプロダクトを提供するのか
そのユーザーが価値だと感じるものはなんなのか
を定義して、チーム内で共通認識を取れるようにします。
具体的な手法として「ペルソナ」や「As-Isカスタマージャーニーマップ」等があります
■ ペルソナ
インタビューで抽出したユーザーの特徴を集めて、擬人化したものがペルソナです。
ペルソナは、プロダクトを届け先となる具体的なユーザーです。
開発チームでは、全員で一つのプロダクトを作っていても想定している対象ユーザーは意外とバラバラだったりします。
だから、議論がずれたり、アウトプットがずれたりします。
チームで共通の対象ユーザーイメージを持つためにペルソナは有効です。
■ As-Isカスタマージャーニーマップ
カスタマージャーニーマップは、以下CJMと略します。
CJMは、ペルソナがプロダクトを通してどのような体験をするのかを可視化したものです。
「As-Is」と「To-be」の2種類があり、As-Is=現状、To-be=理想を意味します。
まずは現状の可視化をするために、As-IsのCJMを作成します。
これにより、ユーザーやプロダクトの課題がわかるようになります。
主に、
「行動」
「思考」
「感情」
が可視化されています。
Design（体験を描く）
ユーザーにとっての価値を定義できたら、理想の体験を描きます
ただ画面上のデザインを考えるだけでなく、 ユーザーがどんな体験ができるか を描くことが重要です
具体的な手法として「6up sketches」「To-Beカスタマージャーニーマップ」「プロトタイピング」等があります
■ 6up sketches
ユーザーが、プロダクトを使ってハッピーになる6コマ漫画を書くことで、目指す体験を可視化します。
6コマという少ないコマに収めることで、体験をシャープにできます。
■To-be カスタマージャーニーマップ
CJMの「To-Be（理想）」版を作ります。
6up sketchesよりも、より詳細な体験を描くことができます。
まず6up sketchesをやって、それをベースにTo-BeのCJMを作ることもあります。
■ プロトタイピング
実際に触れる画面を作ります。
「Prototype is a Question」、プロトタイプとは問いであり、 何を検証したいのか を明確にする必要があります。
検証したいことを検証するために、次のフェーズでTestをします。
Test（評価）
体験を描いたら、次はユーザー自身に良し悪しを評価してもらいます。
開発者ではなく、ユーザー自身に評価をしてもらう目的は、
ユーザーにとっての価値を届けられているか
ユーザーの能力で使うことができるか
を検証できるためです。
よくやるのは「ユーザビリティテスト」です。
■ ユーザビリティテスト
ユーザーにプロダクトを触ってみてもらうことで、ユーザビリティ評価を行います。
評価指標は3つあり、これらを多角的に見ていきます。
有効さ：目標を達成できるか
効率 ：スムーズに達成できるか
満足度：気持ち的にはどうか
一般的には「会員登録して、開発の仕事に応募してみてください」というタスクを設定して、実際にやってみてもらい、それが達成できたか（有効さ）、どのくらいスムーズに達成できたか（効率）、どう感じたか（満足度）を観察・ヒアリングします
「デザイン思考」とは
デザイン思考という言葉があります。
HCDがUXデザインをする具体的な手法であるのに対して、デザイン思考はその精神や思想です。スクラムが具体的な手法で、アジャイルが思想であるのに似ています。
ユーザーのリアルな課題、気持ち、体験などの観点を、デザインだけでなくあらゆる場面で使っていこうね、という感じです。
[コラム]HCDやデザイン思考で、iPhoneは生まれるのか
スティーブ・ジョブズがユーザー調査をしないのは有名な話です
「顧客が今後、何を望むようになるのか、それを顧客本人よりも早くつかむのが我々の仕事なんだ。」
ヘンリー・フォードも同じようなことを言っています
「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」
デザイン思考が世界中で徹底されていたら、未だに私たちは速い馬に乗っているのでしょうか。
HCDやデザイン思考にも、深さがある
もし、浅いデザイン思考が世界中で徹底されていたら、未だに速い馬に乗っていたかもしれません
ですが、「速い馬が欲しい」というユーザーの声を聞いても、何を読み取るかで結果が変わります
「速い馬が欲しい」と言われて、そのまま「速い馬を提供する」のは浅いデザイン思考家です
「速い馬が欲しい」と言っているならば、その裏にあるのは「速く移動したい」であり、その裏には「速く移動することで〇〇したい」とかもあるかもしれない。そうやって、ユーザーの声から本質的な欲求を見出すのが深いデザイン思考家です
ユーザーをめちゃくちゃ観察し、めちゃくちゃ深くまで掘り下げることで、iPhoneを作ることは可能かと思います
着想には「問題発見型」と「問題提起型」の2つがある
しかし、どちらかと言えば、ユーザーを深く深く観察していたからといって、iPhoneの発明は難しかったでしょう
iPhoneや自動車以前のユーザーの欲求と、iPhoneや自動車とは、あまりに大きい乖離があるからです
そのため、時には着想をユーザー以外に求めることも重要です
基本的にデザイン思考の着想はユーザーです。ユーザーを観察して、 客観的に 欲求や課題を見出し、それを解決するプロダクトを提供するのが本来の姿です。これは 問題発見型 と言えます
しかし、ときには 問題提起型 がイノベーションを起こします。ユーザーは課題とも思ってなかったけど、起業家が 主観的に 「これが課題だ！」または「こうあるべきだ！」と問題提起をして、それを解決するプロダクトを提供する
ジョブズはiPhoneを発表した際、「世の中のスマートフォンはスマートじゃない」と言っています。固定された物理キーボードのせいで、まったくスマートじゃない。これやばくない？と問題提起しています。
さらに、「誰がスタイラスなんて使いたがる？」とスタイラスにも問題提起。「最強なのは指だよね」とソリューションを提案しています
扱えるテクノロジーを以て、問題提起をすることもできるし、既存テクノロジーでもベルガンティ教授の「意味のイノベーション」のように物事の意味を捉え直すことでも良いかもしれません
問題提起型でも、デリバリープロセスにおいては、HCDは有効である
問題提起型であれば、主観的に問題提起をして、独善的にプロダクトを提供すればいい…という訳ではありません
あくまで、着想時点において主観的に問題提起型で課題設定をするのがアリなだけで、
デリバリープロセスにおいては、HCDにて、ちゃんとユーザーに使われるプロダクトになっているかを保証しながら開発をする必要があると考えています
この記事が気に入ったらサポートをしてみませんか？