起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識有了這些產品設計文檔，我再也不用背鍋了！
編輯導語：你是否曾經也為別人的錯誤決策背過鍋？如何才能夠更加嚴謹，且保持自己的初心去做設計呢？本篇文章中，作者向我們詳細介紹了產品設計文檔，講解了如何正確維護它，推薦想要學習更加系統管理自己設計的群體閱讀。
你是否曾為設計方案的通過而努力？你是否想要讓自己的設計流程更加規范化？新冠肺炎帶來的遠程工作模式是否給你造成了一些麻煩？這篇文章將教會你如何管理你的設計文檔。
公司或者初創企業中的產品設計師標準工作流程對你來說可能非常熟悉：開發一款新產品首先需要提供設計解決方案。完成設計提案后你需向 1-3 個人闡述你的提案，并獲取反饋。
有時候這些工作能很好完成，有時則不然。舉個例子，有些人大部分的時間都花費在如何完成自己的工作上，因此沒有足夠的時間對你的設計提案提出清晰簡潔的反饋。
特別是在新冠疫情爆發期間，我們不得不進行遠程工作，即使你的工作完成得足夠完美，你也希望記錄下每一步的設計決策，持續追蹤迭代并繼續優化設計，從而規范化設計工作流程。這些事情會經常性發生。
記錄設計過程有很多的好處。舉個例子，這能可視化你的工作內容，創造更多獲得他人反饋的機會，加強整體溝通效率，清晰地描繪出這些設計要點是通過什么樣的設計思路被創造出來的，以用這些設計要點可以解決哪些產品需求等。
一、英雄設計師的失?。═he Fall Of TheHeroDesigner）
2018 年左右，我作為一名遠程產品設計師，在馬德里為一家拉丁美洲的公司工作，我們的團隊里還有來自墨西哥、圣保羅和巴西的成員。
在我開始為這家公司工作以前，我有過很多不同領域的工作經驗，包括新媒體、設計工作室、社交網站、移動操作系統、成立在線零售公司等等，甚至從小型創業公司接一些自由職業者的工作。
這些年我始終遵循著相同的工作方法。提出方案，被一些人選擇，提供一些界面、流程，獲取反饋，然后再提出方案。在多次迭代之后，方案才能進入開發階段。
然而，這些極為相似的方法現在沒辦法達成目的了。在加入這個團隊不久后，我就意識到，通過電話會議提出想法是不夠的。我設計了很多提案，但是我沒辦法從老板和隊員那里得到認可和通過。
我感到非常迷惑，我不停地問我自己：發生了什么？是不是因為我沒有設計出最好的方案？是不是因為我沒有提供高質量的工作內容？所有的問題都在一遍又一遍地打擊我的自信心。
問題在于我應該使我的工作流程更加適用于周遭的環境。
當我意識到了我之前的工作流程是不適用的，我便開始閱讀大量關于如何成為一個遠程設計師的文章，例如海鷗效應（當有人進入你的工作時，你會嚴厲批評它，然后讓它飛走）相關文章，其他公司如何處理遠程協作的相關文章，以及他們如何規范流程并記錄下來。在讀過所有這些材料后，我想知道開發者如何面對同樣的問題。
Pull 請求（開發者之間的一種協作功能）允許你記錄每一次更改，從而在更大的代碼庫中引入更改，并使用其他人的反饋來驗證你的決策。
從這個角度來說，這個由你提出的改變將完美地結合已有代碼的固定點和其間鏈路。這就是我需要達到的，當然，是以一種流行的設計方式。接下來我將介紹，什么是產品設計文檔。
二、產品設計文檔（The Product Design Doc）
產品設計文檔（PDD）將你要解決的問題、場景和最終解決方案轉換為基于迭代或階段的方法。
這意味著你可以將整個設計過程歸檔到一個單獨的文檔里，并將它分享給同事，從而為你的設計方案提供強大支撐。這聽上去是不是很酷？來，讓我們討論一下細節。
1. 內容總覽
一個產品設計文檔需要包含 4 個重點內容：元數據、背景、階段、反饋。
（1）元數據（用來描述數據的數據）是關于文檔的基本信息，例如標、日期、狀態等。
（2）背景可以幫助其他同事理解你的設計方案，你需要像考慮描述、問題、概要或你要實現的目標一樣考慮它。
（3）階段是指設計的迭代過程。一般來說，一開始會更關注整體解決方案，在之后的迭代階段中會越來越注重細節。每一次迭代都會基于上一次的成果和他人的反饋做調整。這是一種達成最終目標的結構化方法，已解決的問題不會重復出現。
（4）反饋指的是所有從其他人那里收集到的觀點、意見、要求和建議。你可以從利益相關者及隊友那里獲得反饋。
基于這四個要點，你就可以創造不同的產品設計文檔來適應你的需求。每一個公司、項目都是不同的，也許這適用于我，但不一定適用于你。但是如果你的產品設計文檔包含了這四個要點，大概率能適用于任何情況。
2. 案例結構
在理解了要點之后，我會把我在這個公司工作時使用的產品設計文檔結構分享給你。它包含了以下這些內容。
（1）標題應當簡潔明了，并且易區別于其他已有的產品設計文檔。
（2）文檔狀態需明確展示，例如以下文檔狀態：草稿：還處在明確設計背景的階段中，還不能收集反饋；S30 / S60 / S90：設計方案中前后階段之間，設計方案的不同完成進度（30% / 60% / 90%）；已完成。
（3）項目概要是對你的設計需解決的問題的描述，通常可以鏈接到其他有用的相關閱讀材料。
（4）設計目標是你在設計過程中最需要關注的一些問題，它可以以列表的形式存在，同時你需要時常查看它，以確認你處于正確的方向及階段上。
（5）S30（完成 30%的階段）所展示的產品設計文檔 應該包含基于項目概要和設計目標所做的初版設計方案，它應該關注大致設計方向，而非細節。也許提供一個低保真框線圖或者類似的競標產品就足以了。
這個階段可能會產生很多完全不同的方案，并收到一些重大反饋。
（6）S60（完成 60%的階段）所展示的產品設計文檔，是基于前一階段收集到的反饋問題，完成設計方案的60%。比起 S90 的產品設計文檔，本階段的文檔可以粗糙一點，但是需要明確方案的內容。
你需要提供高保真線框圖，以及不同頁面狀態和一些流程設計。在這個階段你收集到的反饋，很大可能是關注在是否有狀態及頁面的缺失。
（7）S90（完成 90%的階段）所展示的產品設計文檔，是基于前一階段收集到的反饋，提升方案完成度到 90%。這個階段將會關注你的設計細節，包括所有不同的頁面、支線狀態、視覺設計，甚至是高保真設計稿。在這個階段，你期望會收集到一些不是很重要，不會影響到主要設計方案方向及流程的反饋。
你可能會問自己，我需要完全遵循這個階段命名規范嗎？不，并不是的。你可以重新命名這三個階段為：探索 – 提案 – 解決方案。
你也可以改變這個產品設計文檔狀態的排列順序：首先展示 S90 的解決方案，最后展示 S30 探索的內容。
3. 模板
從 Paper、Notion、谷歌文檔或是實際生活中遇到案例中選一個來做模板。記?。?strong>每個模塊的命名習慣完全可以按照你自己的習慣來。
如果你不喜歡用項目概要這個詞，你可以用需求這個詞，或者是其他更加貼近于此內容定義的詞。你需要保留的主要概念是創建不同的階段，從而使你得以專注于每個階段，你可以將 S30 命名為探索，將 S60 命名為提案，將 S90 命名為解決方案。
三、使用產品設計文檔的主要好處（Keybenenfitsofusingpdd）
1. 每一個決定都被記錄
這意味著即使你離開了這家公司或這個項目組，所有的相關信息都會永遠留在公司里，當有人來接手時，他可以從你留下的設計方案中了解項目，更好地繼續完善它。
2. 加強溝通
產品設計文檔將會收集所有團隊成員的反饋，這使得每一個人都對項目了如指掌，并了解到方案是如何被決定的。
3. 限制利益相關者永無止盡的修改欲
在每一個設計階段，我們關注問題的角度不同，逐漸明確設計方案。這樣一來，人們就可以一次專注于單個問題，從而幫助他們收束發散的思維，提升專注力。
4. 產品設計是通過合作完成的
與讓利益相關者直接決定的解決方案不同，我們讓工程、設計和其他團隊參與解決方案的制定，使其成為方案解決的合作者。
四、寫在最后（Finalnotes）
結束了遠程辦公時遇到的項目，我可以繼續在這里工作一些時間，以保證我可以完成至少 5 個項目的產品設計文檔。我的挫敗感大大減輕了，我能夠讓大家就我的設計方案達成共識，從而使產品繼續迭代。因此，這個公司大大地得到了提升，而且我在那段工作時間內設計的方案現在也依然在被使用。
p.s. 我在 2019 年開始寫這篇文章，在 2021 年我看到 Abstract 正在開發一款用來管理設計流程的產品，所以我決定把之前這篇文章寫完?？磥磉@還是一個很前沿的話題啊。
本文翻譯已獲得作者的正式授權（授權截圖如下）
原文：https://www.smashingmagazine.com/2021/04/better-documentation-team-communication-product-design-docs/
作者：Ismael González
譯者：鄭伊妮；審核：劉倩茹、李澤慧、張聿彤；編輯：孫淑雅
本文由@TCC翻譯情報局 翻譯發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
太干貨了，來迭代更新自己，立馬收藏起來慢慢看hhhh
好方法！值得學習，經驗就是在一次次的積累中不斷養成的。
哇哦！這是一個很好的方法哎，這就學起來
學到了一種新的思路和方法，下次可以試試！