2021年の初め、Dialpadのコア製品はビジネス電話プラットフォームでした。私たちはいくつかのユースケースをサポートしましたが、インターネットを介して電話をかけたり受けたりすることは私たちのパンとバターでした。しかし、年末までに2つの会社を買収し、製品に電子メール、チャット、ソーシャルを追加することを約束しました。私は、製品のサイズを2倍にするプロジェクトの設計を主導する任務を負いました。

（ひび割れ）わかりました、私は経験豊富なデザイナーです。私はこれを成し遂げる方法を理解することができます。

私はすぐに、これを実現するのが難しいステートメントであることに気づきました。

プロダクトデザイナーは、私たちの仕事を支援するためにこれほど多くのツールやテクニックを自由に使えるようにしたことはありません。調査、旅の地図、フィグマ、コード、基調講演、データ分析…リストは膨大であり、増え続けています。非常に多くのオプションがあるので、プロジェクトにどのオプションをいつ使用するかをどのように知ることができますか？

そして正直に言うと、どうすればこれを避けることができますか？

一部のチームは、製品設計プロセスを図またはチャートにまとめました。Dialpadでは、ダブルダイヤモンド製品の設計プロセスをトリプルダイヤモンド（Zendeskの影響を受けています）に適合させました。私たちのものは次のようになります：

それはほとんどの場合機能します。実際には、私のプロセスは次のようになることがあります。

だからそれは行きます

誰かが私にその恐ろしい質問をするとき、私は何を言いますか？

「あなたの製品設計プロセスは何ですか？」

私はプロダクトデザイナーとしての数年間、たくさんのツールやアクティビティを手に入れてきましたが、最近までそれらを文書化したことはありませんでした。その結果、プロセスの一部を忘れることがあり、その結果、デザインに支障をきたしました。

これを修正するために、プロセスの各部分を書き留めたので、将来参照するためのプレイブックを用意しました。これがそのプレイブックです。

私の設計プロセスは、すべてのプロジェクトに必須の一連のアクションではなく、タスクを実行するため、またはタスクをスキップできる理由を理解するために使用できる参照とプロンプトとして考えています。大工の道具箱のように、どの道具が利用可能で、どのようにそしていつそれらが役立つかを覚えておくことは役に立ちます。

発見

明確に定義された問題や目標がないと、期待のずれ、プロジェクトのスコーピングの誤り、または予期しない問題のために、何百もの時間とリソースが失われる可能性があります。チームはこれらの答えを知っていると感じるかもしれないので、何かを構築するためにスキップしたいと思うかもしれませんが、プロジェクトが将来の成功のために準備されるように、最初に仮定を調整して検証することが重要です。

このフェーズの目標は、問題の説明を特定し、問題を組み立て、十分な証拠を収集して、自信を持ってアイデアフェーズに進むことができるようにすることです。

潜在的な活動:(プロジェクトごとに意味のあるものを選択してください）

• 観察する：私たちは何を見ていますか？これまでに何を知っていますか？これにより、プロジェクトに関する知識が深まり、繰り返し発見する必要がなくなります。製品要件ドキュメント（PRD）または設計ドキュメントを開始するときに役立ちます。2〜3日
• Proto-Personas：ユーザーがどのようなものであるかを表す調査と直感の組み合わせ。ユーザーが誰であるか、または彼らのニーズが何であるかについて人々が意見を異にするときに役立ちます。1〜2日
• ジャーニーマッピング：目標を達成するために誰かが通過するプロセスの視覚化。ユーザーエクスペリエンスの全体像を把握したい場合に役立ちます。これには、ユーザーの感情や外部のタッチポイントなどのオフサイトのものが含まれる場合があります。1週間。例
• サービスの青写真：環境のさまざまな部分が互いにどのように相互作用するかなど、プロジェクトの影響を受ける環境を計画します。システムの多くの部分に影響を与える可能性のある大規模なプロジェクトに適しています。サービスブループリントは、プロジェクトを管理可能なチャンクとマイルストーンに分割するのにも役立ちます。1週間。例
• 状況に応じた調査：人々があなたの製品をどのように使用し、なぜ彼らが何をするのかを理解します。例
• ジェネレーティブリサーチ：ユーザーの動機、問題点、行動を理解します。なぜなぜ分析は、表面レベルの仮定を超えて、問題の根本原因を明らかにするのに役立ちます。1〜2週間（調査ラウンドごと）。例
• タスク分析：誰かがタスクを完了するために取るステップを計画し、プロセスを改善するためにステップを追加または削除できるようにします。例
• UXの分解：確立されたパターンまたは関連するパターンから学びます。特に、それらのパターンに簡単にアクセスできる場合（一般的に有料製品では難しい）。1〜2日
• 利害関係者/SMEのインタビュー：私たちがすでに知っていることや試したことを理解します。問題の歴史的背景を持つ人々をターゲットにします。1週間
• データ分析：「いくつ」と「どのくらいの頻度」に関する質問に答えます。分析にアクセスし、ProductAnalyticsの誰かにデータをプルするように依頼します。1〜2日
• UXキャンバス：チームが現在の作業を行っている「理由」を示し、問題の説明と解決策のギャップを明らかにし、会話をアウトプットからアウトカムにシフトします。1〜2日。例

• 問題の説明：ユーザー、その目標、およびデータによってサポートされる望ましい結果を説明する1〜3文。
• 明確で達成可能な目標：予想される変更の概要と、それが特定の製品やビジネスのKPIにどのように結びつくか。
• 成功基準：ソリューションが問題を解決しているかどうかを判断するために使用される測定可能な基準を選択します。
• プロジェクトの潜在的な懸念、リスク、または厄介な領域

意味

チームは、問題を定義し、目標を示し、成功の指標を明確にすることで、設計するためのいくつかのガードレールの定義を支援しました。このフェーズの時間は、問題と、チームが解決策についてどの程度強く感じているかによって異なります。

潜在的な活動：

• プロジェクトを分類する：プロジェクトを管理可能なチャンクとマイルストーンに整理し、責任を割り当て、適切に委任します。作業を他の活動やチームと調整できるように、各フェーズを見積もります。複数の製品分野に影響を与える大規模なプロジェクトに役立ちます。2〜3日
• 問題の優先順位付け：問題とワークフローの影響/努力のマトリックスを作成します。潜在的なソリューションのシーケンスを支援します。1日
• デザインスプリント：製品を設計または再設計するデッキ設計活動のすべての人。迅速な解決策が必要な場合、課題が大きく複雑な場合、またはチームが行き詰まっている場合に役立ちます。5日（スプリントあたり）
• デザインワークショップ： UXの特定の問題やポイントについて競合するアイデアをすばやく生成します。Crazy 8、カードの並べ替えなど。さまざまな方法で解決できる抽象的な問題に役立ちます。1日（ワークショップごと）
• ローリングリサーチ：セッションごとに採用することを心配することなく、定期的に理解度をチェックしたり、デザインをテストしたりします。
• ワイヤーフレームとプロトタイピング：デザインに基本的な構造を与えて、デザインのアイデアがまとまり、「正しく感じられる」かどうかを確認します。
• UIデザインとプロトタイピング：チームがデザインの方向性に自信を持っており、タイポグラフィ、色、間隔、UXコピー、インタラクションなど、デザインの細部に焦点を当て始める場合に役立ちます。
• ユーザーテスト： UX、UI、コピーに関するフィードバックを求めます。この手順には時間がかかるため、プロジェクトが1週間以上余分に必要となるほど重要な場合に使用してください。
• 設計レビュー：他の設計者、製品チーム（製品マネージャー、エンジニア、QAなど）、および（適切な場合）経営幹部の利害関係者との定期的なレビュー。あらゆるレベルの人々に私たちの進歩と貢献の機会を可視化して、管理するときに役立ちます。定期的なレビューは、エッジケースや不幸な道を含むすべてをデザインがカバーしていることを確認するのにも役立ちます。
• 周囲の管理：プロジェクトの進捗状況や活動を他の製品や経営幹部に定期的に伝えるためのフレームワーク（メール、チャットポスト、スライドなど）を作成します。多くの利害関係者がいる注目度の高いプロジェクトに役立ちます。

• プロジェクトを社交する計画
• 完全なPRD
• すべての既知のシステム状態とエッジケースをカバーする忠実度の高い設計。*私の経験では、開発に移行するには、設計が80％〜90％完成している必要があります。エンジニアは通常、より多くのエッジケースを発見し、場合によっては、ブラウザまたはアプリで「適切に感じる」までデザインを調整する必要があります。

発達

このプレイブックを使用して、プロジェクトを実行し、最も影響力のあるアクティビティをすばやく特定し、大まかなタイムラインを作成することができました。

製品設計者は、最終的に製品になる設計に責任があります。詳細な設計仕様を作成することを意味する設計者もいれば、コードを直接プッシュすることを意味する設計者もいます。コードに直接関与するかどうかに関係なく、想定どおりに設計を実装するためにエンジニアリングと協力して積極的な役割を果たします。

潜在的な活動：

1. 設計の詳細を完成させる：開発の開始後に実行できる残りの設計タスクをすべて完了します。エラーメッセージの記述、アニメーションの作成、可変状態の設計、支援技術で使用される場合のUXの定義、および開発と並行して実行できるその他のすべて。
2. 積極的にQA設計。テスト計画が存在することを確認し、プレビューリンクまたは定期的なデモを依頼して、機能をプロアクティブにテストできるようにします。
3. ドキュメントを維持し、アートワークを更新します。会議や注目すべきチャットの会話の後に、意思決定と未解決の質問でドキュメントとデザインを更新します。設計とドキュメントは常に最新である必要があります。これにより、チームの信頼できる情報源であり続けることができます。
4. （設計システムを持つチームの場合）新しいコンポーネントを作成します。プロジェクト中に作成された、再利用の可能性のある新しいコンポーネントを特定し、それらを設計システムで形式化/文書化します。

これは、現在私の製品設計ツールボックスにあるものです。巨大なプロジェクトの前に立って麻痺していると感じる代わりに、このプレイブックを参照して、特定のプロジェクトに意味のある設計活動をすばやく特定することができます。

Dialpadの製品のサイズを2倍にするという困難な作業に直面したとき、私はこのプレイブックを使用して、この大規模なプロジェクトを管理可能なチャンクに分割しました。たとえば、Dialpadの製品の他の部分がどのように影響を受けるかを確認するためのサービスブループリントを作成する必要性を理解するのに役立ちました（数年前に見逃していたかもしれません）。

繰り返しますが：

これは、すべてのプロジェクトで実行する必要のある必須のアクションセットではなく、タスクを実行するため、またはタスクをスキップできる理由を理解するために使用できる参照とプロンプトです。

私もこれを一人でやらない。私はこれらの活動の多くを製品マネージャーやエンジニアと一緒に取り組んでいます。また、独自のツールボックスもあります。しかし、しっかりとした製品設計プロセスを確実に行うのは私次第です。

プロダクトデザイナーのチェックリストに触発され、デザインプロジェクトを主導するためのヒントから発展しました。この記事の初期ドラフトを読んでくれたStéphaneMartinとBethDevineに感謝します。私の個人サイトにも掲載されています。