コラボレーティブデザイン–エンタープライズ製品デザインを成功させるためのガイド

公開: 2022-03-11

アジャイルソフトウェア開発、かんばんプロセス管理、リーンUXについて聞いたことがあると思います。コラボレーティブデザインは、エンタープライズ製品デザインとは異なる哲学的および戦術的なアプローチです。

コラボレーティブデザインは、参加型で魅力的で現実的なオールハンドまたはブレーントラスト環境でデザインするプロセスです。真空で設計するのではありません。代わりに、名前が示すように、コラボレーションデザインは、デザイナーをさまざまなチームや部門の中心に置き、まとまりのある製品を構築するために全員と協力します。このようにして、誰も取り残されることはなく、関係するすべての利害関係者と一緒に製品を構築することができます。

すべての企業組織は異なり、あらゆるアイデアやタスクの周りに利害関係者を囲い込むことは、猫番のように見える可能性があります。このガイドでは、主要なプレーヤーと協力して、彼らの意見を聞くだけでなく、この新しいデザイン中心のアプローチで彼らを参加させるためのヒントとコツを確認します。

プレイヤーに会う

デザイナーは多くのことに長けていますが、彼らの役割は問題を解決することから始まります。それには、専門家が誰であるかを知り、彼らと協力する必要があります。製品開発チームのすべてのメンバーには独自のニーズと責任があるため、それらを知ることは、特定の割り当てを実際に完了することと同じくらい重要です。

それで、それ以上の苦労なしに、チームに会いましょう：

製品マネージャーは、製品と機能の範囲、要件、および開発の反復サイクルを定義します。彼らは多くの場合、最終的なはい/いいえの前に機能のゲートキーパーであり、幹部を含む組織全体とのコミュニケーションで実践されています。
エンジニアは製品を構築するため、技術的な機能と制限を理解しています。これにより、開発のタイムライン、使用するテクノロジ、範囲、および多くの場合設計の実現可能性（テクノロジと時間の制限を考慮してコンセプトが可能である場合）などの主要な懸念事項を決定するための重要なリソースになります。
データベースおよびシステムアーキテクトは、データがどのように統合されるかを知っており、既存の製品/プラットフォームの上に構築し続けながら、パフォーマンスを維持するために何が必要かを深く理解しています。
内部の対象分野の専門家（SME）は、ビジネスプロセス、ユースケース、歴史、政治、および経営陣、クライアント、ユーザーからの一般的な期待に精通しています。
販売は、見込み客に製品を提示することに重点を置いています。これにより、営業が最初の連絡先になるため、リードを閉じる（そして多くの場合作成する）には、製品を理解することが重要です。
トレーナー（またはSaaSではカスタマーサクセスエージェント）は、営業チームや新規またはトライアルユーザーに直接触れることができ、製品がinvitroおよびそれ以降でどのように機能しているかに関する有用な情報を大量に提供できます。

製品に取り組んでいるすべての関係者が設計プロセス（アジャイル手法の基本原則の1つ）に関与している場合、結果として得られる製品は、設計者が利害関係者と協力しているためではなく、利害関係者と協力しているため、成功を収める可能性が大幅に高くなります。そうでないよりも、私たちが理解できない方法で特定のユーザーとビジネスのニーズを理解してください。共同作業は常に最善の選択肢のように思えますが、どうすればよいでしょうか。

利害関係者と協力する方法

プロダクトマネージャー、プロダクトのゲートキーパーおよびタイムキーパー

プロダクトマネージャーは、多くの場合、製品に個人的な愛着を持っており、社内で非常に高い期待を抱いています。また、問題、満たされていない約束、または新しい機能の要求がある場合は、製品のユーザーまたは顧客に回答する必要があります。

彼らはシンプルなコミュニケーションを高く評価しており、進捗状況、問題、および変更について最新の状態に保つ必要があります。彼らはドラフトを最初に頻繁に見るのが好きで、さまざまな規模で作業できるため（直接的な製品開発から、わずかな変更を加えた実践的なものまで、いくつかのレベル）、ドラフトとのやり取りは大きく異なる可能性があります。

PMは、さまざまな利害関係者（内部および外部）とのコミュニケーションに非常に多くの時間を費やすため、PMがあなたにチェックインすることを期待せずに、PMに通知し続けることが重要です。 PMに定期的なチェックインを設定して、反復ドラフトを提示し、フィードバックを聞いて、次の会議のアクションアイテムのリストで常に終了します。

彼らの目標が製品の機能性について何であるかを学ぶのにそれほど時間はかかりません。 PMは、設計者が問題解決者であることを知っているため、設計者はデータと分析を提供して、その理由を証明する必要があります。あなたが正しいかどうかは関係ありません。最高の製品を作ることが目標であり、PMの信頼を得ることができることを証明してください！

エンジニアリング：デザインに命を吹き込む責任があります

エンジニア（開発者とも呼ばれます）は、製品に最も近い人々です。彼らはそれを構築します！これにより、製品の個々のコンポーネントを実際に体験してテストできるため、優位に立つことができます。これは素晴らしいことです。なぜなら、ソフトウェアがコーディングされる前に欠陥を見つけることは非常に多くのレベルで大きな利点であるため、間違いなく、設計の弱点を（時には何かを構築する前に）見つけることができるからです。

エンジニアリンググループの信頼を得る最良の方法は、包括的で完全な製品仕様を作成するか、それらを早い段階で関与させることです…またはその両方です。

開発者が真の利害関係者と見なされる場合、開発者はユースケース、シナリオ、技術的な課題、およびそれらを克服するためのオプションについて積極的に話し合います。

エンジニアが真の製品アーキテクトであることを忘れがちです。彼らは、特に課題が困難であるか、別の方法で処理できる場合に、設計者との問題を解決することに既得権を持っています。

データベースおよびシステムアーキテクト、データ構造の保護者

データベースおよびシステムアーキテクトは、製品が舞台裏でどのように機能するかを知っています。彼らは、データがどのように保存および構造化されているか、何を統合できるか、そしてすべてのシステムがどのように相互に通信するかについてすべて知っています。彼らは、製品がさまざまなシステムとどのように相互作用するか（最終的には彼らが責任を負うもの）よりも、製品がユーザーにとってどのように機能するかについてあまり関心がない傾向があります。

これらは、ユーザー中心の設計者が対処するのが特に難しい場合があります。データベース/システムアーキテクトがエンドユーザーとやり取りすることがない場合でも、製品の信頼性、速度、シンプルさなど、常にエンドユーザーに利益をもたらすことに重点を置いていることを覚えておくことが重要です。

データ構造がどのように機能するか、および製品の機能への変更の影響についての彼らの知識は、専門家の入力なしでは見逃しがちです。システムアーキテクトを招待して、製品の変更に関する会議やディスカッションに参加させることが重要です。たとえ、システムアーキテクトの立場が直接関係していないように見えても、そうです。

システムアーキテクトと協力する1つの方法は、次の質問を含むチェックリストを作成することです。

機能Xは現在のデータ構造に影響を与えますか？
現在のアーキテクチャを考慮した追加の設計/開発作業はありますか？
デザインYは既存のユーザー入力/出力と競合しますか？
機能Xの影響を受ける外部サービスはありますか？

この単純なリストは、既存の（そしておそらく）モノリシックデータ構造がどのように機能するかを明確に理解していなくても、正しい方向を示します。チェックされたものはすべて、簡単な議論で調査する必要がある領域です。

対象分野の専門家およびビジネスアナリスト、情報ウィザード

対象分野の専門家は適切な名前が付けられています。彼らは主題の専門家であり、ユニークで価値のある情報の金鉱になる可能性があります。多くの場合、彼らはこの分野で専門的な学位を取得しているか、人生の大部分を業界で働いてきました。彼らは、ビジネスがどのように運営されることになっているのかを実際に体験し、誰もが今日の場所にたどり着いた長い、つらい歴史と政治を思い出します。

ビジネスアナリストは、組織がどのように運営されているかを熟知しており、データが利用可能であるが社内の専門家がいない場合、SMEと同じ機能を果たすことがよくあります。

SMEと協力して、プロジェクトが経営陣によってどのように認識されているかを学び、内部の期待が満たされていること、および危険な領域を踏みにじっていないことを確認します。アナリストを設計セッションに招待し、事前に専門家であることを伝え、製品のリリースを成功させるために重要となる可能性のある歴史的な失敗、政治的争い、およびその他の問題に関する知識を共有するように依頼します。

カスタマーサクセスマネージャー、新しいクライアントの連絡先

新しいクライアントが最終的にセールスに参加すると、トレーナー、またはSaaS企業の場合はカスタマーサクセスマネージャー（CSM）が引き継ぎ、新しいユーザーに製品の実際の使用方法を教えます。したがって、トレーナーが初心者ユーザーとの会話に多くの時間を費やしていることは言うまでもありません。 CSMは、会社の購入決定に関与しないことが多い顧客とやり取りするため、独自の視点を持っています。

この独自の視点により、トレーナー/ CSMは、顧客のオンボーディングと新規ユーザーの行動の両方について、設計上の決定に役立つ情報を提供できます。多くの企業組織は、新しいクライアントがさまざまな製品をどのように使用しているかを追跡および監視し、電話から苦情まですべてを記録しますが、トレーナーは顧客が実際に苦労していることを認識しています。

すべての主要な設計会議に上級トレーナーを含め、彼らとの決定について問い合わせます。「顧客からの最も深刻な苦情の上位3つは何ですか？」などの質問をします。そして、「新しいクライアントは平均して製品に満足していますか？」そして、「どのような変更があなたとあなたのチームに最大のプラスの影響を与えると思いますか？」このようにして、私たちは皆、幸せな道が何であるかについて学びます。トレーナーは、クライアントが実際に製品を使用するすべての方法に対する私たちの目と耳です。

製品の顧客との最初の接触である販売

多くの場合、販売と設計は対立しています。一部の組織は販売主導型ですが、他の組織はそうではありませんが、目標には明確な違いがあります。販売チームは販売を増やしたいのに対し、設計はユーザーエクスペリエンスを向上させたいということです。それらは常に整列するとは限りません。

そうである必要はありません。ほとんどの営業担当者は、対処するのに非常に合理的な不満を持っています。製品の決定をほとんどまたはまったく制御できず、実際には約束できない約束をするように求められ、すべてにもかかわらず特定の収益目標を達成するように駆り立てられます。営業チームと製品チームが定期的に議論を熱くしているのは当然のことです。

それにもかかわらず、トレーナーのように、販売組織は顧客のニーズに対して独自の視点を持っており、多くの場合、その視点は小さな販売を行うこととクジラを連れてくることの違いです！営業チームが苦労しているさまざまな分野を理解します。あらゆる種類の電話に参加し、見込み客がどのようにコミュニケーションを取っているかを学びましょう。

これにより、営業との会話が始まります。それは彼らのニーズを聞くことだけではありません。それは、最初のコミュニケーションからオンボーディング後まで、あらゆる段階で潜在的なユーザーのエクスペリエンスを向上させることです。営業担当者が見込み客から最もよく耳にすること、取引を成立させる際に直面する課題、および取引が成立した後の最大の懸念事項を確認します。

エンタープライズでの設計は悪夢である必要はありません

設計者として、これらの可動部品はすべて、管理が非常に難しい場合があります。特に、正式な意味での「管理者」と見なされていない場合はなおさらです。チーム間のコミュニケーション、要件の収集、および設計フィードバックの主要な利害関係者として、これらすべての専門家にある程度のレベルでアクセスできる必要があります。

これを行うための最も重要でありながら最も簡単な方法は、すべての関係者の意見に耳を傾け、彼らのフィードバックを真剣に受け止めることです。ほとんどの組織では、次のステップはそのフィードバックを受け取り、製品マネージャーと協力して要件を実用的な作業に整理することです。

そこから、それは優先順位とギャップを埋めることに依存します。最終的には、最高の製品を設計することが目標であり、すべての製品開発スタッフの助けが必要です。それぞれの役割が重要であることを認識し、それらの担当者に製品開発サイクルでの価値を認識させることで、設計者がより良い製品設計の決定を行うために必要な情報を提供できるようになります。

•••

Toptal Designブログでさらに読む：

UIデザインのベストプラクティスとよくある間違い
空の状態–UXの最も見過ごされている側面
シンプルさが鍵–最小限のWebデザインを探る
モバイルインターフェースのヒューリスティック原則
読みやすさのための設計–Webタイポグラフィのガイド