本文為我們介紹了中后臺(tái)界面設(shè)計(jì)的基本流程，以及其中的注意事項(xiàng)。

拿到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è)消化過程，從PRD一堆文字，消化成，自己可以理解圖畫。

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

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

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

草圖先行，原型跟上

前面兩步完成后，可以說(shuō)對(duì)產(chǎn)品的理解已經(jīng)沒有問題了?，F(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)于原型的問題，如果是比較大的項(xiàng)目，建議還是先畫原型，因?yàn)榍捌谠徒换ド闲薷牡拇螖?shù)會(huì)比較多，那么設(shè)計(jì)師可以專注在整體頁(yè)面流程上的把控，而不把時(shí)間放在顏色、icon、插畫等視覺上的修飾。一個(gè)大項(xiàng)目前期的討論、評(píng)審，修改個(gè)5-10次都挺正常的。

每次修改最好都更新下版本號(hào)，并在原型里面加個(gè)【更新記錄】的頁(yè)面，記錄這次更新哪些內(nèi)容。如果是大的更新，或者是功能的改變，最好寫上原因，方便后期可查。因?yàn)闀r(shí)間久了，往后翻真的會(huì)忘記。比起相信自己的記憶，還是爛筆頭吧。我也碰到幾次這樣的坑，某次開會(huì)去掉了某個(gè)功能，當(dāng)時(shí)覺得不需要。后期又有人提這個(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è)面后，說(shuō)明是跳轉(zhuǎn)到哪個(gè)頁(yè)面，不然開發(fā)就只能靠猜

比如新建產(chǎn)品完成后，是到產(chǎn)品列表，還是到產(chǎn)品詳情頁(yè)，因?yàn)榍捌跊]有說(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ā)生。

3. 列表的排列順序

按什么順序排序，這也是個(gè)關(guā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)問題，還會(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。

視覺稿

原型評(píng)審沒有問題后，就可以進(jìn)行視覺的設(shè)計(jì)了。

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

作者：柒悅Jocelyn

來(lái)源：https://www.zcool.com.cn/article/ZOTk3MTMy.html

本文由 @柒悅Jocelyn 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

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