拿到PRD的瞬間，你在想什么？

設(shè)計(jì)一個(gè)產(chǎn)品的前提是要先了解這個(gè)產(chǎn)品想要解決的是用戶什么痛點(diǎn)，核心功能是什么，價(jià)值點(diǎn)在哪里等等。

整體需求概覽，產(chǎn)品畫布

先整體瀏覽下需求，對(duì)需求有個(gè)整體的認(rèn)知，知道大概的框架，功能點(diǎn)是什么

思維導(dǎo)圖，梳理需求

用白紙或XMIND將功能點(diǎn)梳理出來(lái)，最好是按照用一級(jí)菜單/二級(jí)菜單/三級(jí)菜單的模式，把整體的流程，頁(yè)面的邏輯都整理出來(lái)

這是一個(gè)消化過(guò)程，從PRD一堆文字，消化成，自己可以理解圖畫

這一步當(dāng)中，要把邏輯理順，不懂的就問(wèn)，千萬(wàn)不要用猜的，猜一猜，無(wú)限可能啊。一不小心，就給自己挖坑了。

如果產(chǎn)品是涉及到流程的，那就要把整個(gè)流程畫出來(lái)。比如要設(shè)計(jì)審批系統(tǒng)的中后臺(tái)。

如果PM已經(jīng)事先畫好流程圖，可以自己先過(guò)一遍，然后用自己的理解再畫一遍，然后對(duì)照看理解上有沒(méi)有偏差，這樣可以對(duì)整個(gè)流程流轉(zhuǎn)有更深的理解

草圖先行，原型跟上

前面兩步完成后，可以說(shuō)對(duì)產(chǎn)品的理解已經(jīng)沒(méi)有問(wèn)題了。現(xiàn)在要把頁(yè)面串起來(lái)，所以我建議先畫草稿，不用很細(xì)致，要大致規(guī)劃板塊

注意一點(diǎn)，不需要所有頁(yè)面，都需要畫草圖，這樣時(shí)間上太長(zhǎng)，把主要頁(yè)面和流程的草圖畫出來(lái)，把前兩步的理解用頁(yè)面表現(xiàn)出來(lái)，驗(yàn)證流程上是不是有漏洞。很多時(shí)候可能整體流程看起來(lái)是閉環(huán)的，等到畫頁(yè)面的時(shí)候，會(huì)發(fā)現(xiàn)有漏洞的地方

關(guān)于原型的問(wèn)題，如果是比較大的項(xiàng)目，建議還是先畫原型，因?yàn)榍捌谠徒换ド闲薷牡拇螖?shù)會(huì)比較多，那么設(shè)計(jì)師可以專注在整體頁(yè)面流程上的把控，而不把時(shí)間放在顏色，icon，插畫等視覺(jué)上的修飾。一個(gè)大項(xiàng)目前期的討論，評(píng)審，修改個(gè)5-10次都挺正常的。

每次修改最好都更新下版本號(hào)，并在原型里面加個(gè)【更新記錄】的頁(yè)面，記錄這次更新哪些內(nèi)容，如果是大的更新，或者是功能的改變，最好寫上原因，方便后期可查，因?yàn)闀r(shí)間久了，往后翻，真的會(huì)忘記。比起相信自己的記憶，還是爛筆頭吧。我也碰到幾次這樣的坑，某次開會(huì)，去掉了某個(gè)功能，當(dāng)時(shí)覺(jué)得不需要。后期又有人提這個(gè)需求，追溯到底是誰(shuí)說(shuō)不要的，結(jié)果怎么也想不起來(lái)。所以要做到記錄可查。

如果產(chǎn)品前期有做競(jìng)品分析，建議把競(jìng)品分析的內(nèi)容也寫在原型里面。同時(shí)也把產(chǎn)品目標(biāo)，用戶痛點(diǎn)這些都可以寫上去，這樣讓整個(gè)原型，可以更加完整，也更有份量。后期如果遇到類似的產(chǎn)品要設(shè)計(jì)，就可以去回顧下之前做產(chǎn)品的記錄，考查的方向。

做原型時(shí)，可以對(duì)一些要點(diǎn)，進(jìn)行補(bǔ)充，比如以下幾點(diǎn)：

1. 新建頁(yè)面，新建完成后，是跳轉(zhuǎn)到哪個(gè)頁(yè)面，這個(gè)需要說(shuō)明，不然開發(fā)就只能用猜。

比如新建產(chǎn)品完成后，是到產(chǎn)品列表，還是到產(chǎn)品詳情頁(yè)，因?yàn)榍捌跊](méi)有說(shuō)明，開發(fā)就讓頁(yè)面跳轉(zhuǎn)到產(chǎn)品列表，但是事實(shí)上，是要跳到產(chǎn)品詳情。因?yàn)榈皆斍轫?yè)面，可以引導(dǎo)用戶進(jìn)行下一步操作。如果到列表頁(yè)面，其實(shí)操作就被中斷了，除非產(chǎn)品的需求是，不斷建產(chǎn)品，但這種情況比較少

2. 有涉及到狀態(tài)的列表

要在原型旁邊補(bǔ)充說(shuō)明并列出，所有狀態(tài)。如果狀態(tài)還會(huì)對(duì)應(yīng)不同的操作，則需要把對(duì)應(yīng)關(guān)系都列出來(lái)。同時(shí)界面中的列表，也需要把狀態(tài)和操作對(duì)應(yīng)，不要隨意填寫，以致于開發(fā)看漏或者看錯(cuò)了，要保持一致，減少錯(cuò)誤發(fā)生。

或許你會(huì)認(rèn)為開發(fā)在細(xì)分的時(shí)候，也會(huì)講清楚狀態(tài)的分類，各自的邏輯關(guān)系。但是，建議設(shè)計(jì)師多做一步，可以幫助設(shè)計(jì)師更了解產(chǎn)品，還有些特殊狀態(tài)。而且自己碰到比較多情況是，前端也不清楚邏輯，結(jié)果在狀態(tài)與操作的對(duì)應(yīng)關(guān)系上來(lái)來(lái)回回一直在修改。個(gè)人的習(xí)慣是，如果設(shè)計(jì)稿可以呈現(xiàn)的邏輯，那就認(rèn)真的畫出來(lái)，減少后期開發(fā)的錯(cuò)誤和來(lái)回溝通的時(shí)間。

3. 列表的排列順序

按什么順序排序，這也是個(gè)關(guān)鍵問(wèn)題，按創(chuàng)建時(shí)間、更新時(shí)間，產(chǎn)品序號(hào)，優(yōu)先級(jí)等等，不同的需求會(huì)不一樣，所以不要去假設(shè)開發(fā)都知道

4. 表單校驗(yàn)

前端校驗(yàn)，還是后臺(tái)校驗(yàn)？基本上現(xiàn)在都是前端校驗(yàn)，馬上給用戶反饋，而不是在用戶填完一堆的表單后，告訴用戶，哪里出錯(cuò)了。后臺(tái)校驗(yàn)屬于偏重的交互，容易給用戶產(chǎn)生心理負(fù)擔(dān)。

校驗(yàn)問(wèn)題，還會(huì)涉及到報(bào)錯(cuò)文案。這個(gè)建議做個(gè)文檔給開發(fā)，特別是剛合作的開發(fā)，也不了解對(duì)方的習(xí)慣，這樣減少后期更改文案的時(shí)間。也可以做個(gè)報(bào)錯(cuò)規(guī)范，這樣后期的報(bào)錯(cuò)就根據(jù)規(guī)范來(lái)就可以，不需要每次都來(lái)提醒。

5. 輸入框提示文案

之前有人提到這個(gè)提示文案是非必要的，因?yàn)榍懊嬉呀?jīng)有說(shuō)明，當(dāng)前輸入框是要填什么內(nèi)容

加入提示語(yǔ)后，會(huì)讓表單更豐富。而看右邊的表單，空得讓人有點(diǎn)慌...

特殊的字段，會(huì)需要特別的文案；比如版本號(hào)，業(yè)務(wù)方希望用戶可以遵循某種規(guī)則去新建，則可以提示：請(qǐng)輸入版本號(hào)，例：1.0.0；

視覺(jué)稿

原型評(píng)審沒(méi)有問(wèn)題后，就可以進(jìn)行視覺(jué)的設(shè)計(jì)了。視覺(jué)稿上面，也同樣需要一些交互的說(shuō)明，雖然前期原型上已經(jīng)有標(biāo)注。但是對(duì)于開發(fā)來(lái)說(shuō)，他要看著設(shè)計(jì)稿，又打開原型對(duì)著看，其實(shí)也是件挺討厭的事。而且有些交互，是需要界面。比如下拉菜單樣式、搜索框(涉及模糊查詢)、進(jìn)度條(失敗和完成)等等。

藍(lán)藍(lán)設(shè)計(jì)( www.0391cbd.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)。