產(chǎn)品有什么工作是沒坑的呢？恰逢十一有空，階段性總結(jié)一些經(jīng)驗(yàn)和要點(diǎn)，先說一說自己對文檔的理解。通過分享不同的視角，幫助有需要的朋友更好的形成自己的認(rèn)識。

我接觸的三種文檔

Word

哈，我相信這個(gè)是絕大多數(shù)人最開始接觸的文檔形式吧？雖然近來大家都對「又臭又長」文檔深惡痛絕，但是不可否認(rèn)Word能力強(qiáng)好處多，不管是對版本控制、審閱批改、鏈接跳轉(zhuǎn)，還是對拓展文件的支持性來說，Word都可以很好的hold住。而且，多人協(xié)作還可以嘗試Google Docs嘛。

當(dāng)文檔變得「又臭又長」之后，只會(huì)被團(tuán)隊(duì)束之高閣，喪失它應(yīng)有的價(jià)值。所以，為了避免「又臭又長」的Word文檔出現(xiàn)，我會(huì)多講幾句自己使用Word構(gòu)建文檔的習(xí)慣，寫在后文的「組織與邏輯」小節(jié)。

Axure

感覺最近也蠻流行這種Axure的文檔的（搜一下「Axure文檔」一大堆），好處是在使用Axure畫原型的工作流程里，可以直接導(dǎo)出作為可交互的文檔。不但文檔結(jié)構(gòu)清晰，而且效果還挺酷（我一開始就是被這個(gè)吸引了hh），對看文檔的人蠻友好。

自己嘗試之后發(fā)現(xiàn)一些小缺點(diǎn)，就是對太大體量的內(nèi)容支持性不夠好，而且維護(hù)起來也挺麻煩。首先，Axure畢竟不是專門為文檔服務(wù)的，所以當(dāng)實(shí)際工作中需要頻繁對文檔增刪改查和進(jìn)行版本管理時(shí)，會(huì)把人煩死（大家的文檔都不是一蹴而就的對吧？）。

嗯，由于設(shè)計(jì)師的不良習(xí)慣，我個(gè)人比較嫌棄Axure界面丑，所以我用Hype3或JustinMind做這種文檔（小聲說其實(shí)我不做這種文檔，怕累hh）。竊以為這種方式做大版本定稿時(shí)還是蠻合適的。

Wiki

工作一段時(shí)間后接觸到的文檔形式，在團(tuán)隊(duì)合作、大項(xiàng)目支持上，Wiki可以說是有其不可替代性，簡單高效的方式會(huì)提升工作體驗(yàn)，自己在用的Wiki是amwiki。我現(xiàn)在和Wiki正處于蜜月期，覺得這種文檔形式更有利于項(xiàng)目的管理。

圖片文檔

哈哈，這個(gè)是我自己懶的時(shí)候喜歡出的文檔格式。

因?yàn)橹笆亲鲈O(shè)計(jì)的，還比較喜歡用sketch，里面有個(gè)很好用的插件叫Notebook（9.99歐元），可以在原型的右側(cè)生成一個(gè)筆記本，用來對原型內(nèi)容做標(biāo)記補(bǔ)充。

這個(gè)套路簡單快速，針對少量內(nèi)容的改版需求或簡單的功能需求來說，簡直不要太方便。

文檔面向的三類主要用戶

開發(fā)

不知道大家怎么樣哈，我們開發(fā)是不怎么看文檔的，給他們講完就拿著原型和UI的圖吭哧吭哧開發(fā)去了（果然全靠嘴。。），哪不懂了就來問。結(jié)果最后被測試拿著文檔測了滿身Bug，莫名喜感。

測試

測試或許是文檔的「最忠誠」的用戶了吧（測試其實(shí)心里是苦澀的），它們要根據(jù)文檔描述，對開發(fā)出來的產(chǎn)品進(jìn)行測試，保證開發(fā)結(jié)果符合原始設(shè)計(jì)方案（這么說測試是產(chǎn)品的好伙伴?。?。

運(yùn)營

主要是根據(jù)文檔了解產(chǎn)品功能，最簡單的客服人員培訓(xùn)，到編寫新用戶幫助，還有很多產(chǎn)品運(yùn)營的工作，都可以依據(jù)文檔來開展，她們一般看不太懂專業(yè)性描述，所以盡量讓文檔更直白一些吧。

文檔的目標(biāo)

簡單、準(zhǔn)確、易讀、易理解

組織與模塊

第一呢：自上而下

在文檔編寫之初，要自上而下的梳理文檔目錄，從最上層的結(jié)構(gòu)開始逐層細(xì)分，使文檔目錄結(jié)構(gòu)形成體系，避免想到什么寫什么這種自下而上的方式。在文檔里還應(yīng)盡量讓每一點(diǎn)描述有唯一性位置，盡量避免對相同內(nèi)容在不同位置出現(xiàn)多個(gè)描述。

第二呢：組織整理

當(dāng)自上而下的梳理了文檔目錄，也許會(huì)發(fā)現(xiàn)有的地方需要描述的內(nèi)容很多，形成了很深的層級，有的地方很少很簡單，甚至沒有層級。這就是組織結(jié)構(gòu)不太適宜，當(dāng)目錄的結(jié)構(gòu)超過三層時(shí)，我一般會(huì)將其中的內(nèi)容重新組織整理，或提高部分的層級，或重新劃分內(nèi)容。這樣能保證文檔最大的可讀性。

第三呢：精簡結(jié)構(gòu)

精簡結(jié)構(gòu)是說，在整理好目錄之后，再檢查其中有沒有一些內(nèi)容有包含或重復(fù)等關(guān)系，將這些會(huì)導(dǎo)致重復(fù)的內(nèi)容精簡為唯一性內(nèi)容（唯一的描述地址），避免后期為維護(hù)產(chǎn)生不必要的復(fù)雜性。

第四呢：模塊復(fù)用

最簡單，之前都整理好了的內(nèi)容，看看有什么東西是全局性的，都拿出來，做為一個(gè)個(gè)模塊「封裝」，一般放在文檔前幾小節(jié)，將之統(tǒng)一描述，這樣后文涉及到這些內(nèi)容的時(shí)候，直接放一個(gè)跳轉(zhuǎn)鏈接「調(diào)用」就好了，極大的增強(qiáng)了文檔的完整可控性。

第五呢：還沒想好

大道至簡，大象無聲，大音希聲，不要拘泥于形式，這就剩隨機(jī)應(yīng)變了。

關(guān)于邏輯、結(jié)構(gòu)、組織的進(jìn)階閱讀可以找我推薦一些書。

數(shù)據(jù)與邏輯

后臺及隱藏?cái)?shù)據(jù)交換

額外的需求要額外描述，在涉及到數(shù)據(jù)流前后臺操作的時(shí)候，文檔中最好能清晰的描述數(shù)據(jù)的流向，具體的某項(xiàng)數(shù)據(jù)由哪產(chǎn)生，傳遞到哪，由什么控制，在哪里儲存。多和開發(fā)溝通，他們一般會(huì)給你結(jié)構(gòu)性的建議。

業(yè)務(wù)處理邏輯

文檔一定要清晰準(zhǔn)確的描述出業(yè)務(wù)處理邏輯，好在大家一般都很擅長思維導(dǎo)圖。關(guān)鍵／復(fù)雜性的流程單獨(dú)描述，比如登錄注冊流程，下訂單支付流程，邀請分享流程等。

原型的規(guī)范

原型是個(gè)坑啊

請?jiān)徫以O(shè)計(jì)出身帶來的毛病，個(gè)人對很多丑陋的產(chǎn)品原型很抗拒。但原型最重要的是表意清晰，可以不注意對齊排版，但要盡量控制整體原型的規(guī)范，保持一致的風(fēng)格，不然下游工作的開展實(shí)在是崩潰，完全不理解原型要表達(dá)什么。

原型的標(biāo)注

個(gè)人覺得最好能讓原型達(dá)到可用性標(biāo)準(zhǔn)，界面元素邏輯清晰，這樣可以直接在原型上進(jìn)行界面元素的標(biāo)注，更加直觀可讀。

保真度

在普遍性低保真都很難達(dá)到的情況下說高保真我也是含淚了。如果有條件，還是盡量多和交互設(shè)計(jì)師合作，產(chǎn)出高保真原型。有了它，在業(yè)務(wù)邏輯驗(yàn)證，異常情況控制，還有商業(yè)演示等方向都將有極好的支持。

形成規(guī)范

要說出交互文檔是難為人了，但是盡量讓原型的各個(gè)控件是統(tǒng)一化可復(fù)用還是能做到的，如果沒有特殊原因，不要相同的元素不同的樣子，那個(gè)不叫原型，叫畸形。

全是表格

善于利用表格，能減少很多的溝通成本

數(shù)據(jù)限制

輸入框的字?jǐn)?shù)限制，允許輸入的字符集控制等，我一般會(huì)把整個(gè)文檔涉及到的這部分內(nèi)容全匯總一下，放在一個(gè)單獨(dú)的表格里，這樣既方便查找，也方便唯一性修改。要是怕亂，可以在涉及數(shù)據(jù)輸入／輸出的地方編個(gè)號，又方便又直觀。這也算對測試友好吧？（畢竟測試也是我們的用戶?。?/p>

異常情況

既然是異常狀態(tài)，一時(shí)還真還不知道怎么說hh。斷網(wǎng)弱網(wǎng)空數(shù)據(jù)等等，很多亂七八糟的問題，最好也有規(guī)則性的集中描述，這樣可以避免自己在設(shè)計(jì)過程中被大量異常狀態(tài)打亂思路，增強(qiáng)產(chǎn)品整體的可控性。

好用的狀態(tài)機(jī)

清晰描述不同狀態(tài)下的業(yè)務(wù)邏輯，簡單來說就是用表格的方式清晰的將某些條件下的某些東西的狀態(tài)變化描述出來。比如，同一個(gè)按鈕，「游客」點(diǎn)擊時(shí)發(fā)生什么，「成員」點(diǎn)擊時(shí)發(fā)生什么，「管理員」點(diǎn)擊時(shí)又發(fā)生什么。

狀態(tài)機(jī)圖其實(shí)是UML中的一種，我們常用的狀態(tài)機(jī)就是那種簡化版本，更多知識可以去研究一下UML，對培養(yǎng)概念建模的思維也有挺大幫助，這方面我也不是專家就不多說了，不過要是感興趣仍然可以找我推薦一些書。

概念性描述

不知道大家是什么情況，但是我在在實(shí)際產(chǎn)品中，會(huì)遇到很多需要描述的概念性問題，例如社交產(chǎn)品中「圈子」這個(gè)概念，積分系統(tǒng)中「會(huì)員」這種概念，產(chǎn)品中涉及到的概念都要定義清楚，不應(yīng)該草草略過，因?yàn)檫@會(huì)增加許多的溝通成本（又變？你上次不是說會(huì)員要交999嗎？）。

其實(shí)概念描述最好用的表述方式是圖表，類圖、用例圖、業(yè)務(wù)圖等都是很好用的表述工具，面向?qū)ο蠛兔嫦噙^程兩種編程思維也很適合用來思考概念性問題。

概念描述其實(shí)是決定了整個(gè)產(chǎn)品是什么的東西，所以一般都放在文檔的開始，用各種思維導(dǎo)圖來表現(xiàn)（唉其實(shí)概念建模真是個(gè)苦活）。

角色權(quán)限表

對于含社交的軟件來說，一個(gè)用戶往往扮演許多「角色」，比如我在這個(gè)群是管理員，那個(gè)群是創(chuàng)建者，而且這里還會(huì)涉及到不同身份之間的權(quán)限變化，更讓人糟心的是，當(dāng)身份權(quán)限與用戶關(guān)系產(chǎn)生關(guān)聯(lián)的時(shí)候，比如一個(gè)用戶可以在自己管理的群里修改成員備注，而在另一個(gè)自己為普通成員的群里則看不到之前給同一個(gè)人的備注，也不能修改。這類問題很多湊到一起是挺暈的，所以也常常建立「用戶角色或權(quán)限」這類的表，來逐條解釋，就清晰易懂得多了。

積分系統(tǒng)表

對于涉及游戲化機(jī)制的產(chǎn)品，這類積分等級身份勛章排行榜的體系表就必不可少（因?yàn)槿绻划嫳恚氵€能怎么辦 ＝ ＝）。通常這種表內(nèi)容很多，但好消息是不怎么用進(jìn)行規(guī)則邏輯性的描述。通常都是采取階梯制度的建表方式，比如當(dāng)用戶滿足條件A>0，觸發(fā)什么，當(dāng)A>10，又觸發(fā)什么。一般來說這個(gè)表只要做好數(shù)學(xué)計(jì)算就不難搞定（什么！你說數(shù)學(xué)不難？）。

數(shù)據(jù)埋點(diǎn)

這個(gè)我一般單獨(dú)出文檔，根據(jù)業(yè)務(wù)階段和項(xiàng)目要求吧。不是什么時(shí)候都需要埋點(diǎn)，而且個(gè)人覺得埋點(diǎn)這事和主業(yè)務(wù)相關(guān)度不大（如果主業(yè)務(wù)是測試就當(dāng)我沒說），應(yīng)該作為單獨(dú)文檔提交。

拆分文檔

靈活組裝

在實(shí)際生產(chǎn)狀況中，將整個(gè)文檔拆分為數(shù)個(gè)小文檔工作是蠻靠譜的開發(fā)方式，不但能優(yōu)化開發(fā)節(jié)奏，有利于分工協(xié)作，還能強(qiáng)迫文檔形成統(tǒng)一的規(guī)范，保持完整性。

特殊模塊

為了保持專注性（這個(gè)很重要啊），和避免「又臭又長」文檔的出現(xiàn)，通常將文檔的許多不是強(qiáng)相關(guān)性的模塊拆分為單獨(dú)的文檔，比如說埋點(diǎn)文檔，交互文檔，UI文檔，后臺文檔等。

關(guān)于交互

被過多考慮的內(nèi)容

我一直認(rèn)為交互不應(yīng)是產(chǎn)品的主要工作，原因有以下幾點(diǎn)：

• 產(chǎn)品更應(yīng)該關(guān)注產(chǎn)品的全貌
• 交互只是產(chǎn)品價(jià)值鏈中的一環(huán)
• 交互設(shè)計(jì)師是一個(gè)專業(yè)性很強(qiáng)的職業(yè)
• 通常很擅長交互的產(chǎn)品，總會(huì)過多干涉交互設(shè)計(jì)師的工作（和指導(dǎo)程序敲代碼一個(gè)道理）

所以，如果工作中能有專人負(fù)責(zé)交互設(shè)計(jì)，還是建議各位尊重團(tuán)隊(duì)的力量（如果整個(gè)工作流程全是你自己，那就多加油吧，干巴爹）。

而且，要是真的很喜歡交互設(shè)計(jì)，就去轉(zhuǎn)行當(dāng)交互設(shè)計(jì)師嘛～

這個(gè)交互設(shè)計(jì)自查表

看過很多在文檔內(nèi)拉出一份思維導(dǎo)圖來檢查各種設(shè)計(jì)的狀態(tài)的圖，做過交互的都知道，這玩意兒叫交互設(shè)計(jì)自查表。首先我不是說交互設(shè)計(jì)自查表不好啊，但是過分強(qiáng)調(diào)總讓人覺得言過其實(shí)。是的沒錯(cuò)，產(chǎn)品設(shè)計(jì)的完整性可以通過使用這些工具來完善。

但，更重要的確確實(shí)實(shí)是產(chǎn)品的業(yè)務(wù)邏輯，可以允許Bug，可以允許異常，甚至可以允許體驗(yàn)差，但是誰敢允許業(yè)務(wù)不閉環(huán)？

而且竊以為，這些工具展現(xiàn)出來的意義更多在于——構(gòu)建自查清單式的思維模式。新手學(xué)習(xí)使用工具，但是應(yīng)該明白并思考工具背后的邏輯，這才會(huì)慢慢走向成熟，構(gòu)建出自己的工具與思維方式，千萬不要把工具奉為圭臬，舍本逐末。

最后一句，在精力有限的時(shí)候，要學(xué)會(huì)聚焦關(guān)鍵任務(wù)（所有的工作都是成本）。

關(guān)于體驗(yàn)

應(yīng)該涵蓋的內(nèi)容

竊以為相比交互，體驗(yàn)才是更應(yīng)該被納入文檔內(nèi)的內(nèi)容，我不知道是因?yàn)槭袌鼋逃€是職位發(fā)展的原因，體驗(yàn)設(shè)計(jì)師被人提及的概率遠(yuǎn)遠(yuǎn)小于交互設(shè)計(jì)師，而其實(shí)在當(dāng)下，體驗(yàn)設(shè)計(jì)師確確實(shí)實(shí)起著不可忽視的作用。

體驗(yàn)設(shè)計(jì)要根據(jù)業(yè)務(wù)階段調(diào)整節(jié)奏，考慮在什么時(shí)刻納入文檔范疇，以及涉及的深度。

關(guān)于修改

善于修補(bǔ)達(dá)到極致

想要沒有問題的文檔，就像想要沒有BUG的程序。只有虛心接納，并善于經(jīng)營，我們才能達(dá)到更好。

關(guān)于溝通

設(shè)定目標(biāo)，階段可控

設(shè)計(jì)經(jīng)驗(yàn)告訴我，要想獲得穩(wěn)步的項(xiàng)目推進(jìn)，就需要在項(xiàng)目之初，提前設(shè)置好關(guān)鍵的溝通節(jié)點(diǎn)，保持項(xiàng)目的每一階段的進(jìn)展變化可控（比如內(nèi)部提案）。

文檔真的不是寫好了交出去就可以了。最好要在前期就與相關(guān)人員展開溝通，理清了了是邏輯與數(shù)據(jù)層面的問題，確定了主要功能和框架之后，才是慢慢完善文檔處理細(xì)節(jié)的時(shí)候。

好的文檔也是善于管理項(xiàng)目進(jìn)度的體現(xiàn)，畢竟這種東西也要消耗大量精力啊。

大家說，產(chǎn)品開發(fā)不用文檔行不行？比如……用愛？

作者：王雪峰，設(shè)計(jì)轉(zhuǎn)產(chǎn)品，擅長創(chuàng)新型產(chǎn)品構(gòu)建，習(xí)慣從系統(tǒng)層次角度思考產(chǎn)品問題。

本文由 @王雪峰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議