製品設計ドキュメントとのより良いドキュメントとチームコミュニケーション

公開: 2022-03-10

簡単な要約↬デザイン提案を青信号にするのに苦労したことはありますか？設計プロセスを形式化する必要があると思いますか？デザイナーとしてリモートで作業する場合、COVID19の時代はあなたにとって挑戦になりつつありますか？次に、この記事で設計プロセスを文書化するための方法論を理解するために読み続けてください。

会社やスタートアップで製品デザイナーとして働くための典型的なプロセスは、あなたにはおなじみかもしれません。設計ソリューションを提供するための新製品が開発されています。次に、いくつかの設計提案に取り組み、フィードバックを収集するために1〜3人の前でそれらを売り込みます。

このプロセスがうまく機能する場合もあれば、機能しない場合もあります。たとえば、自分のタスクを完了するために注意を払うことに忙しく、設計提案に対して明確で簡潔なフィードバックを提供するのに十分な時間を費やしていない人もいます。

また、プロセスが優れていても、意思決定を書き留め、反復を追跡し、設計プロセス全般を形式化する必要がある場合もあります。特に、COVID19のためにリモートで作業している現在の状況ではそうです。

プロセスを文書化することには多くの利点があります。たとえば、作業がより見やすくなり、より多くの人々からフィードバックを得る機会が生まれ、全体的なコミュニケーションが改善され、すべてのコンテキストと考慮事項を考慮して機能がどのように設計されたかが明確になります。

ヒーローデザイナーの堕落

2018年頃、私はラテンアメリカで事業を展開する会社でマドリッドのリモートプロダクトデザイナーとして働いていました。このプロセスには、メキシコとブラジルのサンパウロの他のチームが関わっていました。

この会社で働き始める前は、ニュースメディア、デザインスタジオ、ソーシャルネットワーク、モバイルOSなど、さまざまな分野の小規模および大規模な環境でのキャリアでさまざまな経験を積み、e-食料品店のスタートアップを設立しました。、そして他の小さなスタートアップとのフリーランスのギグもしました。

それらの年の間、私は同じアプローチに従っていました、あなたは何人かの人々を同じ部屋に座らせ、あなたの解決策を売り込み、いくつかのスクリーン、フローを提供し、いくつかのフィードバックを得て、そしてそれを再び提示します。何度か繰り返すと、作業は開発フェーズに到達する準備が整います。

ただし、これとまったく同じアプローチが機能しなくなりました。チームに参加して間もなく、ビデオハングアウトで自分のデザインを売り込むだけでは不十分であることに気づきました。私はたくさんの提案を作成していましたが、利害関係者やチームメートから最終的な承認を得ることができませんでした。私は混乱し、自分自身に問い続けました：何が起こったのですか？可能な限り最良のソリューションを設計していませんか？質の高い作品をお届けしていませんか？それらの質問のすべてが私に自分自身への自信を失わせていました。 問題は、プロセスをこの環境に適応させる必要があることでした。

ジャンプした後もっと！以下を読み続けてください↓

自分のプロセスがうまくいかないことに気づいたらすぐに、リモートでデザイナーとして働く方法、カモメの効果（誰かがあなたの仕事に来て、それを厳しく批判してから飛び去るとき）、どのように他の企業はリモートコラボレーションに取り組んでおり、プロセスを書き留めて形式化する方法を説明していました。このすべての資料を読んだ後、開発者がこの同じ問題にどのように直面しているのか疑問に思いました。ほぼ非同期的にリモート環境でどのようにコラボレーションしますか？彼らはどのようにして最終合意に達するのですか？実際、開発者コミュニティには、プルリクエストと呼ばれる非常にうまく機能するプロセスがすでにあることを発見しました。

プルリクエストを使用すると、変更を文書化してより大きなコードベースに変更を導入し、他の人のフィードバックを使用して決定を検証できます。このように、導入する変更は、コードがすでに実施しているすべての標準および接続と完全に混ざり合っています。これはまさに私が達成する必要があったことですが、もちろんデザインファッションのアプローチです。プロダクトデザインドキュメントを紹介します。

製品設計ドキュメント

Product Design Doc（PDD）は、解決したい問題、コンテキスト、および最終的な解決策を反復またはステージベースのアプローチに変換するドキュメントです。

これは、設計プロセス全体を1つのドキュメントに文書化して、会社の誰とでも共有できることを意味します。これは、製品を決定するためのナレッジベースとして機能します。かっこいいですね。詳細を掘り下げてみましょう。

全体的なコンセプト

PDDは、メタデータ、コンテキスト、ステージ、フィードバックの4つの主要な概念で説明できます。

メタデータは、タイトル、日付、ステータスなど、ドキュメントに関する有用な情報です。
コンテキストとは、他の人が読む必要があるものです。あなたが行う設計提案を理解するために、あなたが達成する必要があることの説明、問題、要約、または目標のようにそれについて考えてください。
ステージは、設計のさまざまな反復であり、通常、より広範なソリューションに焦点を合わせ始め、各ステージでより具体的な詳細に焦点を合わせます。各段階は前の段階に基づいており、受け取ったフィードバックに対応しています。これは、解決された問題が再び表示されない最終ポイントに到達するための構造化された方法です。
フィードバックとは、他の人から集めたすべての意見、コメント、要求、および推奨事項を指します。利害関係者またはチームメンバーからフィードバックを収集できます。

これらの4つの概念を使用すると、ニーズに合わせてPDDのさまざまなバリエーションを作成できます。会社やプロジェクトはそれぞれ異なり、私にとってうまくいったことは、同じように機能する必要はありません。しかし、PDDでこれらの4つの主要な概念をカバーすると、ほとんどすべての状況で機能する可能性があります。

構造例

主な考え方を理解した上で、その会社で使用してきた仕組みをご紹介します。次のセクションがあります。

タイトルは、簡潔で明確であり、すでに持っている他のPDDタイトルと簡単に区別できる必要があります。
ステータスは、現在ドキュメントがどの段階にあるかを示します。

下書き
コンテキストの定義に引き続き取り組んでいます。フィードバックの準備ができていません。
S30、S60、S90
ソリューションのさまざまな段階（30％、60％、90％）（段階の詳細は後ほど）。
完了
すべてのフィードバックに対処し、欠落している点はありません。 PDDが終了しました。

要約は、設計する必要のある問題の説明であり、一般に、他の役立つ関連資料にリンクしています。
目標は、ソリューションが焦点を当てる必要のある重要なポイントです。これは、正しい方向に進んでいることを確認するために常に確認するチェックリストです。
S30 （またはステージ30％ ）は、要約と目標に基づいて作成する最初の提案であり、詳細ではなく、より広範なソリューションに焦点を当てています。おそらく、忠実度の低いワイヤーフレームまたは同様の手法を提供します。これは、提案されたソリューションがまったく異なるアプローチを取る可能性があり、主要なフィードバックが発生することが予想される段階です。
S60 （またはステージ60％ ）は、完全性の60％でのソリューションであり、S30からのフィードバックを適用します。 S90よりも詳細は少ないですが、ソリューションの意図を明確に示しています。より多くのケースといくつかのフロー定義を含む忠実度の高いワイヤーフレームを提供します。主に見逃されたケースや予期しない小さなシナリオに焦点を当てた、ある種のフィードバックを受け取る場合があります。
S90 （またはステージ90％ ）は、完全性の90％でソリューションを持ち、S60からのフィードバックを適用するステージです。この段階では、さまざまなシナリオ、コーナーケース、ビジュアルデザイン、さらにはプロトタイプなど、デザインの細部に焦点を当てます。ある種のマイナーなフィードバックがあると予想されます。

あなたは自分自身に問いかけているかもしれません、私は同じ順序と段階の命名規則に従う必要がありますか？ええ、あなたはしません。ステージの名前をS30、S60、S90から「探索」、「提案」、「解決策」に変更できます。

順序を変更して、最も洗練された作業（S90、ソリューション）がドキュメントの先頭に表示され、読み取りフローが最終段階から初期段階（S30、探索）に進むようにすることもできます。

テンプレート

最も一般的なライティングプラットフォーム用に提供されているテンプレートの1つからすぐに始めてください。注意：セクションの命名規則は完全にカスタマイズ可能です。 Abstractが気に入らない場合は、 Brief 、 About 、またはニーズに合ったものを使用してください。維持する必要のある主な概念は、各ステージに焦点を当てるためにさまざまな反復を作成することです。S30を探索で、S60を提案で、S90をソリューションで名前を変更できます。

紙
概念
Googleドキュメント
実際の例

PDDを使用する主な利点

すべての決定は文書化されています。
つまり、あなたが会社/プロジェクトを離れるときでも（そしてそれは遅かれ早かれ起こります）、周りで生成されたすべての知識は永遠に会社にとどまるので、他の人がそれを見て、あなたが去ったところから繰り返すことができます。
コミュニケーションを改善します。
PDDでチームのさまざまな人にフィードバックを提供してもらうと、全員が同じページにとどまり、行われた決定を認識するのに役立ちます。
利害関係者からの無限の変化を制限します。
すべての段階で、問題のさまざまな角度に焦点が当てられ、より広い解決策からより狭い解決策になります。これにより、人々は一度に1つの問題に集中することができ、終盤の段階で彼らを助けることができます。
製品は共同で構築されています。
利害関係者が特定のソリューションを定義する代わりに、エンジニアリング、設計、およびその他のチームがソリューションに関与して、それらをソリューションの一部にします。

ファイナルノート

この遠隔地の会社についての話を締めくくると、私はそこでさらに数か月働き、少なくとも5つの異なるプロジェクトで製品設計ドキュメントを実装することができました。欲求不満が大幅に軽減され、デザインの提案についてコンセンサスを得ることができたため、製品は進化し続けました。それ以来、会社は大きく成長し、私の時代に行った仕事の一部は今でも使われています。

PS：私は2019年にこの記事を書き始めましたが、2021年に、Abstractが設計プロセスを文書化するための製品を作成しているのを見て、軌道に戻ってそれを完成させることにしました。それはまだかなり関連性のあるトピックのようです。

参考文献

HannahHearthによるリモートチームでの設計演習の実行方法
カモメの影響を避ける：ローレン・ムーンによるフィードバックのための30/60/90フレームワーク
設計ドキュメントをどのように設計しますか？齋藤ジョン
BrendanFaganによるデザインドキュメントの力
MattColyerによるノートブックの紹介