備忘録｜UX開発で必要になる概念メモ
開発側の要求
ゴールの明文化
ゴールが暗黙の了解になっていたら、チームで明文化して共通認識を持った方が良い
-ビジネスゴール
-製品目標
-ブランドアイデンティティ（概念的な関連性・感情の反応の集合体）
-成功測定基準
-滞在時間（長く回遊して欲しいのか、速く処理を完了させたいのか）
＞自社でUXの理想論はよく語られているが、具体的な測定基準の設定が甘い気がしている。何だか「エモい」ものだとして、担当者の嗜好で方針が決まっている気がする。こんなものは戦略と言えない。
＞上手く質問できるようになること。
ユーザー側の要求
ユーザーセグメンテーションによる仮説立て
- デモグラフィック（人口統計学的属性）で分ける
性別、年齢、教育レベル、配偶者の有無、収入
- サイコグラフィック（心理的属性）で分ける
世界に対する態度、受け取り方をするか
- テクノロジーに対する態度
普段の使用時間、頻度、最新の情報に興味があるか
分ける意味
- 必要な対応の種類に見当がつくようになる
- ニーズ正反対になる場合がある
- どちらかのニーズを切り捨てる
- 2パターンのUIを提供する
＞クライアントへユーザーインタビューをしてニーズを調べようと言った際に、何件・どのようなクライアントに対して実施すべきかを考えた時に、おのずと決まっていった。
ユーザーの一般的な態度や認識の調査
特定の情報を確実に得る（市場調査メソッド）
- サーベイ
- フォーカスグループ
日常生活（コンテクスト）の中でユーザーを理解する
- コンテクスト探求
人類学者が文化や社会を理解する時に使用するメソッドをもとに、スケールを小さくして実施するもの。深い理解が得られるが、かなりリソースを割かないといけない
- タスク分析（ユーザーと製品のインタラクションは、ユーザーが実行している何らかのタスクのコンテクストの中で起こる、という仮説に基づく）
- ユーザーインタビュー（ユーザーに体験談を聞く）
- ユーザーが自然な状態で行うフィールドでの直接観察
＞タスク分析が次項に分類されるのか？とも思ったが、あくまでコンテクストの調査だと読解した。
＞これまで、製品の出来栄えを調査するために、ユーザビリティテストしていたが、ユーザーが自然な状態でプロダクトをどう使うかも合わせて見ていたので、自然とこの辺の調査もちょっとだけやっていたことになるのかもしれない。実際の調査では、明確に分けようとしても、グラデーションになると思う。
ユーザーの行動や製品とのインタラクションの調査
ユーザビリティという言葉が何を意味するかは人によって異なる。
ユーザビリティの意味の例
-ユーザーの代表でデザインをテストすること
-非常に具体的な手法を開発に適用すること
＞結局「製品を使いやすくする」ためのアプローチのバリエーションってことらしい。直感とは合っていたけど、何だかモヤモヤ。
＞あと、ユーザーテストや、ユーザビリティテストって、記事や本によって内容にばらつきがあるので、摂取した情報によって、チーム内で解釈がバラけていくの困る・・・この書籍では「ユーザーの行動や製品とのインタラクションの調査」を指して「ユーザーテスト」という用語を使用している。
以下、ユーザーテストで考えるべきことを整理した。
調査目的・範囲の決定
- 具体的な課題に対する狭い範囲の調査
- 抽象的な課題に対する広い範囲の調査（ブランドメッセージが伝わるか、など）
調査に使用する製品
- 完全に機能している製品
- プロトタイプ（プロジェクトの段階によって使い分ける）
- ローファイ（低忠実度）なモックアップによるテスト
- 完成品と区別がつかないレベルのモックアップによるテスト
- カードソーティング（情報を書いたカードを仕分けるなど）
ペルソナ
調査で得た情報と一致している必要はあるが、見えない部分を自分たちで加筆しても良い。顔写真も勝手に作って良い。架空のキャラクターなのだから。プロジェクトメンバーの偶像になれば良い。
＞よくマーケティングの話やら、ブランディングの話で出てくる「ペルソナ」という用語だが、「うちの製品が想定しているユーザーのペルソナは〜」と話された時に「実際のユーザーは、本当にそんな人かな」と疑ってしまうことがよくある。この違和感を具体化し、調査を追加で行う必要があるかもしれない。（もしくは、自分が一般的な価値観とずれているせいで、多くの人々に共感できないだけかもしれないが。）
個々のユーザーに対する調査時間を長くすると、得られる情報は詳細になるが、調査に含められるユーザーの数は少なくなる。
戦略決定・共有
意思決定
一般的にステークホルダー（各部門のマネージャー）が行うが、戦略が上手くいくかどうかの感覚は、顧客に近い一般従業員の方が優れている。
＞顧客・現場からのフィードバックを、意思決定者までいかにして届けるかは、古今東西、共通の課題のようだ・・・
戦略の共有
一部の重役だけが理解しているだけでは、プロジェクトはうまくいかない。
また、なるべく簡潔に、誰でも分かりやすく伝えることが大事。
（文章量で圧倒することよりも、読んだ人が理解できることが大切）
＞プロジェクトに、途中からアサインされる人は「今北産業」状態なので、3行で説明できるようにしたいものだ・・・。
戦略の見直し
戦略は進化し、洗練されるべきである。
＞大抵の場合、重役に決定権があるので、助言するのは難しいかもしれない・・・
＞「UX開発のために、我々の会社の戦略について、より詳細に理解が必要なので、質問させてください！」と言って質問してみるのが、角を立てずに進める方法かもしれない。
質問して実際のデータと合致していたら、自信を持って次のステップに進めるし、戦略の基になっているデータが古くなった時に、データを提供できる。
戦略段階におけるデザインチームのタスク一覧
ユーザーエクスペリエンスの成功測定基準を明確にする
ユーザーの要求を理解する
ユーザーの一般的な態度や認識の調査をやってみる
ユーザーの行動や製品とのインタラクションの調査の精度を上げる
ペルソナはすでにあるが、上記の調査で精度を上げる
上記のデータで武装した上で、「UX開発のために、我々の会社の戦略について、より詳細に理解が必要なので、質問させてください！」と言ってステークホルダー（マネージャー陣）に取材する。
デザインは、コミュニケーション力が肝よな〜コミュニケーションって難しい・・・
この記事が気に入ったらサポートをしてみませんか？