上一篇?我們圍繞「產(chǎn)品的第一個版本」展開分析，接下來，我們繼續(xù)來看下設(shè)計確認(rèn)的過程。

設(shè)計確認(rèn)

首先我們來看下「設(shè)計確認(rèn)」的含義。

「設(shè)計確認(rèn)」包括原型確認(rèn)和 UI 確認(rèn)兩大步，這是研發(fā)和測試可以開始工作的前提。也就是說，原型和 UI 確認(rèn)了，研發(fā)團隊才能干活。

那產(chǎn)品經(jīng)理和 UI 確認(rèn)圖的時候，研發(fā)在干什么呢？劃水嗎？

一般來說，「設(shè)計確認(rèn)」提前一兩個開發(fā)周期完成，以確保研發(fā)工作不會出現(xiàn)斷檔。也就是說，研發(fā)在做上一個開發(fā)周期的功能時，產(chǎn)品經(jīng)理和 UI 就要開始下一個周期的「設(shè)計確認(rèn)」。

曾經(jīng)年少的我認(rèn)為研發(fā)出現(xiàn)斷檔，讓大家在一段忙碌期后休息休息也是好事。直到有一天 Leader 和我核算了一下我們部門的成本，研發(fā)斷檔一天的成本是 5k+ （10 個人平均一人一天 500 塊），我才開始認(rèn)真對待這件事情。關(guān)注成本可以說是產(chǎn)品經(jīng)理的必備技能之一，而這也讓我對一些事情的看法和之前相比有了明顯的不同。

原型確認(rèn)

「原型確認(rèn)」就是需要確認(rèn)原型啦。嗯，這是一句正確的廢話。不過，需要說明的是，這里的「原型確認(rèn)」是產(chǎn)品經(jīng)理確認(rèn)的、并經(jīng)過評審的下一個開發(fā)周期的原型。

為什么需要評審？一方面避免產(chǎn)品經(jīng)理自嗨，另一方面多方評審可以保證整個團隊在做最重要的事情。誰來參加評審呢？這個每個公司的要求不一樣，一般會有技術(shù)、產(chǎn)品、UI 等多方角色參與。

1. 功能打包

對于我們的產(chǎn)品「簡報生成器」來說，由于簡報的信息源因為實現(xiàn)而導(dǎo)致無法讓用戶自定義，導(dǎo)致產(chǎn)品的核心和我們之前所理解的有所不同。所以，我們在做下一期的功能列表的時候，需要重新評估，也就是所謂的「功能打包」。

每個開發(fā)周期都是需要重新評估功能列表，重新審視之前的「產(chǎn)品規(guī)劃」，以保證下一個開發(fā)周期做最正確的事情。因為在產(chǎn)品開發(fā)過程中，我們總會遇到一些問題，從而導(dǎo)致周期調(diào)整或者功能調(diào)整，甚至在上線后也很難保證所有已知的 Bug 都被解決。而這些遺留問題都需要記錄在案，進(jìn)入功能列表中，以待下個開發(fā)周期被選擇或被解決。

由于簡報信息源的問題，導(dǎo)致「簡報生成器」的功能更偏向于簡報的信息展示，信息源的添加需要產(chǎn)品經(jīng)理提需求，程序去實現(xiàn)，才能保證對應(yīng)信息可以展示。

因此，「簡報生成器」下一個階段最重要的兩個功能點是：信息源的添加和信息的展示。而不是我們之前規(guī)劃的「簡報設(shè)置」，甚至說「簡報設(shè)置」這一大類都不復(fù)存在了。

這么看起來，「簡報生成器」這個產(chǎn)品名字似乎不太合適呢，更準(zhǔn)確地叫法應(yīng)該是「簡報」。相應(yīng)地，產(chǎn)品的定位也會相應(yīng)隨之改變，一個提供簡報信息集合的產(chǎn)品。按理說，產(chǎn)品的定位修改后，要重新進(jìn)行競品分析什么的，這里我們就暫且略過，可能和之前的文章分析內(nèi)容不太一樣，但是分析的思路和方法是一致的。感興趣的朋友可以翻看之前的文章。

接下來，我們繼續(xù)分析：信息源的添加和信息的展示這兩部分。

（1）信息源的添加

首先，信息源的添加是不需要畫原型圖的，只需要產(chǎn)品經(jīng)理提供信息獲取的規(guī)則。那對于「簡報」來說，首先需要提供如下幾類信息：

1. 互聯(lián)網(wǎng)產(chǎn)品
2. 開發(fā)者資訊
3. 創(chuàng)投 | 融資 | IPO
4. 熱門問答

我們以「互聯(lián)網(wǎng)產(chǎn)品」為例，給出具體的信息提取規(guī)則。從信息源上來講，「互聯(lián)網(wǎng)產(chǎn)品」包括以下幾個類型：小程序、產(chǎn)品文章、iOS 應(yīng)用、Android 應(yīng)用、Mac OS 應(yīng)用、Windows 應(yīng)用。小程序從「知曉程序」獲取，需要獲取每日最新的小程序名稱及說明。如果你是這么寫規(guī)則的，那么你一定會被挑戰(zhàn)。

開發(fā)同學(xué)：「知曉程序」是個網(wǎng)站吧？我需要全網(wǎng)爬嗎？這個工作量有點大哦…

產(chǎn)品經(jīng)理 ：當(dāng)然不是啦，只需要爬取首頁的「最新」，誰讓你全網(wǎng)爬了。

開發(fā)同學(xué)：那你不說清楚。另外，我怎么知道什么是「每日最新」？

產(chǎn)品經(jīng)理：點小程序進(jìn)去，不是有個「發(fā)布時間」嗎？它等于「昨天」就是最新的。

開發(fā)同學(xué)：還要點進(jìn)去，好吧好吧……那什么是「小程序說明」？

產(chǎn)品經(jīng)理：就是點進(jìn)去那個「產(chǎn)品介紹」啊……

開發(fā)同學(xué)：?

額，這下終于明白要把事情說清楚是有多么重要了吧。整理一下，小程序類信息的獲取規(guī)則如下所示：

• URL：https://minapp.com/
• 爬取的內(nèi)容：首頁里的 Tab 為「最新」的內(nèi)容，需要爬取對應(yīng)的小程序名稱、小程序說明、小程序的發(fā)布時間、小程序的 URL。其中完整的小程序說明和發(fā)布時間可通過點擊對應(yīng)的小程序進(jìn)入詳情頁查看。
• 爬取的時間：至少能查到昨天和今天的數(shù)據(jù)即可。

其實，就算你這么寫了，可能還是會被挑戰(zhàn)，比如他們會問我一次爬多久的數(shù)據(jù)啊、爬取的數(shù)據(jù)怎么存儲啊、對爬取的數(shù)據(jù)格式有沒有什么要求啊……問題是列不完的，只能遇到一個解決一個嘍。

剩下的幾類可按照與「小程序」同類的需求描述即可。一般我會把需求寫在 Axure 的頁面里（一般是新建一個頁面，將其命名為「需求規(guī)則描述」），一方面團隊成員不用頻繁切換軟件查看，二來規(guī)則和原型也在一起也方便自己查看。

（2）信息展示

接下來，我們來看「信息展示」這部分。這部分肯定不能只描述需求規(guī)則啦，原型圖肯定是要畫的。

那一般用什么軟件來畫呢？常見的軟件為 Axure。產(chǎn)品新人大多會花很多時間學(xué)習(xí)軟件的使用，很關(guān)注怎么用 Axure 畫出漂亮的界面什么的，卻常常忘記了最重要的一點，工具是用來表達(dá)想法的，能熟練使用 Axure 是產(chǎn)品經(jīng)理的必備技能，但不代表熟練使用 Axure 就能成為產(chǎn)品經(jīng)理，大家千萬不要本末倒置。

要畫好「信息展示」的原型，需要了解有哪些信息（和第一步「信息源的添加」息息相關(guān)，也可以反過來幫助我們檢驗第一步規(guī)則是否存在缺失），其次是需要展示哪些信息，最后才是怎么展示。這里也可以發(fā)現(xiàn)怎么展示也就是 Axure 畫原型是最不重要的一步，之前的思考分析過程才是最重要的。所以很多人認(rèn)為產(chǎn)品經(jīng)理就是「畫原型」的，那我只能說「你怕是對產(chǎn)品經(jīng)理有什么誤解」。

經(jīng)過一系列的分析，我把原型圖畫出來了，如下圖所示。當(dāng)然這里的圖只是其中一個界面，你可不能只給研發(fā)同學(xué)一個界面就當(dāng)作原型圖啊。篩選什么的效果怎么著都得畫出來。

2. UI 溝通

如果你想要和某一個人高效溝通，那你一定要了解對方關(guān)注的點在哪里。

那么 UI 關(guān)注的點在哪里呢？

對原型圖的顏色、字體、間距、排版、布局等信息 UI 一概不關(guān)注，因為產(chǎn)品經(jīng)理給出的這些信息，經(jīng) UI 之手后可能「面目全非」，會更加精致、美觀。

那 UI 到底關(guān)注什么？

1. 信息的關(guān)聯(lián)性。哪些信息是有關(guān)系的，這樣他們設(shè)計的時候會考慮將其「放在一起」。
2. 信息的重要程度。哪些信息是需要用戶特別注意的或者說用戶最關(guān)注哪些信息，這將意味著他們會出現(xiàn)在界面的哪個位置。
3. 信息的長度或邊界值。哪些信息可能會比較長，這會對頁面的布局以及元素的長度有影響。
4. 特殊狀態(tài)。必填項未填寫時的報錯提示、完成提示等。當(dāng)然，這里 UI 只負(fù)責(zé)給出具體的樣式，文案還是需要產(chǎn)品經(jīng)理提供的。

很多時候，UI 可能并不關(guān)注產(chǎn)品的業(yè)務(wù)邏輯，但是一個優(yōu)秀的產(chǎn)品經(jīng)理還是會為 UI 解釋產(chǎn)品的業(yè)務(wù)邏輯，一來了解產(chǎn)品知識會促使 UI 設(shè)計出更合理的界面；二來 UI 也可以幫助產(chǎn)品經(jīng)理出謀劃策，也就是俗話說的「眾人拾柴火焰高」，產(chǎn)品設(shè)計遇到難點的時候，也多個人可以討論。

和 UI 溝通清楚之后，就是 UI 自由發(fā)揮的時間了。對了，還有一個很重要的點，就是要和 UI 溝通設(shè)計完成的 deadline，并及時跟蹤設(shè)計進(jìn)度。請記住，沒有 deadline，基本等于沒有溝通。因為大多數(shù)人的心理就是這樣，你不說什么時候要，那就代表你的事情不著急，我可以無限拖。

（1）PRD（Product requirements document） 文檔

當(dāng)產(chǎn)品經(jīng)理和 UI 溝通完之后，產(chǎn)品經(jīng)理就可以著手編寫 PRD 了。當(dāng)然，如果產(chǎn)品經(jīng)理時間足夠，PRD 完成之后再轉(zhuǎn)交 UI 也是再好不過的事情了。因為溝通之后一些細(xì)節(jié)，UI 想要回顧的話，看 PRD 是再好不過的事情了。

關(guān)于 PRD，我想到之前文章后「小寶」的留言：「如何產(chǎn)出一份高質(zhì)量的 PRD？」

當(dāng)時我的回復(fù)是這樣的：

• 首先，需要明確 PRD 是給誰看的？為什么要寫 PRD？
• 最后，針對看 PRD 的人，只要他們能理解你要表達(dá)的意思，就是一份高質(zhì)量的 PRD。
• 至于格式、形式都不是很重要，達(dá)到溝通的目的最重要，不要為了寫一份高質(zhì)量的 PRD 而去寫 PRD 就好。

平時工作中，我會在原型圖的旁邊標(biāo)注關(guān)鍵的點，以最終形成用于團隊成員溝通的 PRD。我基本很少寫十分詳細(xì)的 PRD 的文檔，一來長度太長，只有測試會仔細(xì)看，開發(fā)大多都不愿意看；二來即使寫了很詳盡的 PRD，團隊之間的溝通過程也是無法避免的。所以，根據(jù)當(dāng)前團隊成員的習(xí)慣，我選擇了在原型圖旁邊標(biāo)注的方式寫 PRD。

網(wǎng)上有很多大佬會寫很漂亮的 PRD 文檔，我不清楚他們平時工作中是否也是這么寫的，也不清楚與之合作的團隊成員是否真的有耐心讀完這樣的 PRD。我只是覺得，PRD 并不能完全替代溝通的過程。不過，詳盡的 PRD 還是有好處的，用于歸責(zé)。如果產(chǎn)品經(jīng)理的 PRD 寫了，研發(fā)最終沒實現(xiàn)，那就可以甩鍋了。但這種情況可以通過項目管理的方式解決。

（2）UI 評審

UI 完成 UI 圖后，產(chǎn)品經(jīng)理一定要參與評審（驗收），以確保 UI 圖完備、準(zhǔn)確?！竿陚洹故侵?UI 提供了所有該提供的界面，包括各種特殊狀態(tài)；「準(zhǔn)確」是指 UI 圖可以準(zhǔn)確表達(dá)產(chǎn)品設(shè)計的理念和想法。

很多時候，404 界面（以及 403、500 界面）、空頁面、搜不出結(jié)果的頁面等 UI 可能會有遺漏，導(dǎo)致不夠「完備」。也有的時候，UI 在設(shè)計界面時會偏離產(chǎn)品設(shè)計的意圖或者按照自己的想法莫名添加一些需求出來，產(chǎn)品經(jīng)理一定要及時糾正。

比如我們在設(shè)計一個數(shù)據(jù)展示界面的時候，UI 加了一個全屏的界面，實現(xiàn)上他跟研發(fā)咨詢過了，可以直接調(diào)瀏覽器的全屏接口，然后他就很驕傲的和我講他的設(shè)計。

UI 小哥哥 ：我們系統(tǒng)里的數(shù)據(jù)不是太多了嗎，我設(shè)計了一個全屏的功能可以全屏顯示數(shù)據(jù)，可以隱藏導(dǎo)航欄和側(cè)邊欄，就可以多展示幾列數(shù)據(jù)。

產(chǎn)品經(jīng)理 ：多展示幾列有必要嗎？

UI 小哥哥：有啊，本來放不下的數(shù)據(jù)全屏的情況下都可以展示出來了，橫向滾動條也省了。

產(chǎn)品經(jīng)理 ：那你知道用戶用的都是多大的屏幕嗎？

UI 小哥哥 ：不管他們用多大的屏幕，我都可以支持啊。是不是很厲害。

產(chǎn)品經(jīng)理 ：據(jù)我所知，使用這個系統(tǒng)的用戶都是 1920 的屏幕，完全不存在你說的數(shù)據(jù)展示不完的問題，這樣的話，這個功能似乎沒什么必要呢？

UI 小哥哥：那當(dāng)我沒說，圖已經(jīng)刪了……

其實還是要看具體的應(yīng)用場景，在當(dāng)前場景下的「全屏」功能，展開后其實也沒多幾行數(shù)據(jù)，不太影響用戶查看數(shù)據(jù)。但是如果是在網(wǎng)頁看博客之類的，可以全屏顯示博客內(nèi)容，不看周圍的廣告，就是一個很好的設(shè)計。就是不知道，公司的廣告收入會不會因此而減少。

（3）設(shè)計確認(rèn)階段的產(chǎn)出

設(shè)計確認(rèn)階段會有兩大比較重要的產(chǎn)出：PRD 和 UI 圖。

• PRD 可以和原型一起提供，這樣方便團隊成員查看。
• UI 圖可以上傳到「藍(lán)湖」（常見的設(shè)計軟件：Sketch、PS、XD 等軟件藍(lán)湖都是支持的），方便團隊成員在線查看，以減少 UI 和研發(fā)設(shè)計圖不統(tǒng)一的情況出現(xiàn)，提高雙方溝通的效率。

總結(jié)

1. 產(chǎn)品規(guī)劃和功能打包之間的關(guān)系是什么？

或許你會說，「產(chǎn)品規(guī)劃」不是已經(jīng)把每個迭代需要做的功能列表確認(rèn)了嗎？為什么這里又冒出來一個「功能打包」，不是多此一舉嗎？

并不是多此一舉啦。首先，我們做的每個決定都是基于現(xiàn)有的認(rèn)知信息之上的，當(dāng)我們做「產(chǎn)品規(guī)劃」時也是如此，我們盡可能做出最優(yōu)的決策。但是隨著產(chǎn)品的不斷迭代、用戶的不斷增加，可能導(dǎo)致之前的「產(chǎn)品規(guī)劃」不再適應(yīng)當(dāng)前的產(chǎn)品版本。

換句話說，之前覺得很重要的功能，現(xiàn)在變得無關(guān)緊要；之前覺得可有可無的功能，現(xiàn)在成了必不可少的功能。這就要求產(chǎn)品經(jīng)理在每個版本開始的時候，重新審視「產(chǎn)品規(guī)劃」，合理地做「功能打包」，給出當(dāng)前版本最適合開發(fā)的功能列表。

可以這么理解，「產(chǎn)品規(guī)劃」是產(chǎn)品的長期規(guī)劃，需要好幾個產(chǎn)品版本逐漸去迭代實現(xiàn)，而「功能打包」是包含在「產(chǎn)品規(guī)劃」內(nèi)的，是當(dāng)前產(chǎn)品版本需要實現(xiàn)的功能。

當(dāng)然或許你會疑惑，為什么產(chǎn)品經(jīng)理在做「產(chǎn)品規(guī)劃」時不能考慮得長遠(yuǎn)些呢，讓「產(chǎn)品規(guī)劃」更加不容易「變」呢？

只能說這個要求很難做到，需要你有足夠的「眼界」，預(yù)測未來可能會出現(xiàn)什么情況；以及過去做產(chǎn)品的「經(jīng)驗」，能夠判斷這里可能會有什么坑；以及一點點的「運氣」。

2. 功能列表 VS 產(chǎn)品規(guī)劃 VS 功能打包

之前的文章評論里有人問過這個問題，這里我們來簡單說明下這三者的區(qū)別。

場景：假設(shè)你剛收到消息，你的閨蜜一會要來你們家吃飯。

產(chǎn)品經(jīng)理：家庭主廚。

用戶：你的閨蜜。

需求：直接需求是「吃飯」，滿足生理需求。間接需求可能是「來談心（吐槽）」，附加需求可能是「晚上睡這里」。

功能列表：好比冰箱里的食材，有菜、肉、蝦等，對應(yīng)一個個小的需求。

產(chǎn)品規(guī)劃：好比利用這些食材，可以做是素菜、大葷、小葷、爆炒蝦等。產(chǎn)品規(guī)劃類似一個菜單，規(guī)定了每個菜需要哪些食材，對應(yīng)需求組的集合。

功能打包：好比關(guān)于這一頓飯，因為閨蜜對蝦過敏，蝦肯定不做了。只能素菜、大葷、小葷了，對應(yīng)當(dāng)前版本的需求集合。

3. 需求池管理

既然每個版本都需要重新做「功能打包」，那是不是會有一個功能列表，以方便我每次從中「挑選」出最合適的功能列表。嗯，這個東西就是業(yè)內(nèi)所說的「需求池」。不過「需求池」里不只有「功能列表」，還有上期遺留的 Bug 及用戶反饋等信息。

也就是說，「需求池」和「功能列表」是包含關(guān)系，或者你也可以將需求池理解為「動態(tài)變化的功能列表」，這個池子里可以增加新的功能列表，也可以剔除一些功能列表。

一般情況下，我們所說的「功能列表」是第一版時提出的需求的集合，到后期產(chǎn)品迭代、需求發(fā)生改變之后，功能列表也就變成了現(xiàn)在的「需求池」。

一般我會和研發(fā)團隊使用同樣的軟件來管理需求池。比如：我們現(xiàn)在在用 Jira，我就會用 Jira 充當(dāng)需求池管理軟件，把收到的需求記錄在內(nèi)，并標(biāo)注優(yōu)先級、編寫需求描述，以方便團隊溝通。和研發(fā)團隊使用同樣的軟件的好處是不用擔(dān)心信息不同步，因為記錄在別的地方研發(fā)不一定會關(guān)注，同時產(chǎn)品經(jīng)理也不會忘記更新。

4. 需求不需要評審嗎？

看公司要求以及產(chǎn)品經(jīng)理所負(fù)責(zé)的產(chǎn)品的難易程度，比如我在工作中遇到的 2B 產(chǎn)品，都是拿著 UI 圖去和用戶評審，而不是需求評審。當(dāng)然，在 UI 評審之前，產(chǎn)品經(jīng)理已經(jīng)就「產(chǎn)品規(guī)劃」和用戶達(dá)成一致。

如果需求需要評審，設(shè)計確認(rèn)的步驟就會調(diào)整為如下圖所示。也就是說，UI 溝通會在需求評審之后進(jìn)行。

下一篇我們將重點關(guān)注「研發(fā)測試」過程，敬請期待。

好的，今天這篇文章到這里就結(jié)束了，我們的《一個項目帶你走進(jìn)產(chǎn)品經(jīng)理的世界》系列文章完成進(jìn)度如下：黃色為當(dāng)前進(jìn)度～

相關(guān)閱讀

一個項目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（1）：從收到一個需求談起

一個項目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（2）：需求分析

一個項目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（3）：從用戶需求到產(chǎn)品功能

一個項目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（4）：產(chǎn)品規(guī)劃

一個項目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（5）第一個版本：MVP ？MDP ？

#專欄作家#

佐珥，微信公眾號：產(chǎn)品碎月（ID：pm_lab），人人都是產(chǎn)品經(jīng)理專欄作家，專注互聯(lián)網(wǎng)產(chǎn)品，樂于通過幽默詼諧、圖文并茂、結(jié)合實際的文字分享自己的產(chǎn)品經(jīng)驗，期望同大家一起快樂成長

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

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