現場からのニュース：誰が、どのようにUX Researchで品質管理手法を使用してIT製品を開発したか。 パート1/6

記事のすべての部分： 1 | 2 | 3 | 4 | 5 | 6

---

前の記事「 UX Researchの定性的方法 」では、UX問題を解決するための高品質の方法論（インタビュー、観察、民族誌）の効果的な使用に関する実践的な推奨事項を示しました。 そこで、どのような状況で定性的な方法論を使用したのか、そしてその結果は何かを理解するために、外国人の同僚の経験に目を向けることにしました。



素敵な写真をくれた素晴らしい著者に感謝します。



なぜ外国企業について話しているのですか？ そこでの高品質の方法論は、長い間エキゾチックであるのをやめ、ITプロダクトロジストの兵器庫に入りました。 彼らの経験を研究することは、UXの分野におけるこれらの方法の機能と制限をよりよく理解するのに役立ちます。 これを行うために、独自の調査を実施しました。



作業はいくつかの段階で行われました。 まず、IT製品の開発を専門とする外国企業が選ばれました。 西洋市場にはそのような企業がたくさんあることは明らかです。 すべてを特定したり、最も有名なものだけを選択したりする目標は設定していません。 なんで？ 中小企業がどのプロジェクトに取り組んでいるのかを見るのはもっと面白かったです。 サンプルには大規模で有名な会社があります（たとえば、 CooperやBlink ）。



私たちは長いリストを作成し、企業が基準に準拠しているかどうかをチェックし始めました。「About」タブとポートフォリオの情報を注意深く調べました。 4つの主要な基準がありました。

1. これは、請負業者として機能する独立した会社でなければなりません。 大企業のUX部門は除外しました。 もちろん、そこで研究を行います。 品質管理方法が使用されていますが、これはまったく異なる話です。 そして、予算は異なります。
2. 会社は、IT製品の開発のためのサービスを提供する必要があります。 必ずしも「完全なサイクル」ではありません。スタッフがプログラマーであるとは限りません。
3. 会社は質の高い方法論（インタビュー、観察、民族誌）を使用する必要があります。 これらは必ずしも兵器庫の唯一の方法ではありません。
4. 会社のウェブサイトにはケースが必要です。 ここが最も問題でした。最初の3つの基準に一致した企業もありましたが、サイトのケースの代わりに顧客のロゴしかありませんでした。 ロゴは、たとえそれらの多くがあったとしても、作品の本質を理解することを許しません。

企業の能力レベルを評価しませんでした。品質の方法論を使用した経験を分析するために、私たちのタスクに最も適したものを選択するだけでした。 その結果、15社を選択しました。

1. ReD Associates （デンマーク、米国）
2. Experientia （スイス、イタリア、シンガポール、イギリス、中国、台湾）
3. AnswerLab （米国）
4. クーパー （米国）
5. スポットレス （英国）
6. U1 （オーストラリア）
7. TecEd （米国）
8. ボウマスト/ニックボウマスト （アメリカ）
9. ヘッド （イギリス）
10. The Understanding Group （アメリカ）
11. 点滅 （米国）
12. Prime Motive （オーストラリア）
13. 閲覧室 （イギリス）
14. CXパートナー （英国）
15. RMA （英国）

私たちの目的にはこれで十分でした。 第二段階では、最初のケース分析を開始しました。 そして、ここで深刻な問題が待っていました。 企業は内部のキッチンを公開することに消極的であり、ユーザー分析とその結論に関する調査結果をまったく共有したくありません。 それは理解できる：ケースの全体的な焦点は結果にのみあります。 顧客を引き付ける必要があります。 そのようなケースは私たちに合わなかった。 私たちはクライアントではありません。彼らと仕事をする方法と原則に興味があります。結果については後で説明します。



ケースには3つの問題がありました。

1. ケースの説明では、一般的な情報のみ。 お客様はどのような特定の問題を抱えていましたか？ それを解決するために何をしましたか？ 明確ではありません。 すぐに結果と一般的な用語について話します。
2. ユーザーデータを収集する方法は説明されていません。 「私たちはユーザーを勉強しました」または「ユーザーと話しました」というフレーズの後ろに隠されているものは何ですか？ 使用された方法：調査、フォーカスグループ、観察、インタビュー、または一般的なWeb分析？ 正確に定性的な方法が使用されたケースを選択することが重要でした。 定量的方法は私たちには興味がありませんでしたが、場合によっては定性的方法論を補完することができました。
3. データがどのように使用されたかは明らかではありません。 たとえば、医師の勤務時間の勉強は、病院スタッフ向けのアプリケーションの開発にどのように影響しましたか？ これに注意を向けたのはごく少数のケースのみでした。

それにもかかわらず、26のケースを選択することができました。 それらは説明の完全性が異なり、これは記事の本文に反映されています。 すべての企業が分析結果の使用を説明する鮮やかなストーリーを提供できたわけではありません。 どこかかなり乾燥した報告がありました。 ただし、すべてのケースには、Webサイト、モバイルアプリケーション、プロフェッショナルなインターフェイス、オンラインサービスなど、IT製品の開発に高品質の方法論を使用した実際の例が含まれています。 作業の結果は異なります。推奨事項、開発戦略、概念、プロトタイプ、既製製品。 私たちは非常に異なるプロジェクトにも着手しているため、すべてに興味がありました。



これらの違いにもかかわらず、選択されたケースの最初の分析は、私たちが6つの生活状況に対処していることをすぐに示しました。

1. 特定のユーザーグループ向けのIT製品の開発。
2. 複数のユーザーグループ用の共通プラットフォームの開発。
3. モバイルプラットフォームへの移行。
4. プロフェッショナルなインターフェース開発。
5. 新しいローカル市場へのIT製品の入り口。
6. 新しいサービスの開発。

これらの状況での定性的方法論の使用には、異なる目標、研究方法の選択、および最終結果という独自の特性がありました。 研究の第3段階では、これら6つの状況を分析し、製品の問題を解決するための品質手法の使用パターンを特定しました。 以下に焦点を当てました。

• 問題。 お客様はどのような問題に直面しましたか？ プロジェクトチームはどのような困難に直面しましたか？
• メソッド。 どの品質方法を選択しましたか？ 研究はどのように行われましたか？
• 結果。 どのユーザーデータが取得されましたか？ このデータはどのアプリケーションを見つけましたか？ IT製品の開発にどのように影響しましたか？

これらすべての点は、外国人の同僚の経験を理解するために重要です。 生活の状況は、タスクの複雑化と定性的研究を実施するための要件に従って配置されます。 私たちは研究の結果に目を向けます。

「私たちはすべて9歳の女の子ではありません」：特定のユーザーグループ向けの製品開発

ほとんどのIT製品は、特定のユーザーグループのニーズを満たすように開発されていますが、「平均的な人」向けの開発はまれです。 特定のユーザーに対する製品の成功は、ニーズ、期待、痛みをどれだけ正確に定義するかにかかっています。 そして、製品を作成するときにこの知識がどの程度正しく使用されているか。



ここでの主な難点は何ですか？ 方法を選択し、ユーザーデータを収集しますか？ 収集されたデータを分析する方法で？ それとも結果を使用するのですか？ これらはすべて重要な問題ですが、それらについて話すのは時期尚早です。



主な難点は、ユーザーを代表していないことを認識することです。 仮説を立て、美しいモデルを描きますが、ユーザーと話したり観察したりするまで、あなたはそれらについて何も知りません。 何が彼らを興奮させますか？ 彼らは本当に何が必要ですか？ ユーザーの現実はあなたの見解とどのように違いますか？



場合によっては、この認識は「痛みのない」ものです。 プロジェクトチームと顧客が調査するかどうかについて疑問を持たない3つの事例を次に示します。

* * *

これら3つのケースが関連しているのはなぜですか？ プロジェクトチームが実際に研究を行うことを余儀なくされる場合、それらはすべて非常にまれな状況です。 子どもは、ほとんど何も知られていないユーザーの特別なグループです。 私たちの想像力を示した後、この種の他のグループを思い出すことができます：障害者、孤独な高齢者など。 研究の必要性が疑いなく顧客でも請負業者でもないことが重要です。 それ以外の場合、あなたの無知を認めることははるかに困難です。製品開発者は自分の総合的な専門知識を非常に強く信じています。



UX研究の方法論について話すと、これらの3つのケースは、定性的手法（インタビュー、観察、日記研究）の使用が、特別なユーザーグループにとっても高品質のIT製品の開発に役立つ貴重な情報を提供することを示しています。 チームは必要な知識を得て、暗闇の中でさまようことをやめます。 悪い製品を入手するリスクは減少します。



さらに、ケースは、チームがユーザーグループの特性（スポットレスケースの日記など）を考慮して方法論を調整しなければならない場合があることを示しており、フィールドワークの複雑さのために、研究者の資格は非常に高くなければなりません。 ユーザーの認識に深刻なギャップがある場合は、共同設計セッションを無視しないでください（クーパーの場合）。



疑わしい読者は反対します。はい、私たちについてほとんど知らないユーザーグループがあり、研究なしには方法がありません。 子どもたち、それを理解している人もいますか？ しかし、誰もが知っていることをする普通の人がいます。 たとえば、彼らは車を買います。 車を販売するためのウェブサイトが必要な場合、なぜ研究するのですか？ 締め切りが迫っていて、予算が限られています。 時間とお金を節約する方が良いと思いませんか？ 別のケースを見てみましょう。

* * *

それだけですか？！ 調査を実施しましたが、結果はそれほど控えめですか？ 革命を待っていますか？ 革命はありません。特定のタスクを行う人にとって便利なサイトです。 特定のユーザーグループ向けに製品を開発する際に品質の方法論を使用しても、画期的な成果をもたらす素晴らしい結果が得られるとは限りません。 さらに、品質の方法論の使用そのものは固有の機能ではありません。これは、高品質のIT製品の生産における作業ルーチンの一部です。 この作業の結果は些細に見えるかもしれませんが、人々に本当の利益をもたらします。 別のケースを見てみましょう。

* * *

再び革命と魔法はなく、高品質の研究作業と、その結果としての便利で使いやすいIT製品だけです。 最後のケースでは、読者の注意を逸らす可能性のある重要なポイントがあります。最初は、顧客はユーザーに関するすべてのことをまったく知らなかった。 そのため、独自の専門知識に頼らずに研究を行う必要があります。 おそらく結果はあなたの推測を確認するでしょう。 それには何の問題もありません。 あなたのアイデアが間違っているとさらに悪くなり、製品の発売後にそれを知ることができます。 高品質の方法論は、開発者をこの危険から保護するのに役立ちます。 したがって、最初の3つのケースほど明確ではない場合でも、調査を実施する必要があります。



品質の方法論を使用して特定のユーザーグループ向けの製品を開発した経験を分析した後、次の結論を導き出すことができます。

1. 高品質の方法論は、ユーザーのニーズ、習慣、恐れ、問題に関する貴重なデータを提供します。 この知識は、対象読者がよく知られている製品開発に必要です。 ユーザーエクスペリエンスを向上させるために既存の製品に変更を加える必要がある場合、この知識も同様に重要です。
2. プロジェクトチームは、IT製品の開発に必要なユーザーとユーザーの行動に関する完全な知識不足に直面することがあります。 これは、特定のユーザーグループの製品を作成する場合に可能です。 そのような状況では、チームは研究を行うことを余儀なくされます。 同時に、多くの場合、異常なユーザーグループと連携するように方法論を適合させる必要があり、研究者のトレーニングの要件は特に高くなります。 その結果は、IT製品の設計に大きな影響を与える可能性があります。
3. 別のより一般的な状況で、研究の必要性が明らかでない場合。 その理由は、プロジェクトチームがユーザーグループに近いこと、ユーザーの経験のルーチン、またはユーザー自身の専門知識に対する信念などです。 この場合、専門家の評価を確認するため、または明白でないユーザーのニーズを特定するために、調査を実施する必要があります。 定性的研究は、既成のIT製品の将来の問題から開発者を保護するのに役立ちます。

---

記事のすべての部分： 1 | 2 | 3 | 4 | 5 | 6