當我們在進行互聯(lián)網(wǎng)或系統(tǒng)產(chǎn)品設(shè)計時，大多數(shù)產(chǎn)品經(jīng)理都明白產(chǎn)品創(chuàng)意和交互設(shè)計的重要性。但是，如何將一個優(yōu)秀的產(chǎn)品創(chuàng)意變?yōu)檎嬲漠a(chǎn)品，以何種方式體現(xiàn)交互設(shè)計之美，我們必須以嚴謹有序的方式進行產(chǎn)品設(shè)計。

在To B產(chǎn)品，特別是后臺產(chǎn)品的設(shè)計工作中，即使這些產(chǎn)品通常邏輯比較復雜，但仍能遇到產(chǎn)品經(jīng)理接到一個需求任務(wù)，上來就開始畫原型，做交互，樂此不疲。事實上，這種工作方法常常是不可取的。理清該需求的本質(zhì)，并在產(chǎn)品設(shè)計中以合理和完善的方式去體現(xiàn)，才是第一要務(wù)。從此開始，我們應(yīng)該拋棄一切不著邊際的幻想，從最冷靜和理性的角度來著手產(chǎn)品的設(shè)計工作。

第一步：剖析需求，提出問題

在做需求分析的時候，產(chǎn)品經(jīng)理的一個大忌就是，拿來就做，不問問題。不問問題有兩種可能性：第一種可能性是需求已經(jīng)提的很完善了，沒有什么問題可以提；第二種可能性是需求分析不到位。

舉一個例子，曾經(jīng)有一個業(yè)務(wù)部門需求是，將原本T+1的金融產(chǎn)品贖回到賬體驗改為T+0實時到賬。但是該需求并沒有提出具體的實現(xiàn)方式，只提出他們可以先墊一部分錢給投資者。我們在分析這個需求的時候，首先要明白，這個需求的第一要務(wù)是，無論如何，投資者應(yīng)該在贖回的當前就拿到贖回款。

• 衍生出的第一波待解決問題較為宏觀：
• 一旦T+1變?yōu)門+0，原來的T+1產(chǎn)品是否還存在？
• 是重新創(chuàng)建一個T+0的產(chǎn)品還是把原來T+1的產(chǎn)品改為T+0？
• 這個T+0產(chǎn)品將會是系統(tǒng)中唯一的T+0產(chǎn)品還是未來多個同類型產(chǎn)品中的第一個？

這一波問題找到答案后，我們將會對T+0贖回這個業(yè)務(wù)的邊界有大致的了解。如果是孤例，那就是一個功能模塊級別的任務(wù)。如果將來會大規(guī)模開展，那我們應(yīng)該從現(xiàn)在就開始考慮功能的擴展性（然而市場總是變化快，開始說只是先做做，后來要大批量上的情況也很多，這主要看產(chǎn)品經(jīng)理自己的判斷是否準確了）。

第一波問題找到答案后，將會進入第二波問題的提出：

• 這個業(yè)務(wù)將由哪幾個部門協(xié)同合作？
• 誰領(lǐng)導，誰協(xié)同？
• 資金從哪個賬戶出款，何時出款？
• 是否有回款，什么條件觸發(fā)回款？
• 這些流程的各個節(jié)點，誰推進，誰審核，誰被通知？

這些問題答案就是是能夠完成產(chǎn)品設(shè)計的最關(guān)鍵素材，這個維度的問題應(yīng)該問到不能再問的原子級別。問題是否問完的檢驗標準就是，產(chǎn)品經(jīng)理是否自己能夠流暢的口述整個流程的信息流和資金流的流轉(zhuǎn)過程，有一處不明白，那一處就會成為實現(xiàn)時的坑。

第三波問題也非常重要，這個層次的問題主要在系統(tǒng)層面。例如：

• 由哪幾個系統(tǒng)協(xié)同完成這個需求？
• 系統(tǒng)和系統(tǒng)之間是如何交互的？
• 數(shù)據(jù)一致性如何保證？
• 一旦一個系統(tǒng)掛了，另一個系統(tǒng)如何回滾或容錯？

在這一波問題中，可能需要技術(shù)同事作為顧問，但問答并不需要太細，因為當前只是處在需求分析，并未上手設(shè)計。

三波問題，百分之七八十有了答案之后，我們可以寫出一個較粗的需求分析報告，給業(yè)務(wù)部門進行確認。哦，我知道很多產(chǎn)品經(jīng)理說我哪有時間寫這玩意兒??？沒錯，你可以不寫，但不能不想。

第二步：用例先行，框定邊界

如果有做后臺的產(chǎn)品經(jīng)理不知道用例，那是一個很大的遺憾。因為沒有用例，就沒有整個系統(tǒng)。簡而言之，只要能完成預(yù)先設(shè)定的用例，無論系統(tǒng)實現(xiàn)得多么差，都起碼是一個合格的系統(tǒng)。

如何寫用例在這里不多講，個人認為最好的參考資料是《大象-thinking in UML》。寫好用例的意義在于，劃分清楚，在當下需要實現(xiàn)的版本中，哪些需求是需要實現(xiàn)的，哪些不需要。這點很重要，如果不劃分清楚，很有可能出現(xiàn)在需求文檔的撰寫中，不斷加新需求，使版本計劃延期，版本功能變得不可控。

第三步：按角色分模塊，按功能分模板，按模板做頁面

后臺產(chǎn)品的原型設(shè)計，在很多人眼中，似乎不那么注重交互，就是一堆“某某管理”的操作頁面。我們見到的大多數(shù)國產(chǎn)后臺產(chǎn)品，例如各種OA系統(tǒng)，流程管理后臺，ERP后臺，數(shù)據(jù)管理后臺等，大多數(shù)做的潦草而匪夷所思。

說到這里，不禁想岔開一下：

• 為什么我國美食世界聞名，高端廚具還是用德國的？
• 為什么我國是中醫(yī)文化的發(fā)祥地，現(xiàn)在高端漢方化妝品還是唯韓國馬首是瞻？

還有很多的為什么，如果說國防實力或航天科技方面需要國家財力的支持，那么在民用品的創(chuàng)新設(shè)計方面，我們也不優(yōu)秀，這似乎應(yīng)該是一個社會問題。

那么，我們應(yīng)該如何來做頁面級的功能設(shè)計呢？只有一條宗旨，降低學習成本，提高使用效率。

假設(shè)該產(chǎn)品已經(jīng)沿用多年，除非有顯著的簡化和易用性新設(shè)計，一般不應(yīng)改變原有交互邏輯，不管你覺得該邏輯有多么白癡。原因很簡單，這個產(chǎn)品的使用者很有可能是一些初中都沒畢業(yè)的客服中心人員，很有可能是一些很少跟電腦打交道的人，他們并不是我們這樣天天研究各種互聯(lián)網(wǎng)產(chǎn)品的人，當我們做好原型之后，應(yīng)該自己模擬用戶去試試，到底能不能完成既定工作，而不是沉浸在自己應(yīng)用了各種所謂高端的交互設(shè)計概念的飄飄然中不可自拔。

接下來，繼續(xù)進入正題。

在模塊設(shè)計時，為什么會有“這個管理”、“那個管理”模塊，到底是誰在管理，管理的目的是什么？這個模塊的工作之前（前置流程）是什么？做完這個模塊的工作之后（后置流程）是什么？這些都需要考慮清楚。

個人的建議是以一個或一類角色的工作作為一個大型的模塊，以該類角色中不同的分工作為子模塊來處理。這樣一來，這類角色可以集中處理工作，而不需要在整個系統(tǒng)的不同模塊之間跳來跳去的這里點點，那里點點，一不小心就忘了操作。

這里也舉個簡單的例子。

見過有些產(chǎn)品設(shè)計，將某些業(yè)務(wù)的申請和審核做在一張頁面里，我個人是很反對這種設(shè)計的。這種設(shè)計的第一個壞處是，這倒逼了技術(shù)實現(xiàn)必需將權(quán)限設(shè)定到按鈕級，增加了工作量；第二個壞處是，對于操作員和審核員，無法區(qū)別展示不同內(nèi)容，大家看到的信息必須是完全一樣的，畢竟你們共享了一張頁面，因此擴展性也是差的。

再說說按功能分模板。

每張頁面都有它自己的功能，沒有一張頁面是什么功能也沒有的。一般頁面的功能可以粗略的分為：綜合展示頁面（dashboard類頁面）、表單工單類頁面-即填入一些數(shù)據(jù)并保存的頁面、列表類入口頁面-即展示數(shù)據(jù)表格并帶有一些索引鏈接的頁面（例如產(chǎn)品列表，投資者列表等）、數(shù)據(jù)查詢類頁面-即帶有搜索區(qū)和結(jié)果區(qū)的頁面、詳情主頁類頁面-即展示某個對象全部數(shù)據(jù)的頁面（例如個人資料、賬戶詳情等）。除此之外，彈窗也有一些模板，在這里不一一列舉。

如果我們能夠預(yù)設(shè)一些模板，并在頁面設(shè)計中盡量復用這些模板，不但可以節(jié)省我們的工作時間，也可以讓用戶的學習成本進一步降低，因為對大多數(shù)人來說，觸類旁通比完全從頭開始學習容易得多。

當然，這是一個循序漸進的過程，我們自己應(yīng)該在一次次的產(chǎn)品迭代中，也對我們的頁面模板庫進行迭代，不斷重新整合、分拆，以適應(yīng)新的業(yè)務(wù)和進一步優(yōu)化原有業(yè)務(wù)。

當我們完成了以上三步，可以說大部分的產(chǎn)品設(shè)計工作已經(jīng)完成，但是這僅僅是設(shè)計階段，這些工作還不能達到可以提交開發(fā)的階段。

下一篇開始寫產(chǎn)品自測。

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