使用產品設計文檔更好的文檔和團隊溝通

您可能熟悉在公司或初創公司擔任產品設計師的典型過程：正在開發一種新產品，並為其提供設計解決方案。 然後你提出一些設計方案，然後在 1-3 個人面前推銷它們以收集反饋。

有時這個過程工作得很好，但有時卻不行。 例如，有些人忙於完成自己的任務，沒有花足夠的時間為您的設計提案提供清晰簡潔的反饋。

也可能發生這樣的情況，即使您的流程很好，您仍然希望通過寫下決策、跟踪迭代和總體設計流程來正式化流程，尤其是在當前由於 COVID19 導致我們發現自己在遠程工作的時代。

記錄過程有很多好處。 例如，它使您的工作更加可見，創造了從更多人那裡獲得反饋的機會，改善了整體溝通，並清楚地展示瞭如何在所有上下文和考慮因素的情況下設計功能。

英雄設計師的隕落

2018 年左右，我在一家在拉丁美洲運營的公司從馬德里擔任遠程產品設計師，參與了這個過程中來自墨西哥和巴西聖保羅的其他團隊。

在我開始在這家公司工作之前，我的職業生涯中有很多不同的經歷，在新聞媒體、設計工作室、社交網絡、移動操作系統等許多不同領域的小型和大型環境中工作，創辦了一家電子雜貨初創公司，甚至與其他小型初創公司一起做一些自由職業。

在那些年裡，我一直採用同樣的方法，你讓一些人坐在同一個房間裡，推銷你的解決方案，提供一些屏幕、流程、獲得一些反饋，然後再次展示。 經過一些迭代後，您的工作將準備好進入開發階段。

但是，這種相同的方法停止了工作。 加入團隊後不久，我意識到僅在視頻通話中宣傳我的設計是不夠的。 我正在創建很多提案，但我無法獲得我的利益相關者和隊友的最終批准。 我很困惑，不停地問自己：發生了什麼事？ 我不是在設計最好的解決方案嗎？ 我不是在交付高質量的工作嗎？ 每一個問題都讓我對自己失去信心。 問題是我需要讓我的流程適應這種環境。

當我意識到我的過程不起作用時，我開始閱讀很多關於如何遠程工作的文章，海鷗效應（當有人進入你的工作，嚴厲批評它然後飛走），如何其他公司正在接近遠程協作，以及他們如何通過寫下來正式化他們的流程。 在閱讀了所有這些材料後，我想知道開發人員是如何面臨同樣的問題的？ 他們如何以幾乎異步的方式在遠程環境中進行協作？ 他們如何達成最終協議？ 我發現，事實上，開發者社區已經有一個非常適合他們的流程：它被稱為拉取請求。

拉取請求允許您通過記錄更改並使用其他人的反饋來驗證您的決定，從而在更大的代碼庫中引入更改。 通過這種方式，您引入的更改與代碼已有的所有標準和連接完美結合。 這正是我需要實現的目標，但當然是採用設計時尚的方法。 讓我向您介紹產品設計文檔。

產品設計文檔

產品設計文檔 (PDD)是將您要解決的問題、上下文和最終解決方案轉換為迭代或基於階段的方法的文檔。

這意味著您可以將整個設計過程記錄在一個文檔中，該文檔可以與您公司的任何人共享，它將作為您做出的產品決策的知識庫。 聽起來很酷，對吧？ 讓我們深入了解細節。

總體概念

PDD 可以用 4 個主要概念來描述：元數據、上下文、階段和反饋。

• 元數據只是有關文檔的有用信息，例如標題、日期、狀態等。

• 上下文是其他人需要閱讀的內容，以了解您提出的設計建議，將其視為您需要實現的描述、問題、摘要或目標。

• 階段是您設計的不同迭代，通常開始關注更廣泛的解決方案，並在每個階段關注更具體的細節。 每個階段都基於前一個階段並處理收到的反饋。 這是一種結構化的方式，可以達到最終解決的問題不會再次出現。

• 反饋是指您從其他人那裡收集到的所有意見、評論、請求和建議。 您可以從利益相關者或團隊成員那裡收集反饋。

有了這四個概念，您可以創建不同的 PDD 變體以滿足您的需求，每個公司/項目都是不同的，對我有用的，不必以相同的方式為您工作。 但是，如果您在 PDD 中涵蓋這 4 個主要概念，那麼它幾乎可以在任何情況下工作。

示例結構

在了解了主要概念之後，我將與您分享我在該公司期間一直使用的結構。 它有以下幾個部分：

• 標題應該簡潔、清晰並且易於與您已有的其他 PDD 標題區分開來。
• 狀態指示您的文檔現在處於哪個階段：
• 草案
  仍在努力定義上下文。 還沒準備好反饋。
• S30、S60、S90
  解決方案的不同階段（30%、60%、90%）（稍後會詳細介紹這些階段）。
• 完全的
  所有反饋都已得到解決，並且沒有遺漏點。 PDD 完成。
• 摘要是對您需要設計的問題的描述，通常鏈接到您可能擁有的其他有用的相關閱讀材料。
• 目標是您的解決方案需要關注的關鍵點，這是您將不斷審查的清單，以確保您走在正確的軌道上。
• S30 （或Stage 30% ）是您根據摘要和目標提出的第一個提案，關注更廣泛的解決方案而不是細節，可能通過提供低保真線框或類似技術。 在這個階段，提出的解決方案可能會採取完全不同的方法，並且預計會出現主要反饋。
• S60 （或Stage 60% ）是您完成 60% 的解決方案，並應用來自 S30 的反饋。 它的細節比 S90 少，但清楚地表明了您的解決方案的意圖。 您提供了一個包含更多案例和一些流程定義的高保真線框。 您可能會收到一些反饋，主要集中在遺漏的案例和小的意外情況。
• S90 （或Stage 90% ）是具有 90% 完成度的解決方案並應用來自 S60 的反饋的階段。 此階段專注於您設計的最精細細節，包括所有不同的場景、角落案例、視覺設計，甚至原型。 預計會有一些小的反饋。

您可能會問自己，我是否需要遵循相同的順序和階段命名約定？ 好吧，不，你沒有。 您可以將階段從 S30、S60 和 S90 重命名為：探索、建議、解決方案。

您還可以更改排序，以便最精煉的作品（S90，解決方案）位於文檔的頂部，閱讀流程從最後階段進入早期階段（S30，探索）。

模板

使用為最常見的寫作平台提供的模板之一快速開始。 請記住：部分的命名約定是完全可定制的。 如果您不喜歡Abstract ，只需使用Brief 、 About或任何適合您需要的東西。 您需要保留的主要概念是創建不同的迭代以專注於每個階段，您可以將 S30 重命名為 Exploration，將 S60 重命名為 Proposal，將 S90 重命名為 Solution。

• 紙
• 概念
• 谷歌文檔
• 現實生活中的例子

使用 PDD 的主要好處

1. 每個決定都有記錄。
   這意味著即使您離開公司/項目（遲早會發生），周圍產生的所有知識都將永遠留在公司中，因此其他人可以查看它並從您離開的地方進行迭代。

2. 改善溝通。
   在 PDD 上讓您的團隊中的不同人員提供反饋有助於每個人保持一致並了解所做的決定。

3. 限制利益相關者的無休止的變化。
   每個階段都關注問題的不同角度，從更廣泛的解決方案到狹窄的解決方案。 這使人們可以一次專注於一個問題，在最後階段幫助他們。

4. 該產品是協作構建的。
   我們讓工程、設計和其他團隊參與解決方案，使他們成為其中的一部分，而不是利益相關者定義特定的解決方案。

最後的筆記

結束關於這家偏遠公司的故事，我在那里工作了幾個月，我能夠在至少 5 個不同的項目上實施產品設計文檔。 我的挫敗感減少了很多，我能夠就我的設計建議達成共識，因此產品繼續發展。 從那以後，公司發展了很多，我在此期間所做的一些工作仍在使用中。

PS：我在 2019 年開始寫這篇文章，然後在 2021 年我看到 Abstract 正在創建一個用於記錄設計過程的產品，所以我決定回到正軌並完成它。 看起來它仍然是一個相當相關的話題。

參考書目

• 如何在遠程團隊上運行設計練習 Hannah Hearth
• 避免海鷗效應：Lauren Moon 的 30/60/90 反饋框架
• 您如何設計設計文檔？ 約翰·齋藤
• Brendan Fagan 設計文檔的力量
• Matt Colyer 介紹筆記本