在我面試幾百個產(chǎn)品經(jīng)理的經(jīng)歷中，我發(fā)現(xiàn)很多產(chǎn)品新人都在學(xué)習(xí)一些質(zhì)量不高的教程。這些教程通常用前大半截的篇幅來介紹一些形而上的理論，真的到了實操階段卻草草收尾，只教你一些表面的東西，例如流程圖長什么樣、動態(tài)面板怎么畫，很少去討論在真正的工作中，一個PRD到底是怎樣誕生的。所以我想做一些教程給你們看，讓你們能夠真正掌握實操的過程。

但在我整理過去作品的這段時間里，我發(fā)現(xiàn)很少作品可以寫成圖文教程，因為我采用的都是面向?qū)ο蟮脑O(shè)計方法，每個模塊都是靜態(tài)的，模塊之間是互相成就的，不存在一個“線性的流程”。用幾小時視頻加上我的嘴炮旁白是可以做到的，但是用圖文的形式就很難表達(dá)清楚。

每當(dāng)這種時候我都很希望能掌握電影《降臨》中外星人傳授給地球人的表意文字。一個水墨狀的圓弧上，每一個突觸都代表一個事物，突觸之間的位置關(guān)系代表了它們在這個故事里的角色。這個故事沒有開頭和結(jié)尾，你可以用一萬個聲音去敘述這個故事，而故事本身卻并不復(fù)雜，因為時間的一維方向性在這里被打破，只有角色，和角色之間的所有的關(guān)系。

不過這個系統(tǒng)是個例外，它是我上家公司政務(wù)SAAS系統(tǒng)中的一個小功能，叫做簡易表單系統(tǒng)。顧名思義，它比較簡易，因此它有機會寫成圖文教程。

寫這篇教程之前，我花了半天的時間來整理它的提綱，然后花了一天半的時間從以前的文檔里慢慢找到配圖并PS。從提綱來看，雖然沒有介紹到全部的思路，但是我在敘事結(jié)構(gòu)上做了一些取舍，讓你可以更輕松地跟著我的思路走下去，所以現(xiàn)在我們進(jìn)入正題。

注：本文在第3章之前都是抽象邏輯探索，你可能會覺得枯燥而跳過。但是當(dāng)你看完后面的原型章節(jié)之后，你會發(fā)現(xiàn)，你還是得返回來重看一遍。

立項和整理需求

我不會人五人六地告訴你我是怎么調(diào)研市場和研究競品的，因為這個項目不存在。在實際的互聯(lián)網(wǎng)公司工作中，很多痛點是痛到不行的，但是很多時候大家對痛苦的忍受程度、愚鈍程度也是超過你想象的，越大型、人均頭發(fā)數(shù)量越少的公司越是這樣。

這種時候，產(chǎn)品經(jīng)理也很容易因為壓力而隨波逐流，但你的使命就是去做指路人。只要把你的方案表述出來，告訴別人怎么你是怎么解決老板和大家的痛苦的，你就可以立項。調(diào)研報告和各種炫彩的ppt不是必須的，它們通常是因為你的策劃案不夠漂亮，或者大家還不夠相信你。沒有什么ppt能比一個漂亮的落地計劃直接甩在大家臉上更有說服力。

上圖是某個銀行給我們的Excel表，他們想把這套表格搬到線上來，圖里只是其中一個合作銀行的一部分的表格。而且，我們當(dāng)時在做的也不光是銀行的線上表單，剛好還有某個地區(qū)政府的科創(chuàng)局也需要上線一個系統(tǒng)，讓企業(yè)用在線表單填寫信息上傳上去。

當(dāng)你看到這樣的可怕的表格，不是上圖這一份，而是十幾份，你會怎樣做？

“讓我們直接一頁一頁畫成原型，然后交給程序員一個字段一個字段開發(fā)吧！”——在我看到我的產(chǎn)品經(jīng)理莫名其妙地加班、程序員也在莫名其妙地加班之前，他們就是這樣做的。我現(xiàn)在截圖給你看，你會覺得這樣很愚蠢，然而當(dāng)你身臨其境的時候，每天被老板分配的任務(wù)壓到喘不過氣的時候，你真的會很容易失去跳出來說皇帝沒穿衣服的勇氣。

顯然你要去制作一個通用的表單系統(tǒng)，這個表單系統(tǒng)能照顧到這些不同的數(shù)據(jù)填寫需求，讓程序員開發(fā)出來，然后撒手不管，丟給客戶或者運營去配置具體的數(shù)據(jù)。

很多產(chǎn)品經(jīng)理不知道去分辨老板哪些指令是專業(yè)的，哪些是業(yè)余的，自己甘心做一個“需求翻譯器”，還納悶為什么自己的需求不被人好好執(zhí)行。其實你的方案能讓大家少加班，還能讓大家出品更好，你的威信就在不斷建立，大家就會把你當(dāng)做指揮官。

當(dāng)遇到客戶或者老板丟給你十幾張Excel表的時候，你首先要看這些表格是不是規(guī)范的。如果是一張大寬表，所有的數(shù)據(jù)都被整理得井井有條的，那就不需要去梳理它，可以直接走下一步。但是如果你遇到的是我這樣的，不同的幾個機構(gòu)給的不同的表格，而你想把它們都做成一個表單系統(tǒng)，那你就需要先去好好梳理這些數(shù)據(jù)了。

梳理數(shù)據(jù)時不要挑軟柿子，而是要去挑那些最硬的柿子。比如有些表格要求用戶上傳各種附件，有些表格的行數(shù)是不確定的，有些表格的層級數(shù)量特別多……你并不是要把所有客戶給的數(shù)據(jù)項全部整理到xMind，而是把這些難點在梳理的過程中理順。一旦把這些都理順了，就不需要再繼續(xù)梳理下去了。

我在第二步（右圖）嘗試著把梳理出來的數(shù)據(jù)轉(zhuǎn)化成業(yè)務(wù)模型，新手不要這樣做。因為畫這種模型的基礎(chǔ)，是你已經(jīng)可以很嫻熟地撰寫業(yè)務(wù)邏輯文檔，從而能夠直接憑空想象這些文檔，在大腦里直接把它圖形化。這種能力對我來說，是在我寫過至少80萬字的文檔之后才產(chǎn)生的。

撰寫后端邏輯文檔

大部分產(chǎn)品經(jīng)理不會撰寫后端邏輯文檔，而在傳統(tǒng)的游戲界，這個技能是普遍存在的。這跟互聯(lián)網(wǎng)行業(yè)資金太多，產(chǎn)品經(jīng)理門檻太低有直接關(guān)系，會用墨刀就能做PM，這是多少培訓(xùn)班的謊言。我這么說有的人可能不服，“我明明也寫了很多文字類的文檔啊”。但是大多數(shù)這些文字類的文檔，都是對原型的補充說明，是前端層面的，而不是接口層面的，更不是后端層面的。

抽象后端邏輯是我快速落地一個項目的法寶。考慮周全的后端邏輯直接帶來后端大佬的好心情，后端大佬的好心情直接帶來好的接口，好的接口直接帶來前端大佬的好心情，前端大佬的好心情直接帶來好的用戶體驗。跟后端程序員開會的時候，我大部分時間只跟他們講后端邏輯文檔，至于原型長什么樣子，其實除了接口方面，后端程序員根本不關(guān)心。如果你不能把后端邏輯說清楚，而是一味地說“這個按鈕點了之后就去到哪一頁”，證明你還是在用外行人的眼光來分解一個產(chǎn)品的構(gòu)成。

在你不熟悉后端邏輯文檔的情況下，你可以把本章內(nèi)容放在原型畫完的下一步來做。當(dāng)你嫻熟掌握之后，你會發(fā)現(xiàn)，先寫邏輯文檔可以省下你很多由于業(yè)務(wù)邏輯不清晰而畫出錯誤原型的時間，對于后臺產(chǎn)品來說尤其如此。

不管一個線上表單玩出什么花樣，最終的顆粒都是不同類型的字段，我把它們稱作“簡單字段”。簡單字段沒什么好探索的，無非是文字、圖片、附件、選擇題、聯(lián)動選項等等一些不同類型的字段。這里的關(guān)鍵點是下圖所示的“復(fù)合型字段”。

為什么要設(shè)計這些復(fù)合型字段？

因為在前面梳理這些Excel表的時候你會發(fā)現(xiàn)，很多字段之間是有內(nèi)在關(guān)聯(lián)的，而我們設(shè)計一個后臺系統(tǒng)不管它再復(fù)雜，最終也是為了讓用戶填表的時候心情更爽。

• 聯(lián)合字段的目標(biāo)：在用戶端把幾個字段連在一起，消掉它們之間的間距，讓用戶知道這幾個字段是一起的；
• 主從字段的目標(biāo)：幾個字段也是一起的，但是它們之間有從屬關(guān)系。這個時候哪個字段在最上面，就代表它是老大。例如，主字段是“2016總營收”，而兩個從屬的字段是“其中高新科技收入”和“其中醫(yī)藥產(chǎn)品收入”；
• 多條組的目標(biāo)：我們不知道用戶要填多少項數(shù)據(jù)，只能粗略地設(shè)定一個上限，讓用戶自由添加條目。例如我們要求用戶填寫他公司的股東信息，我們只知道用戶每個股東的信息都要填寫姓名、職位和占股比例，但是具體用戶要填多少條，是用戶自己點“添加”按鈕的次數(shù)來決定的；
• 二維表的目標(biāo)：有些數(shù)據(jù)是由橫縱交錯的行和列組成的，例如財務(wù)報表，縱向是具體的財務(wù)報表數(shù)據(jù)，橫向是時間軸。這種表格顯然不管是在網(wǎng)頁端還是手機端，都應(yīng)該跳轉(zhuǎn)到一個單獨的頁面來填寫。

所以這個時候就可以寫字段部分的后端邏輯文檔了。不管這些字段在手機里的交互能玩出什么花樣來，我們現(xiàn)在這一步只需要關(guān)注它在后端儲存哪些屬性，以及管理員可以對它進(jìn)行什么操作（我在文檔里用“func_”表示）。

簡單字段是字段的最小顆粒，而復(fù)合型字段是對這些簡單字段的進(jìn)一步拼裝。不過上圖其實有誤，因為我前面介紹的復(fù)合字段有4種，而上圖文檔里只有2種，因為我在結(jié)合兩三個產(chǎn)品文檔來寫這個教程，請大家假裝看到我寫對了吧。

下一步就是把這兩種字段封裝起來，把它們統(tǒng)稱“獨立字段”。在設(shè)計后端文檔的時候，什么情況下需要封裝呢？

就是當(dāng)你搞了幾種東西，而這幾種東西有很多統(tǒng)一的屬性，或者在很多情況下需要統(tǒng)一的管理。例如，你山寨一個小微博功能，用戶分為普通、黃V、藍(lán)V，顯然你應(yīng)該在“用戶”層面封裝一層，然后把通用的功能例如關(guān)注、發(fā)推等等都放在這里來描述。

1. 字段的基本屬性：例如一個字段的標(biāo)題叫什么，描述是什么；
2. 字段的額外屬性：其實，設(shè)計到額外屬性的時候，我才覺得有必要把簡單字段和復(fù)合字段封裝起來。因為在給這些字段附加一些buff的時候，不管它是什么類型的，運營人員都應(yīng)該直接當(dāng)做一個對象來操作。例如，運營人員決定把8個字段構(gòu)成的“股東信息”標(biāo)記成注冊必填，那么顯然它們要作為一個整體來對待，不準(zhǔn)運營人員節(jié)選其中的某些字段來標(biāo)記。否則，整個系統(tǒng)的重心會被打亂；
3. 字段的操作：同理，一個字段也好，一串關(guān)聯(lián)的字段也好，對于操作來講都是整體的。即使復(fù)合字段內(nèi)部有另外的操作，也不影響它作為一個整體進(jìn)行操作；
4. 字段數(shù)據(jù)的儲存：略。

接下來你就要考慮，剛才形成的那些一個個獨立字段，要怎樣進(jìn)一步儲存起來？

在剛才我們梳理數(shù)據(jù)的時候，你會發(fā)現(xiàn)這些數(shù)據(jù)是一層一層裝起來的，而且不同的甲方在歸類這些數(shù)據(jù)時的偏好也不相同。有些可能比較喜歡套娃，五六層目錄才看到數(shù)據(jù)；有些數(shù)據(jù)量比較少，一兩層數(shù)據(jù)就可以搞定。所以獨立字段最外面肯定是由N層目錄包裹起來的。我們把目錄做成套娃的模樣，甲方爸爸喜歡多少層套娃，我們就給他多少層套娃。

但是，是不是用戶打開最后一層套娃之后，就直接看到一個個字段了？

這又需要你從后臺的思維跳脫出來，去考慮用戶體驗的事情了。

之前我看到一個網(wǎng)友的提問：“HR說我只有后臺經(jīng)驗，所以覺得我不具備用戶端方面的才能”（大意），我想說，HR這個行業(yè)的平均水平可能還不如產(chǎn)品經(jīng)理的平均水平，牛逼的后臺產(chǎn)品經(jīng)理設(shè)計任何一個后臺功能的時候，都會去想象它在前端會長什么樣。后臺直接決定了一個產(chǎn)品的用戶端好不好用，而反過來，如果你只設(shè)計C端，而不了解后端，那么你設(shè)計的東西可能在數(shù)據(jù)結(jié)構(gòu)上完全沒法跟服務(wù)器搭上，那么你想它怎么落地呢？

這套后臺做好之后，它所定制的表單，用戶在手機和網(wǎng)頁都可以訪問，兩個端的設(shè)計也會有不同。這個時候最好的辦法就是去思考它在手機端的效果。手機的屏幕小，對體驗的要求更苛刻，如果你的設(shè)計在手機走得通，那么在網(wǎng)頁端只會走得更通。

在手機端YY（不一定要畫出原型來）之后你會發(fā)現(xiàn)，最后一層數(shù)據(jù)的體驗是上圖這樣才會比較舒服。當(dāng)用戶進(jìn)到某個最終的目錄，他首先會看到一些入口（左圖），這些入口點進(jìn)去就是一個小型的表單（右圖）。這樣設(shè)計之后，用戶的填表壓力就被拆解了，同時，用戶進(jìn)入一個小表單之后，上下滑動就可以填寫所有的數(shù)據(jù)，不需要再左右跳轉(zhuǎn)層級了。

所以這個小表單我把它定義為“數(shù)據(jù)體”。一堆有關(guān)聯(lián)的字段裝進(jìn)一個數(shù)據(jù)體里，然后這個數(shù)據(jù)體放在目錄里，最后形成整個業(yè)務(wù)的表單。

你可能會想，我直接讓前端把最后一層目錄自動展示成這樣不行嗎？這樣不是更簡潔嗎？為什么還要多一個“數(shù)據(jù)體”的概念？

這是因為——

第一，數(shù)據(jù)體只能儲存平級字段，從邏輯上直接避免字段跟目錄混搭。這樣就能有效地保證，用戶面對的都是一整頁的字段，上下滑動就可以填寫完畢。我們考慮重要功能的時候，一定要假設(shè)運營人員是懶惰的，是跟你完全對著干的，在重要的用戶體驗上，要用邏輯的強制性來對抗人性的普遍弱點。正因為運營人員可能是懶惰的，所以當(dāng)你設(shè)計了數(shù)據(jù)體之后，他更傾向于把同類的數(shù)據(jù)全部裝進(jìn)一個數(shù)據(jù)體，而不是勤勞地創(chuàng)建多個數(shù)據(jù)體，這就保證了用戶填表的爽快感。

第二，每個數(shù)據(jù)體都是有主題的。例如，某個數(shù)據(jù)體叫做“個人信貸記錄”，里面有幾十個字段讓用戶填寫這方面的數(shù)據(jù)。那么，它需不需要整體的教程？在未來需不需要作為一個討論話題開放給用戶社區(qū)？所以，當(dāng)你遇到這種業(yè)務(wù)上有必要歸類的東西時，你可以考慮它的未來場景。如果在未來它應(yīng)該具備一些場景，那么你就可以提前把它設(shè)計成一個獨立的主體。

根據(jù)上面的討論，數(shù)據(jù)體和目錄的文檔就寫出來了，整個后端邏輯文檔的主體就大概成型了。文檔寫好之后，你再設(shè)計相應(yīng)的后臺原型會發(fā)現(xiàn)真的相當(dāng)輕松，你可以開著音樂來畫原型，因為你在大的方向上不可能有什么遺漏。比如有了上圖結(jié)尾的“目錄的操作”之后，當(dāng)你畫到目錄的原型時，你難道會漏掉“調(diào)整排序”這個按鈕嗎？

找到原型的套路

對于一個任意復(fù)雜度的后臺系統(tǒng)來講，只要你能寫出上面的邏輯文檔來，那么其實你的原型已經(jīng)可以consider it done了。只有畫出來好不好看、好不好用的區(qū)別，沒有功能實現(xiàn)上的區(qū)別。不過恰好那段時間我比較閑，所以畫了一個很規(guī)范的單頁應(yīng)用原型。也正因如此，我選了這個產(chǎn)品來寫教程。

對于一個專業(yè)寫文檔的產(chǎn)品經(jīng)理來講（不知道什么時候起，追求專業(yè)的文檔被當(dāng)做一個產(chǎn)品經(jīng)理可有可無的特性？好像還會被人當(dāng)做手作人那樣帶點居高臨下的味道？各種數(shù)字報表和商業(yè)計劃ppt被當(dāng)成了時代首選技能？），沒有固定的原型套路，只有最適合當(dāng)前產(chǎn)品的原型套路。如果不是以前的套路，那就去發(fā)明一種新的套路，這樣你的套路就會越來越多，所以接下來我們就看看這個產(chǎn)品適合哪種套路。

在不知道怎么動手的時候，與其在那里不斷規(guī)劃（實際上是拖延癥），往往不如直接開工把最硬的骨頭先啃下來，對這個產(chǎn)品來講先去畫主界面就對了。上圖就是我畫的主界面。畫完之后你會發(fā)現(xiàn)，整個后臺其實只有這一頁。左邊是目錄，中間是這個目錄下的數(shù)據(jù)體，而右邊是選中了一個數(shù)據(jù)體之后的具體配置。

但是這一頁是分三種狀態(tài)的，除了平時的狀態(tài)之外，還有兩種特殊的狀態(tài)。當(dāng)用戶在目錄里選擇的不是普通的目錄，而是回收站的時候，由于回收站的功能會比較受限，所以頁面的布局和元素也出現(xiàn)了閹割，從而影響了整個頁面的布局。然而這三種狀態(tài)又有很多共用的元素。如果在原型里把它們分開去講述，顯然就是把工作量擴大了至少三倍。

在純粹具象的原型設(shè)計思路上，這個頁面分為三種狀態(tài)，意味著三份重復(fù)勞動；而從最抽象的眼光來看，這三種狀態(tài)有100%的元素都是共用的，就好像除了靈魂和記憶之外，我們可以把一個人看做等價于他身上的任意一個、沒有癌變的細(xì)胞，但是用這種眼光去欣賞你的同類又顯得有點乏味了。

這兩種做法都比較極端，你的目標(biāo)就是去找到其中的平衡點，也就是我在前面提到的，去找到符合這個產(chǎn)品的套路。每個人的性格都不一樣，原型畫風(fēng)和用戶理念也不一樣，套路自然也不一樣。以我個人比較潔癖的性格為例，以下是我找到的套路。

1. 把三種主界面的形態(tài)畫成三個頁面（使用“CASE_”前綴）；
2. 把頁面的共同元素抽離出來，作為一個單獨的對象（使用“#obj_”前綴，其中井號在我的原型中的意義是：它并不代表一個真實的頁面，只是某個頁面中的一個提取出來的東西，例如對象、彈窗或流程）來描述；
3. 把這個對象做成超鏈接小方塊，扔進(jìn)使用這個對象的頁面里。一個對象在多少個頁面出現(xiàn)，你就扔多少個小方塊在這些頁面，而具體這個對象的文檔，你只需要維護(hù)一頁；
4. 在原型的第一頁寫上閱讀說明。上圖的閱讀說明是我從其它原型里翻出來的，所以有些東西對不上號，請大家假裝看到了正確的閱讀說明。

我這樣說比較抽象，下面先舉一個簡單的例子——

如上圖所示，主界面的兩個狀態(tài)都出現(xiàn)了數(shù)據(jù)體列表，所以我把鏈接到數(shù)據(jù)體列表的小方塊扔進(jìn)了這兩頁中。程序員不管在其中那一頁，只要他說“這個列表是怎么展示的？哦，下面有個小方塊，我點進(jìn)去看一下”，他都會進(jìn)到下面這個文檔里。

我做原型基本上都是用這些小方塊來跳轉(zhuǎn)的，除非是用來給客戶演示的原型，否則我很少在頁面元素本身做交互。都是把所有跳轉(zhuǎn)的按鈕放在小方塊里，然后單獨擺在頁面上。頁面是頁面，方塊是方塊。為什么這樣？因為迭代的時候太舒服了，我從來不用去尋找動態(tài)面板里面的動態(tài)面板里面的交互，所有的鏈接都是平鋪出來的，所見即可拖。

有的人就要說了，“Axure不是這樣用的，你得做交互！”——我為什么要做交互？

我們不妨深入想一想這個問題，就是我們?yōu)槭裁匆鼜腁xure設(shè)計思維的問題。Axure并不是一個純粹的原型設(shè)計軟件。從使用體驗上，他要照顧新手，所以搞了很多所見即所得的效果，但是它的這些效果實際上是高不成低不就的。

設(shè)計動態(tài)交互上，為什么不去畫時間軸或者直接用AE呢？幾個吭哧吭哧的動畫，幾個動態(tài)面板的特效，就能代表所有瀏覽器和移動設(shè)備的交互效果嗎？

從用戶群上，他更不是針對產(chǎn)品經(jīng)理的，而是針對那些要看原型的外行老板們。老板們不會裝專用客戶端，所以Axure最終輸出的是網(wǎng)頁，因此它的所有交互事件也都建立在瀏覽器事件上，同時它還只是瀏覽器的閹割版，不論是事件的傳遞、一個前端對象的狀態(tài)切換，還是頁面元素之間的布局關(guān)系，全都不如直接寫代碼來的簡單。

例如在iOS開發(fā)App時，想要讓一個按鈕左右離屏幕20pt，自動拉伸，并且懸浮在頁面底部100pt處，你只需要填幾個數(shù)字就行了，而在Axure里你反而要寫很多的邏輯才能實現(xiàn)。

就是這樣的繞路實現(xiàn)，還被很多人當(dāng)成技術(shù)的炫耀，我覺得跟整天探索“茴”字有幾種寫法是沒有任何區(qū)別的。更不用提Axure那種故作高級的態(tài)度了，例如把回收站功能和圖片壓縮選項都取消掉，好像這樣顯得比較“簡潔”。

Axure它只是一個工具，同時很不幸的是，目前（我拿到投資之前），我們基本只有這個工具能用。但這并不影響工具的使用者不是去服務(wù)工具，而是讓工具服務(wù)使用者。

話說回我怎樣讓Axure服務(wù)于我，我們接著看我的原型。

有堅不摧的對象繼承鏈條

如果一個產(chǎn)品上線之后不需要迭代，畫原型只需要一個版本就結(jié)束工作，那么我接下來說的全都是廢話。所以我在下文展示原型圖的時候會重點告訴你：為什么對于產(chǎn)品迭代來講，我需要這樣的設(shè)計。

接下來就承接上一章的設(shè)計套路，為你展現(xiàn)原型里最重要的“數(shù)據(jù)體”模塊的“對象繼承鏈條”。你現(xiàn)在不需要知道這個鏈條具體的概念，只需要打起精神來，跟著我的7個連環(huán)鏈條（倒敘）走下去，不要中途走神。

鏈條第7環(huán)：數(shù)據(jù)體

數(shù)據(jù)體就是前文提過的，主界面中最主要的一個模塊，用來配置一個具體的數(shù)據(jù)體。還記得數(shù)據(jù)體在后端邏輯文檔里面的規(guī)劃嗎？

沒錯，數(shù)據(jù)體就是用來直接裝載字段的東西。所以數(shù)據(jù)體在原型里，除了自身頭部信息之外，主要就是用來裝載具體的字段了。另外，上圖中所有的菜單功能，你如果翻回前面的后端邏輯文檔，你會發(fā)現(xiàn)我早就已經(jīng)用“func_”把它們都規(guī)劃完了。這就是我說的，后端邏輯文檔寫完之后，你可以聽著音樂畫原型。

鏈條第6環(huán)：獨立字段

從剛才標(biāo)注了獨立字段的鏈接，就可以進(jìn)入獨立字段的說明頁。回憶一下后端邏輯文檔，獨立字段是什么？

沒錯，獨立字段是我們提前規(guī)劃好的，對兩種字段的封裝，這兩種字段分別是“簡單字段”和“復(fù)合型字段”。所以，必然地，獨立字段的具體展示也要分兩種情況來介紹給前端程序員了。

你問后端程序員去哪了？

后端程序員看完我的邏輯文檔早就開發(fā)完了，正在催著前端程序員趕緊聯(lián)調(diào)。如果前端程序員在這一頁粗心大意，沒有按照我的設(shè)計把獨立字段的具體展示分成兩種，我根本不用去管，后端接口的報錯已經(jīng)用滿屏的紅色閃現(xiàn)在前端程序員的屏幕上了。

鏈條第5環(huán)：添加或修改字段中轉(zhuǎn)頁

在前面兩個環(huán)節(jié)，你看到了數(shù)據(jù)體，也看到了數(shù)據(jù)體下面的獨立字段。這兩個環(huán)節(jié)不是平級的，但是它倆都具備添加或修改字段的功能。

為什么會這樣？因為數(shù)據(jù)體本身肯定可以添加字段，而數(shù)據(jù)體下面的具體字段，你得提供再次修改這些字段的功能啊，你不能讓運營的人每次錄入都簽字無悔啊。

但是，問題在于，“添加修改簡單字段”和“添加修改復(fù)合型字段”我是分成兩個具體頁面來畫原型的。從數(shù)據(jù)體的菜單添加一個字段的時候，用戶在菜單里直接就選擇了一個字段類型，所以是直接前往具體的原型頁面。而修改一個獨立字段的時候，由于我已經(jīng)抽象了兩種字段的菜單，所以我是不知道你到底要去哪個具體原型頁面的。

這個時候，只要加多一個上級的中轉(zhuǎn)頁面，然后把這兩頁具體文檔變成它的子頁面就行了。然后，你在中轉(zhuǎn)頁面里把這兩頁的鏈接放進(jìn)去。使用這個功能時，當(dāng)邏輯不確定的時候，你就鏈接中轉(zhuǎn)頁；邏輯很確定的時候，你就鏈接具體的文檔。你可能要問了，我為什么要搞這么麻煩呢？因為這個中轉(zhuǎn)頁對以后的迭代是有重大意義的。

在以后迭代的時候，如果字段的復(fù)合類型變多了，那么添加修改字段的文檔也就不止兩頁了，可能有十頁。到了那個時候，如果你要增加第11種文檔，你要把整個原型所有用到添加修改字段功能的頁面全部更新一遍。

而我這樣做就不需要了，因為其它頁面只是指向這個中轉(zhuǎn)頁，你每次在中轉(zhuǎn)頁下面增加一個頁面，就記得把它的鏈接也放進(jìn)中轉(zhuǎn)頁，這不就不用整個原型改一遍嗎？

鏈條第4環(huán)：修改復(fù)合型字段

從剛才所說的中轉(zhuǎn)頁或者具體的鏈接，我們就進(jìn)入了“添加或修改一個復(fù)合型字段”的頁面。復(fù)合型字段除了本身的字段描述信息之外，主要就是由簡單字段構(gòu)成的了。所以這個模塊主要的功能自然就是去添加、修改和刪除這些簡單字段。

再次重申，由于復(fù)合字段中可以對簡單字段進(jìn)行哪些操作，我們早就在后端邏輯文檔里用“func_”整理完畢了，所以這里你可以完全放空大腦就能無遺漏地把這些功能菜單設(shè)計齊全，根本輪不到別人挑你的BUG。

我的記憶力極差，初中的時候背一首唐詩背到放學(xué)一小時老師還不準(zhǔn)我回家，到現(xiàn)在我女朋友還整天說我是花生仁那么大的腦袋。但是我發(fā)原型文檔給程序員時，每次都說“一個設(shè)計BUG請吃飯一次”，然而最近兩三年基本沒人吃到我的謝罪大餐，靠的就是先寫邏輯文檔。

鏈條第3環(huán)：修改簡單字段

在前面一個環(huán)節(jié)里，你會發(fā)現(xiàn)復(fù)合型字段是由簡單字段構(gòu)成的，所以，雖然在文檔中，修改簡單字段和修改復(fù)合字段是平級的。但是用戶在復(fù)合型字段中修改或者添加一個簡單字段的時候，實際調(diào)用的是修改簡單字段的功能。所以，除了第5環(huán)節(jié)的中轉(zhuǎn)頁之外，復(fù)合型字段也可以調(diào)用這個修改簡單字段的功能。

修改簡單字段的功能，就是終于接觸到最終的實際字段了。但是我在上圖里為什么只畫了“選擇題”這一種情況呢？其它類型的字段我為什么沒畫在這里，而是又鏈接到其它頁面呢？難道我就這么喜歡套娃？

鏈條第2環(huán)：字段表傳送門

不是我喜歡套娃，而是“簡單字段的配置與展示”出現(xiàn)的地方飄忽不定。所以我必須到處安插傳送門，至于這個傳送門通向什么領(lǐng)域，你馬上就會知道。

鏈條第1環(huán)：字段表

所有的傳送門都通向這張字段表。我們在這里把所有類型字段的展示、配置都放進(jìn)來，然后好好維護(hù)它。

為什么要這樣做？

想必你也知道了——這畢竟是一個表單系統(tǒng)，表單系統(tǒng)的基石就是字段，字段在未來的擴充肯定是相當(dāng)頻繁的。

這張表看起來現(xiàn)在還沒什么，但是如果不去這樣設(shè)計它，那么你每一次迭代這個系統(tǒng)，都要花一半的時間去修改每個具體頁面所展現(xiàn)的字段。真要這樣頭鐵，那么恭喜你，你離人類的本質(zhì)越走越近了。

你說，你沒有我這么多的后臺設(shè)計經(jīng)驗，不知道字段表需要拆出來單獨維護(hù)，不知道要把頻繁更新的功能放進(jìn)中轉(zhuǎn)頁，也不知道不同層級的模塊要怎么拆分、怎么互相連接？再看一眼這一章的標(biāo)題：“有堅不摧”的對象繼承鏈條。

沒有任何文檔撰寫套路是無堅不摧的。如果有一篇文章在你的feed里冒出來，告訴你“掌握這20個技巧，就能讓你設(shè)計一個專業(yè)的XXXX原型”，那么你應(yīng)該趕緊點進(jìn)去屏蔽這個人，然后再舉報這篇文章，然后再返回你的feed點擊“我不感興趣”。

你唯一能做的，就是每次反省自己原型設(shè)計的問題，每次迭代的時候看一看自己做了多少無用功，把每個周末的時間都花在完善自己的文檔上，力圖讓它達(dá)到你現(xiàn)在的100分。然后等下一次迭代的時候，輕蔑地看它一眼，說一聲“垃圾原型，50分鑒定完畢”，存?zhèn)€版本，然后開一個新的文檔，把有用的東西復(fù)制進(jìn)來，把沒用的結(jié)構(gòu)打散扔掉，然后再力圖把它變成新的100分……

結(jié)語

在結(jié)語部分，我們先用一張關(guān)系圖來回顧一下，前兩章我花了那么大的篇幅來講原型的繪制，我到底講了什么。

是的，我檢查了很多遍，我仔細(xì)檢查了右圖的每個方塊、每條連線，最后我才說服自己相信，這張關(guān)系圖已經(jīng)完整、沒有遺漏地，表達(dá)了我在前面兩個章節(jié)煞費口舌地描述的所有模塊之間的關(guān)系。

我統(tǒng)計了一下，那兩個章節(jié)我寫了大概4400字，其中用來表述模塊之間的關(guān)聯(lián)關(guān)系的，我們算它有3000字。而圖表里面的漢字是128字。圖表里除了漢字之外，就只剩下方塊、位置、線條這些圖形關(guān)系了。所以，圖形帶來的文字表達(dá)效率之比是24比1。

——你需要注意的是，我畫的是關(guān)系圖，而不是流程圖。流程圖是具有方向性的，本質(zhì)上只是更簡潔的文字。而關(guān)系圖是沒有方向性的（這就是為什么我的連線沒有箭頭），從任何一個局部都可以順著線條向外推導(dǎo)，推導(dǎo)出任何你想講述的故事。

關(guān)系圖是簡潔、低調(diào)和安靜的，但正如老劉說的：“記得大三的一次信息課中，教授掛出了兩幅大圖片，一幅是畫面龐雜精細(xì)的《清明上河圖》，另一幅是一張空曠的天空照片，空蕩蕩的藍(lán)天上只有一縷似有似無的白云。教授問這兩幅畫中哪一幅所包含的信息量更大，答案是后者要比前者大一至兩個數(shù)量級”。

這就是我在文章開頭提到的，我多么希望我能掌握《降臨》里外星人使用的表意文字。為了講清楚我的產(chǎn)品設(shè)計思路，我講了很多的話，你花了很久的功夫來閱讀。但是實際上，我真正希望你掌握的，是這門安靜的語言，是純粹圖形化的思維。我指的不光是前面的原型繪制部分，其實更包括后端邏輯文檔的部分，它們都可以被圖形化。

事實上，在我寫完這篇教程之前，我根本不知道原來我要講這么多的話。整個產(chǎn)品的設(shè)計過程里，我的腦子里基本是不存在語言的，只有一個個的形狀像狄拉克海那樣，從虛空里不斷潮起潮落。你把它們摘下來，不斷地重組它們，當(dāng)你把它們捏成一團一團之后，你會發(fā)現(xiàn)，你已經(jīng)完成了對一個產(chǎn)品的整個設(shè)計過程。

當(dāng)你越來越適應(yīng)這種圖形化思維之后，你會發(fā)現(xiàn)，你能比別人快很多倍地構(gòu)思一個復(fù)雜的系統(tǒng)出來。唯一的缺點是，你的圖形思維模塊會侵占你的語言中樞——你更說不過那些喜歡講ppt的人了。

作者：黃聯(lián)樵，微信：arubagod

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

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