AIによる要約：UXデザインとリサーチの工数を適切に見積もり、プロジェクトの優先順位を決定する手法「UXキャパシティプランニング」を紹介する。従来、UX作業は計画段階で考慮されず、リソース配分が不明確だった。この問題を解決するため、リサーチ労力は「問題の明確さ×リスク」、デザイン労力は「複雑さ×リスク」の軸で分類し、適切な対応を決定する。これにより、UXリソースを最適化し、開発のスムーズな進行とプロダクトの品質向上を実現する。
多くの企業が、プロジェクトが必要とするUX労働量のレベルを調整するのに苦労しています。そんな場合、このフレームワークが役立ちます。
私がこれまで働いてきた、あるいはコンサルティングやアドバイスをしてきたすべての企業で、デザイナーとリサーチャーが苦労しているのを目の当たりにしてきました。
苦労のいくつかは、すべてのプロジェクトで「完全なUXプロセス」（それがどのような意味であれ）を行うことを期待するデザイナーから来るものです。他のデザイナーは、まずユーザビリティテストを行わずに、自分がデザインしたものを開発者に実装させることに不安を抱いています。
さらに一般的なのは、特定のプロジェクトが正当化すべきリサーチとデザインの労力レベルについて、プロダクトマネジメントとの整合性が取れていないことです。多くの場合、UX作業のキャパシティプランニングが実際に行われていないことが原因です。労働量、見積もり、ロードマップ、キャパシティはすべて、エンジニアリング作業に最も一般的に割り当てられる用語です。コミットメントが行われ、プランニングは納品フェーズでのみ行われます。
公平を期すために、私は、チームがUXを見積もりに含めたくないというわけではないことも観察してきました。チームがUXを見積もりに入れたがらないのではなく、その方法を知らないだけなのです。デザイン＆リサーチ労働量に関する全体的なレベル設定のための標準的なフレームワークはありません。これまでは。
解決すべき問題
私が解決しようとした主な問題は4つあります：
- UXキャパシティプランニングを改善し、様々な状況下で必要とされるUXの労働量のレベルについて、UX、プロダクト、エンジニアリング間の連携を改善すること。
- 時間枠の中で現実的に期待できるUX活動の種類を設定します。
- UXチームがディスカバリー、イテレーション、実行のレベルを決定できるようにします。
- UXチームが最も付加価値の高いプロジェクトにより多くの時間を割けるようにします。
ペンド・リサーチ・エフォート・フレームワーク
似たような問題に挑戦した人は他にもいます。2021年8月、Jeanette Fuccella氏はPendoブログでリサーチの優先順位を決めるフレームワークを発表しました。
彼女は2つの次元にまたがる象限を作成しました： 問題の明確さとリスク。
- 問題の明確さ：高、リスク：低は、「出荷して測定」。
- 問題の明確さ：高、リスク：高は「デザイン・ヘビー」。
- 問題の明確さ： 低、リスク：低は「リサーチ・ライト」。
- 問題の明確さ： 低、リスク：高は「リサーチ・ヘビー」。
概念的なレベルでは非常に有用ですが、克服すべき現実的な障害もありました：
- リサーチ・ライトとリサーチ・ヘビーが何を意味するかについては、ほとんど説明されていませんでした。どのような場合にどのようなレベルのリサーチを行うべきかは説明されていますが、そのリサーチがどのような内容を含んでいるかは説明されていません。
- ほとんどの企業は、プロジェクトレベルのリサーチをすべてこなせるほど大規模なリサーチチームを持っていません。そこで、いつデザイナーがリサーチを行い、いつフルタイムのリサーチャーに任せるべきか、という疑問が浮かびました。
- リサーチとデザインの両方を1つのマトリックスにまとめようとする試みは、単純化しすぎました。リサーチの労力を決定するのに多少は役に立ちましたが、デザインの労力についても同じようなことをする大きなチャンスがあると思いました。
UX労働量フレームワーク2.0
私の新しいフレームワークは、リサーチ労働量とデザイン労働量を分け、Tシャツレベルの労働量ガイド、各労働量レベルが何であるか（そして、いつ使うべきか）の説明、そして、レベルごとの共通のアクティビティや属性を含んでいます。
リサーチ労働量については、私は「問題の明確さ」対「リスク」に留まりました。リスクはデザイン作業にも当てはまりますが、私は「問題の明確さ」を「複雑さ」に置き換えました（複雑さがデザイン作業にどれだけの反復が必要かを決定することが多いからです）。
問題の明確さ：高
これは、私たちが以前に取り組んだことがあり、活用できる広範な既存の定性的・定量的調査があり、チーム全体で理解を共有している問題です。
問題の明確さ 低い
ほとんど新しい、あるいは未知の問題。多くの仮定が存在。問題の定義が不十分で、大幅な調整が必要。この作業は戦略/イニシアティブレベルで行われる可能性が高い。
リスク：高
簡単に「元に戻せない」作業、ユーザーの主要なワークフローの大部分に影響する作業、および/またはビジネスやユーザーエクスペリエンスに大きなリスクがある作業。
リスク: 低
簡単に取り消すことができ、少数のユーザーに影響し、ミッションクリティカルなワークフローに影響せず、「間違った」としてもビジネスやユーザーエクスペリエンスに与える影響が小さい作業。
複雑さ：高
多くのシステム/API、外部との依存関係、複数のチームにまたがる利害関係者、または技術的に複雑（設計の意思決定に影響を与えるような方法）。
これは、多くの疑問があるか、設計者が既存の知識をほとんど持っていない問題空間です。
複雑さ：低い
システムや利害関係者がほとんど自己完結しており、依存関係がほとんどなく、単純明快です。
多くの場合、これらは単純なユーザビリティの改善や、よく理解されたワークフローにおける追加のユースケースです。
リサーチ労働量の象限
各労働量レベルの理解を深めるために、各リサーチ労働量レベルを詳しく見てみましょう。
出荷して測定
時には、リサーチの厳密さよりもスピードを優先する必要があります。これは、問題が明確でリスクが低い場合に最適です。多くの場合、このステップにはリリース後の戦略に関する提携が含まれ、デザイナーが行うことができます。
リサーチライト
リスクが低い場合でも、解決しようとしている問題が明確でない場合は、リサーチを行うのが賢明です。とはいえ、何週間もかけてゼロから始める必要はありません。リサーチ・ライトは、通常、発見調査のフォローアップに重点を置いています。リスクが低いため、通常、このレベルではユーザビリティ・テストは必要ありません。
リサーチライトは、活用できる先行する定量的または定性的なリサーチがあるが、まだ答えのない疑問がある場合に最も適しています。このリサーチは、通常、デザインチームが行います。専任のリサーチチームをリサーチライトプロジェクトから解放することは、リサーチチームが生み出す価値を向上させるための重要な要素です。
リサーチ・ミディアム
リスクが高い場合は、たとえ問題の明確性が高くても、リサーチに投資することが重要です。リサーチ・ミディアムとリサーチ・ライトの決定的な違いは、リスクが高いため、評価テストに投資する必要があるということです。
また、専門のリサーチチームが設立されている場合、デザイナーが実施するリサーチの中で最も一般的なレベルであることも注目に値します。
リサーチヘビー
複数のプロジェクト、チーム、またはジャーニーにまたがる大規模なプロジェクトでは、より厳密なリサーチが必要になります。このようなプロジェクトでは、生成的・評価的、定性的・定量的、態度的・行動的といった複数のリサーチ手法が必要になることがよくあります。
この種のリサーチは通常、より戦略的な性質を持っており、訓練を受けた経験豊富なリサーチャーが行う必要があります。多くの場合、デザイナーが一人で行うよりも多くの時間を必要とします。
デザインの労働量レベル
象限間で必要とされるデザイン労働量レベルは以下の通りです：
ここでの意図は、デザイナーを特定の成果物に制限することではなく、リスクと複雑さに応じて必要な作業の種類と 量をパートナーに伝えることです。
コンサルティングのみ
すべてのプロジェクトにUXの直接的な「実作業」が必要なわけではありません。リスクと複雑さが低い場合、UXに作業（モックアップ）を割り当てるのではなく、コンサルティングを受けることは100％許容されます。そうすることで、デザインチームは最も影響力のある仕事に時間を使うことができます。
リスクが低く、複雑性が低く、既存のデザインパターンを活用しているときに多くのコンサルテーションを行うことは、UXの潜在能力を引き出し、ビジネス構築により戦略的に貢献するための鍵となります。多くのデザイナーが、あらかじめ決められたソリューションのためのモックアップ作りに多くの時間を費やしています。
そのような場合、製品チームと、使用するコンポーネントやフローなどを揃えるためにクイックコネクトを持ちたいが、エンジニアリングチームにはその作業を行う権限を与えるべきだという期待を持つように設定することは、非常に役に立ちます。これは、設計システムを導入する最大のメリットのひとつです。
フロントエンドエンジニアが、モックアップのバックエンドで素早く何かを作り上げ、それを私に見せるような職場もありました。私たちはちょっとした微調整について話し合い、それから実際のバックエンドに接続してリリースする準備が整いました。
ちょっとしたUIの変更にいちいちモックアップを作る必要をなくすことは、より複雑でリスクの高い（そしてインパクトのある）仕事に時間を割くことができるようになるための重要な戦術です。
デザインライト
たとえ複雑性が高くても、もしあなたが考えている変更がうまくいかなかった場合、それを元に戻すのが簡単であれば、多くの場合、高度な反復作業や低忠実度の事前作業などは必要ありません。ただそれを世に送り出し、実地でテストするだけです。
複雑なため、コンサルティングだけでは不安な仕事ですが、1ヶ月のデザイン作業も必要ありません。ここでのもう一つの重要な要素は、ビジネスやユーザーエクスペリエンスに対するコストが低いことです。
ヒント：個人情報、金融取引、政府規制、ミッションクリティカルなシステムに関連する仕事は、決して「デザインライト」に該当してはいけません。
私が見るチームの最大の間違いの1つは、デザイナーにすべてのプロジェクトでUXライトの仕事をさせようとすることです。このようなフレームワークを使うことの大きな付加価値の1つは、UXライトの仕事は絶対にできるが、リスクが低い場合に限るということを説明するのに役立つことです。
デザイン・ミディアム
リスクが高いときは、より多くの反復を行い、より低い忠実度で問題解決を始めることが重要です。複雑性が低い場合は、このようなことはあまり必要ありませんが、それでも、コストのかかる手戻りやビジネスへの悪影響を避けるために、反復に時間をかけることは理にかなっています。
デザインライトではなくデザインミディアムを採用するもう1つの一般的な理由は、新しいパターンやコンポーネントを導入する必要がある状況に関係しています。余分な検証とテストが必要であり、そのためのキャパシティを確保することが重要です。
デザイン・ヘビー
最後に、デザインヘビーです。これは複雑でリスクの高いプロジェクトで、正しく行うことが不可欠です。多くの場合、デザイン・ヘヴィはリサーチ・ミディアムまたはヘヴィとペアになります。
多くのデザイナーが「フルUXプロセス」といえば、このレベルを思い浮かべるでしょう。モデリング、情報アーキテクチャ作業、ローフィデリティ、モックアップなど。深い機能プロトタイピングは必ずしも必要ではありませんが、ここでは重要です。
なぜなら、作業を誤ると、顧客やビジネスにとって大きな損失になるからです。
このフレームワークの使い方
「これは素晴らしいと思うよ、ジェレミー "とあなたは言います。いい質問ですね。例を挙げましょう。
1. プロジェクト計画
プロジェクトの優先順位が決まったら（そして多くの場合、その前に）、プロジェクトの説明に以下の項目を入力します：
- 背景情報（問題を理解するために必要なあらゆる文脈）
- 解決すべき問題（そして、なぜ今優先する価値があるのか）
- ビジネスインパクト（または「価値」）
- ユーザーの成果（誰かの生活がどのように改善されるか）
- 成功基準（成功したことを知るために何を観察する必要があるか）
通常、これらはプロダクトマネージャーが作成しますが、共同作業となることもあります。
その後、チームのUXデザイナーが入力に挑戦します：
2. プロジェクトキックオフ
次に、バランスのとれたチームと主要な利害関係者（UX、プロダクト、エンジニアリングのリーダーなど）とキックオフを行います。デザイナーが作業を開始する前に、プロジェクトの説明（UXの取り組みを含む）についてすり合わせを行います。修正や追加が行われることもよくあります。
3. デザイナーが UXストーリーを Jira に追加
私が非常に勝ちがあると感じていることの1つは、UXがJiraのようなプロジェクト管理ツールで作業を追跡するようにすることです。これは、パートナーに明確さと透明性を提供し、私たち自身に責任を持たせるのに役立ちます。
私たち全員が上記のことに同意したら、デザイナーはプロジェクトを個々の作業項目（ストーリー、タスク、プロダクトバックログ項目など、その組織が好むもの）に分割します。忠実度のガイドラインは、各バックログ項目が何らかの成果物（調査計画、ワイヤーフレーム、モックアップv1、調査結果など）と結びついていることです。労働量フレームワークは、どのようなバックログ項目を行うべきかのガイドとして機能します。
各バックログ項目は、具体的な見積もりを取得し、どのプロジェクトに最初に取り組むべきかなど、PMの指示に従って優先順位付けされます。そして、バックログ項目は設計者のキャパシティに基づいてスプリントにドラッグされます。
4. プランニング
この時点で、UXストーリーをプロダクト＆エンジニアリングとレビューし、優先順位やビジネスニーズなどに応じて調整を行います。私たちの目標は、特定の四半期のロードマップ上のすべてのプロジェクトに対してこれを行うことです。私たちは、変更が起こることを認識していますが、ある四半期のすべてのプロジェクトについて何かを書き出し、優先順位をつけることで、四半期計画を立てる際にUXキャパシティを考慮に入れることができ、その結果、より現実的な期待値をエグゼクティブ・リーダーたちに伝えることができます。
注：私は、機能よりも問題と結果に優先順位をつけることを固く信じています。それは私が常に目指している理想的な状態です。しかし、ほとんどのチームは現実的にそうではないことがわかりました。そのため、優先順位をつけるプロジェクトの問題と成果を確実に定義し、UXの労働量とキャパシティにリリーススケジュールを（その逆ではなく）導かせることが、有用かつ現実的な妥協点となっています。
