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

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

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

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

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

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

這是一個消化過程，從PRD一堆文字，消化成，自己可以理解圖畫

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

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

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

草圖先行，原型跟上

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

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

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

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

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

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

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

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

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

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

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

3. 列表的排列順序

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

4. 表單校驗(yàn)

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

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

5. 輸入框提示文案

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

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

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

視覺稿

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

藍(lán)藍(lán)設(shè)計(jì)( sillybuy.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國內(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ù)。