以用户体验五要素复盘产品设计

本次复盘从产品规划与设计、沟通协调两个方面来思考，而产品规划与设计又根据用户体验五要素的产品设计流程来展开。

---

产品规划与设计方面

1、战略层

此产品最初的战略方向很明确，就是为了让领导能够方便的看到一线员工的工作量和质的情况。因此从战略层面来说，本次产品的设计不存在问题。

2、范围层

在考虑范围层的时候出现了一些问题：因为需求只能通过远程电话沟通、时间过于仓促（从想法到交付只有两周时间）、本身对领导层（最关键的用户）的具体需求和员工工作习惯不了解等各种原因，导致部分产品范围考虑有欠缺，比如某些说明性的字段的遗漏。要想避免，必须要相关人员全身心投入，而身为产品经理也需要更多时间和机会去实际了解各用户角色在本系统涉及的工作流程中的习惯和需求。

做的好的地方：做了用户角色和任务分析

1）从接单后，就一直在搞清楚组织架构，用xmind抽象出了组织架构，从而确定本系统的目标用户有哪些，分为哪些人物角色。

2）调查了解各个人物角色之间（使用系统的）工作流程，做好了任务分析；并且在processon上用泳道图绘制了整个系统的主要核心业务流程图，也针对不同角色用Visio分别绘制了他们的核心业务流程图。

经验教训：应该尽可能早的把尽可能准确的用户组织架构和人员名单给到研发，经过抽象处理的未必准确

早期我向领导（需求方）再三确认过抽象出来的组织架构没有问题，感觉肯定不会出错，就直接将抽象后的组织架构给了研发。但是在梳理最终的具体名单和组织架构时，发现虽然与抽象出来的架构虽然大体一致，缺还是略有不同——存在一人身兼多职的情况。这在前期抽象过程中并没有想到，也没有提醒研发可能存在这种情况。导致在研发的最后关头出现了原本的数据结构设计无法满足需求的问题，好在最后只是做了略微调整就完善了。如果不是一人身兼多职而是一人身兼多种角色的情况，那这次就会造成数据结构的完全不适应，从而导致研发大面积返工，上线时间大幅度延迟。因此，以后在做此类产品设计时，应该在第一时间将准备的用户组织架构和人员名单梳理出来并给到研发，因为这会影响到他们的数据结构设计，避免不必要的研发资源浪费和产品交付推迟。

ps：因为本系统相对较为简单、且没有时间和机会做详尽的用户调研和使用场景分析，因此这次产品设计过程中，用户调研就是依赖直接与领导沟通完成、场景分析基本就是在自己脑子里面过了几遍就完成了，并没有形成书面交付物。

3、结构层

1）根据角色需求的差异对系统进行拆分设计，将复杂度降到最低：因为不同角色的功能需求完全不同，所以此系统的前端系统展示是根据不同角色的功能需求分别设计。

2）信息列表按多种状态分类，因此采用了顶部tab导航的方式对信息列表进行归类整合。

经验教训：微信的返回按钮太恶心，与可定制的APP不同，一定要给用户提供一个快捷切换的导航按钮。

本系统在微信公众号上运行，但微信的返回按钮太恶心，完全不可控。即使你只有两个主要功能模块入口，如果用户路径较深，采用微信的返回按钮返回，会使得用户一直深陷于返回状态而难以到达主入口页，因此产品一定要给用户提供一个快捷切换的导航按钮。本系统为了保持系统设计的一致性和前端代码的复用性，同样是采用了悬浮icon导航，直接跳转到主入口页，类似于下图。

4、框架层

1）核心模块和入口少，采用顶部tab导航+悬浮icon导航的组合方式：此系统的所有角色都只有1~2个核心功能模块，因此整个系统都是采用了顶部tab式导航+悬浮icon导航的组合方式，见下图。如果核心功能模块更多，或许会考虑采用顶部tab式导航+底部菜单栏导航的组合设计框架。

2）本系统信息相对单一，再加上是移动端，所以基本都是采用了最简单的从上到下的信息流的页面结构方式。

做的好的地方：1）所有的模块和框架设计样式都尽量保持一致：为了保持系统的整体性和一致性、同时也增加研发（前端）的代码可复用性，所有的模块和框架设计样式都尽量保持一致。如统一采用顶部tab导航和悬浮icon导航、相同样式的卡片式信息列表。

5、表现层

1）卡片式列表设计：大部分页面都是展示信息列表，而且文字描述内容较多，因此最终选用了常见的卡片式列表设计（上面有图）。

2）为了能够尽早交付、减少前端工作量，本系统尽可能的降低交互效果的要求。

3）采用了最近流行的平铺滑动式导航和信息列表样式，增强了系统的可扩展性，若日后添加更多的部门也不需要修改前端代码，见下图。

做的好的地方：1）设计规范化：在制作原型时，基本统一了不同页面各种情况下的字体大小、字体和背景颜色、间距、图标尺寸大小等，做到了相对较好的统一和规范化设计。2）提前跟UI交待了整体风格：在UI设计之前，就交待了本系统的使用对象年龄较大、所处环境较为传统，因此需要一个较为稳重的设计基调。

---

沟通协调方面

1）研发响应快速的团队，可以口述零散的需求变更和bug修复，反应慢则最好使用奇妙清单等团队协作工具进行书面通知和任务分配，明确责任人，并且能够及时更新和追踪任务完成状态

在产品开发过程中，出现了很多需要修改的细节（有的是需求变更，有的则是程序bug）。为了节约大家时间，我就直接和对应的研发口头沟通。因为很多小细节稍微做点修改就好了，工作量也不大，原以为研发会很快修改好，但是到最后发现，研发响应速度太慢，之前提到的需要修改的问题并没有去完善，被遗忘了……

2）为了让所有人的认知处于同一水平，同时方便上线前的产品测试核验，任何的需求变更都录入到需求管理表或者产品功能的featurelist中，并让团队所有人更新文档

由于本次为了加快响应速度，所有的featurelist都放在了原型文档中呈现，但是原型的原始文件莫名其妙不见了（悲催的……），只剩下了一个pdf版文件。导致中途很多需求的变更都不能及时以一个统一、整体的书面版本交付给大家，最终的结果就是，虽然口头或者零散的书面通知了所有人，但是还是很多人都是参照第一个版本的产品设计来开发、测试。

---

其他

相比于典型的互联网产品设计，虽然此管理系统非常小，但是产品设计的整个过程，除了战略层不需要有太多考虑外，其他层面也都基本需要相同的考量和设计。