作為一個曾以超詳細文件而遭人白眼的互動設計人員，我最大的敗筆，在於寫文件只在乎自己有沒有成就感，而不是別人看不看得懂、能不能順利理解，後果是，文件雖全，但沒人有耐心理解消化，最後還是都跑來問我，不勝其煩。

得出的一個實際教訓是，把厚的做薄。別光顧著文件好看、結構清晰，而去問看文件的人，這麼寫能不能看懂，用什麼形式寫更容易懂，哪些地方不用太詳細，哪些地方要多說幾句。

如果還處於做不厚的境況，就還是先老老實實有一句寫一句吧， MECE 原則、金字塔原理是基本功。

設計文件是用於描述你的設計如何解決問題。設計文件是對設計思路的規劃，主要目的是你對設計展開思路，總結他人的建議，以便更好地開展設計工作，做出更好的產品。

很多認為設計文件不重要，設計文件的目的是讓其他人瞭解你的設計或作為參考。設計文件描述了問題的解決方案，對於團隊來說非常重要，對於個人來說也是不可或缺的。

對於團隊，有利於工作的開展和團隊的合作，方便溝通。對於個人也有利於思路展開，和設計方案制定。

如何寫設計文？要清楚自己的設計思路，為什麼而設計，創意點在哪裡，使用者群體是哪一類人，是否有價值，市場是否有前景，使用者是否喜歡。從為什麼設計到為誰而設計展開設計文件構思，再從其商業價值到市場分析。設計是為了解決問題，設計文件要闡述清楚自己設計能解決什麼的問題。

首先簡單說一下開發人員不寫設計文件去開發產品的弊端，80%的程式設計師在沒有設計文件的情況下開發產品的最終結果是以自身設計無法實現而告終。如果未來程式設計師走向分為兩派，一派是產品功能設計人員、一派是程式碼搬磚者，那我認為他們所得的薪資可能是8:2的比例，或者說根本不需要後者，後者直接被機器所幹掉。

軟體開發，架構先行，一篇優秀的設計文件可以使開發人員少走很多彎路，設計文件越是詳細，考慮的越是全面。首先可以使自身設計的程式BUG比例大大降低，也可以幫助程式設計師理清思路，同時也能讓別人快速看懂你的程式。

那如何寫好設計文件？首先明確使用者需求，在設計文件的開始要先交代設計產生的實際背景，闡述要寫此篇設計文件出於什麼需求，大概要解決什麼樣的問題，達到什麼效果，完成哪些功能。這裡一定要一目瞭然，切忌含糊不清，語言表述不明確，誤導他人或是使他人摸不到方向，要將實際的需求描述清楚，可以配以效果圖，以便需求描述更加生動到位。接下來是程式碼步驟的實現，將思路實現。

要保證源頭上的正確，避免一步錯步步錯的情況發生，從後端的資料庫操作到前端的樣式設計始終要遵循程式碼的開發以及命名規範，避免重複地去查詢資料庫造成產品效能低下的情況。最後要和領導同事進行設計評審，讓每個人都能發表一些自己的意見，使最終開發少走彎路減少BUG發生率。