中后台界面设计流程剖析

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

设计一个产品的前提是要先了解这个产品想要解决的是用户什么痛点，核心功能是什么，价值点在哪里等等。

整体需求概览，产品画布

先整体浏览下需求，对需求有个整体的认知，知道大概的框架、功能点是什么。

思维导图，梳理需求

用白纸或XMIND将功能点梳理出来，最好是按照用一级菜单/二级菜单/三级菜单的模式，把整体的流程，页面的逻辑都整理出来。

这是一个消化过程，从PRD一堆文字，消化成，自己可以理解图画。

这一步当中要把逻辑理顺，不懂的就问，千万不要用猜的，猜一猜，无限可能啊。一不小心，就给自己挖坑了。

如果产品是涉及到流程的，那就要把整个流程画出来。比如要设计审批系统的中后台。

如果PM已经事先画好流程图，可以自己先过一遍，然后用自己的理解再画一遍，然后对照看理解上有没有偏差，这样可以对整个流程流转有更深的理解。

草图先行，原型跟上

前面两步完成后，可以说对产品的理解已经没有问题了。现在要把页面串起来，所以我建议先画草稿，不用很细致，要大致规划板块。

注意一点，不是所有页面都需要画草图，这样时间上太长，把主要页面和流程的草图画出来，把前两步的理解用页面表现出来，验证流程上是不是有漏洞。很多时候可能整体流程看起来是闭环的，等到画页面的时候，会发现有漏洞的地方。

关于原型的问题，如果是比较大的项目，建议还是先画原型，因为前期原型交互上修改的次数会比较多，那么设计师可以专注在整体页面流程上的把控，而不把时间放在颜色、icon、插画等视觉上的修饰。一个大项目前期的讨论、评审，修改个5-10次都挺正常的。

每次修改最好都更新下版本号，并在原型里面加个【更新记录】的页面，记录这次更新哪些内容。如果是大的更新，或者是功能的改变，最好写上原因，方便后期可查。因为时间久了，往后翻真的会忘记。比起相信

自己的记忆，还是烂笔头吧。我也碰到几次这样的坑，某次开会去掉了某个功能，当时觉得不需要。后期又有人提这个需求，追溯到底是谁说不要的，结果怎么也想不起来。所以要做到记录可查。

如果产品前期有做竞品分析，建议把竞品分析的内容也写在原型里面。同时也把产品目标，用户痛点这些都可以写上去，这样让整个原型可以更加完整，也更有份量。后期如果遇到类似的产品要设计，就可以去回顾下之前做产品的记录，考查的方向。

做原型时，可以对一些要点，进行补充，比如以下几点：

比如新建产品完成后，是到产品列表，还是到产品详情页，因为前期没有说明，开发就让页面跳转到产品列表，但是事实上，是要跳到产品详情。因为到详情页面，可以引导用户进行下一步操作。如果到列表页面，其实操作就被中断了，除非产品的需求是，不断建产品，但这种情况比较少。

要在原型旁边补充说明并列出，所有状态。如果状态还会对应不同的操作，则需要把对应关系都列出来。同时界面中的列表，也需要把状态和

操作对应，不要随意填写，以致于开发看漏或者看错了，要保持一致，减少错误发生。

按什么顺序排序，这也是个关键问题，按创建时间、更新时间，产品序号，优先级等等，不同的需求会不一样，所以不要去假设开发都知道。

前端校验，还是后台校验？基本上现在都是前端校验，马上给用户反馈，而不是在用户填完一堆的表单后，告诉用户哪里出错了。后台校验属于偏重的交互，容易给用户产生心理负担。

校验问题，还会涉及到报错文案。这个建议做个文档给开发，特别是刚合作的开发，也不了解对方的习惯，这样减少后期更改文案的时间。也可以做个报错规范，这样后期的报错就根据规范来就可以，不需要每次都来提醒。

之前有人提到这个提示文案是非必要的，因为前面已经有说明，当前输入框是要填什么内容。

加入提示语后，会让表单更丰富。而看右边的表单，空得让人有点慌……

特殊的字段，会需要特别的文案；比如版本号，业务方希望用户可以遵循某种规则去新建，则可以提示：请输入版本号，例：1.0.0。