前言：从【业务系统】看后台产品的设计逻辑思维
入职至今已有两个年头，作为研发的身份一直在和业务系统打交道。一直想尝试自己总结一下对后台产品设计的一些知识。
首先，后台产品和前端产品存在很大的差异性。尽管前后台产品的逻辑是相通的。比如。后台有角色，前台也有角色。但你的关注重点可能会存在差别。做后台，你可能会更关注用户、组织，角色，权限的设计模型以及每一个状态下不同角色的多个操作（功能实现）；但做前台，你的重心却可能会放在哪类用户在哪种场景下没有点这个按钮所以是不是文案要改要不要把按钮变大一点位置移动一下诸如此类（用户体验）。
后台产品：更加注重的是业务逻辑的清晰和功能的实现
前端产品：对视觉设计和交互设计有更高的要求
一句话：后台产品粗糙大汉，前台产品文艺青年
下面开始，介绍下自己总结的后台产品的设计方法与思路（其中请教了几位前辈，在此感谢）。
后台产品设计逻辑思维
从我之前的分析里可以得出结论，对于后台产品而言，最重要的就是第3步，业务逻辑梳理。以及第4步，将业务逻辑梳理成为产品的逻辑。下面以【业务系统】为例子逐一分析。
1.需求讨论与收集
输出产物：用纸笔画出草图，或者记录
在实际工作的场景当中，需求收集和讨论是工作开始的第一步，所谓“万事开头难”，这也是最繁琐最耗时的一个步骤。后台系统主要是功能类的，用户基本是本单位员工，应用场景也略显单一（PC端为主，移动端目前也在普及），但是需求属性却是“真实+高频+刚需”。
后台用户对于交互体验等容忍度相对较高，也能接受一定的学习时间成本（单位会针对某些功能组织培训）。但对数据的准确性，处理的时效性等要求较高。说白了“首先你得能用，好不好用放在后面再商量”
后台产品需求往往是业务方直接提出的，最常见的模式就是和业务方开个会讨论。这个阶段的大原则应该“认真听，但不照着做”。可以采取“定量+定性”的方式，将用户的需求先收集起来。会议形式的需求讨论往往发言比较凌乱，需要认真做好发言笔记，会后整理成需求列表。我本人参与重要会议时，会有用手机录音的习惯，便于会后复盘。此阶段的输出产物，用纸笔画出草图即可，不必非用电脑
2.需求分析与要素梳理
输出产品：脑图是个不错的选择
需求分析是将从用户手里搜集的第一手需求，经过加工分析整理，剥离事物的外表去看透用户内心的本相，即：这个需求（功能）究竟要满足他什么？再深层次就是他为什么要满足这个？
做c端产品，需求分析是重头戏。常用的Y字形理论，就是需求分析的经典模型。但对于后台产品，这个需求分析相对清晰明确好做一些，因为后台产品的需求基本都是工具性的，满足于某个工作流，故此目的性很明确。也就是说，后台产品，需求的分析工作其实业务方帮助我们做了很大一部分，而c端产品更多是有产品经理自己去分析需求。
这个阶段的输出产物，以脑图为最佳。当然，脑图作为框架类的输出产物，都很合适。下一次昨夜里，我就尝试用脑图去梳理目前业务系统的主要业务流架构。
3.业务逻辑梳理
输出产物：流程图、泳道图
需求调研与分析完成后，就是自己对内容的消化和吸收。首先要做的事情是自己先清晰地理解一个产品。只有自己理解了，才能更好地推进产品进行开发。先梳理清楚线下的业务流程。将线下的业务流程梳理清楚以后，然后才是对产品的思考。这个阶段最好的输出产物就是各种流程图和泳道图了。在这里，我拿业务系统中的【产品开班】来举例（并没有完全依照现有的产品开班逻辑）
流程图
业务流程图描述的是完整的业务流程，以业务处理过程为中心，一般没有数据的概念。流程图以动作来推动业务前进。下面是产品开班的例子
产品开班流程图
流程图更加关注的是业务实现具体需要进行哪些操作。每一个动作的构成形式基本都是 “动词 + 名词” 或者 “动词” 的形，这样才能更加明晰以动作为驱动的流程图。
泳道图
泳道图，又称为跨职能流程图。也是我所说的流程图的第二步。作为流程图的进阶，泳道图加入了泳道表示不同角色（或岗位、部门等）。让人在了解业务流程时，也清楚由谁执行该动作。同样以产品开班为例子。
泳道图
可以看到，每一个动作都放在相应的泳道下，对应了执行此动作的人。这样对于业务流程中不同角色的职责也会更为明确的认识。
也许有人会质疑，觉得花这么多时间画图会浪费很多时间。我觉得仁者见仁智者见智了。对于我个人而言，每天捣弄这些图，会很快加深我对产品的理解。特别是在业务比较复杂，而且之前没有接触过相关方面知识的时候，仅靠大脑很难有清楚的思维，但是图形化后却能很好地理解。在业务整理上多花点时间整理，我觉得是很有必要的。
4.产品逻辑梳理
输出产物：功能点、角色、页面、页面内架构
我们继续用产品开班当例子。在业务逻辑梳理清楚之后，再进行产品逻辑的梳理，这个就感觉清晰和顺畅多了。将业务逻辑转化为产品逻辑是产品人员的基本功（也是本人需要强化的），主要的步骤总结如下
a.功能点
先根据业务逻辑，梳理单一功能点
功能点
b.功能点+角色
有了功能点之后，尝试加入角色的情况（前提是此功能是多角色完成），角色梳理清晰十分有助于权限分离的操作
c.页面+功能
可以开始考虑设计页面了，一共几个页面，分别对应实现哪些功能点（并未完全按照当前业务系统现状画图）
d.页面内架构
到这一步，就可以着手搭建页面内的架构了。我用查询作为例子，解释一下。
先搭页面，再确定页面内的功能，最后细化页面内的信息。在原型出来以前，可以拿产品架构图先和别人进行一下交流。产品架构图相较于原型图，与数据库的设计思想比较一致（研发经验得出的结论）。优秀的后台产品，产品架构图和数据库结构图，一定会比较类似，因为二者都是用一致的思维得出的，这是我这两年的研发经验告诉我的真理。另外，产品架构图修改较快捷，返工成本相对较小。产品架构图更多是需要个人的整理。
5.产品原型
输出产物：原型图（axure，墨刀等）
产品梳理好以后，就要开始搭建原型了。很多外行（包括两年前的我）对产品经理的认识很简单，认为就是画原型图，出PRD的人（也就是只做这一步的工作）。但其实，原型图的输出，只是产品设计的最后一个步骤。在前几步都操作无误的前提下，最后一步也会水到渠成的。
a.先确定通用模块：页头、页尾、一级导航、二级导航。
根据产品的不同，选择合适的布局。目前业务系统用的是右侧式导航栏，后面会分析思考一些更为合理的布局。
b.将产品架构图的内容填充到页面内，并加入文字说明操作
c.细节
细节就多了，这个也是对我而言比较难的地方，因为细节这个最吃经验。需要不断打磨才能积累。细节决定成败
我能想到的细节处理：
文案
导航：一（二、三）级导航；菜单...
常用模块交互方式：按钮，弹窗：对话框...
色彩：页面基调；字体颜色...
反馈：提示；警告；正确；错误...
d.尽量要单独出一份详细的PRD(也视具体情况而定)。
产品设计的阶段，就暂时结束了。然而，路，才刚开始...
总结与排期
总结一套设计逻辑思维，其中也借鉴了一些前辈师兄们的方法，但这绝不是产品的结束。而是刚刚开始。业务系统，作为一套工作流占比极重、业务复杂程度极高、耦合性极强的后台系统，而且已经使用了其重构之路任重道远。我将【业务系统】的主线业务功能，拆分成了七大模块，作为后面的子任务去逐一分析（下一期我会详细用脑图分析，还涉及一些小的使用频度较低业务功能）。
业务系统
下面是我对这个任务的各个子任务排期
因为本人只能以业余时间进行这项工作，故此无法在排期一览加上具体完成日期。但我一定会充分利用课余时间，以及本人两年来对业务系统的理解，逐一模块化地去分析、梳理、重构业务系统各个模块。希望各位老师各位同仁看了之后提出宝贵意见。
最后，用万圣节单位做的南瓜灯作为结尾，梦想的光亮哪怕再微弱，只要努力也就会有希望
路漫漫其修远兮，吾将上下而求索，加油
每天进步一小点，加油
网友评论