车贷管理系统二期的重构与设计中，着实体会到了产品经理的不容易。二期的车贷管理系统业务流程发生变更，相当于系统重构，但是和从0到1的项目相比优势在于，可以总结一期项目的不足，在二期中进行优化和改进，所以此次车贷项目除了系统业务重构，重新绘制交互设计流程，还总结了一期系统交互体验上的问题和不足。现在项目二期开发接近尾声，总结梳理发现，对我来说此次任务最大的一个挑战并不是专业技能上的，而是项目协同和管理上的，业务方和我们研发中心不在一个城市，给沟通和调研带来了极大的不便，尽管这样，在我几次都临近崩溃的边缘还是成功拉回了自己，推动项目顺利进行。

一.项目中总结与反思

车贷项目最终顺利进行，首先应该感谢团队的大力配合。从头至尾贯穿其中的我，深刻认识到了需求文档的重要性，为之前做过的这么多的无头项目（一句话需求项目，一般没有产品经理介入），找到了答案。需求文档的输出是一个很重要的节点，承上启下，输出物的质量高低代表了需求分析的精细程度。交互设计师作为第二产品经理，也需要强大的业务逻辑能力和需求分析梳理的能力，接到需求之后要先进行需求分析，理清业务流程，确定需求优先级，然后再开始系统框架的交互设计；关键时刻还应撰写明确清晰的需求文档，以便指导和沟通开发、设计、测试人员；项目进行中，也要及时跟进变更需求并评审沟通，否则后面节点上的人员容易做无用功。

二.项目设计中需求文档的撰写规范

接触过需求需求种类，需求文档、需求描述、需求字段、需求列表、一句话描述，在上篇文章中《如何搭建“一句话需求”管理系统》中提到过。对于需求描述或者一句话需求这种，需要在设计之前进行需求分析，明确业务流程图，然后再进行交互逻辑设计。而对于需求文档，需求列表或者紧跟其后的业务流程图，功能架构图这种则是需求必不可少的部分，只是展示形式不同。不过无论哪种形式，都不要忘记编写需求文档的初衷。以下针对工作中遇到的需求规范做的梳理和总结，如果不合理的地方，请各位小伙伴指出，一起交流学习。

1.需求文档的撰写规范（.doc文件已上传附件，可自行下载，仅供参考）

不同的产品经理不同的风格，工作配合中需求文档是最常用的一种，具体格式规范如下：

a.题目和目录：

b.修订记录和版本控制：

c.文档目的

d.功能结构图/业务流程图

e.核心功能需求

f.其他非功能需求

2.需求列表（.excel文件已上传附件，可自行下载，仅供参考）

在配合的产品经理中，只有一个善于质量控制的产品经理喜欢用这种方式，个人也很喜欢这种方式，简单直接清晰明了，并且也方便统计数目，便于测试人员逐条编写测试案例。具体格式规范如下：

3.业务流程图

流程图中要包含角色（部门），流程的发起、流转、反馈、结束。业务流程图是项目设计中很重要的一环，业务流程图是结构层和范围层的展示，业务流程图要包含从业务流程发起到结束的所有环节，必须是一个完整的闭环才行。业务流程图可以指导交互设计师和研发人员更好的理解业务功能，梳理业务逻辑。交互设计师则要根据业务流程图拆分出主功能框架和子任务流程，继而进行后续的功能界面设计。日常工作中绘制流程图一般用Visio和OmniGraffle，有时候还会用到axure，当然还有人使用.doc&ppt也未尝不可（用这俩的都是高手），并且设计软件能满足设计需求就可以，或者工作中的配合交接方便，剩下的就看个人习惯和偏好了。

4.功能架构图

曾和研发同事聊起时，在项目配合过程中他们更倾向哪一种需求文档，一位研发经理脱口而出“脑图”。开发人员的逻辑性思维比较强，所以对他们而言，需求越精确越简单粗暴越好，这样他们的思路逻辑更清晰，也能有效的减少沟通时间。
功能架构图就是我们所说的脑图，这种一般出现在项目的前期，一个清晰的功能架构图可以帮你更好的梳理产品功能逻辑，用来判断产品功能模块是否完整。
一般编写功能架构时有两个角度：功能和权限。

C端产品一般要从功能的角度编写，而对于B端产品则需要结合功能和权限来编写。

三.如何拆解业务流程到具体的功能任务

“业务流程图”中提到“交互设计师则要根据业务流程图拆分出主功能框架和子任务流程，继而进行后续的功能界面设计”，下面我就结合车贷管理系统，具体说说如何拆分业务流程图。
把业务流程图拆解为角色用户、角色功能、角色用户目标，然后根据核心功能拆解出其他子功能，界面设计方案也就相应出来了。

四.系统重构设计目标

旧版交互问题总结：

1.流程繁琐，页面信息复杂，部分按钮操作不明确；

2.订单详情页面内容繁多，页面层级不清晰，重点不清晰，用户容易迷失自己；

3.表单设计单调枯燥（是否能在满足易用的情况下，让体验更友好）。

系统重构设计目标：

1.流程梳理，操作流程简约流畅;

2.界面内容归纳整理，优化信息展示层级;

3.统一设计规范。

五.界面设计方案和交互设计说明

交互设计说明：

六、总结
文档也好，功能框架也好，业务流程图都只是一种表现手法，目的是让团队中的开发人员和设计人员能够更好的理解需求和流程，从而更好地服务于生产，无论手段工具多么复杂，最重要的还是逻辑清晰思路明确。所以作为一个交互设计师，除了保证功能逻辑的完整性，操作流程的易用性，还要兼顾到团队的其他成员能更好的理解业务理解需求。之前发了一篇“如何快速搭建一句话需求管理系统”，有一个朋友说“看数据的，直接上色就能用了”我还是想说不同的系统、不同的终端、不同的平台会有不同的受众，具体业务系统的视觉要设计到什么程度，则要根据受众群体的大小和系统具体的要求来判断，而不是固有思维“看数据的，直接上色就能用了。

忠告：总结要趁早
切记文章一定要存好草稿之后再来发布，免得重演我这二次编写的悲剧。