刚进入国内某分散式长租公寓公司时，接受到的一个任务是将维修员使用的PC端移动化，本文主要是讲述的是产品设计过程。
用户对工具型产品的核心需求是效率，具体个人觉得可以分为四方面：
流程框架：流程真实映射用户需求过程，正确对接后台各模块，契合用户使用习惯
功能划分：功能简单易上手，信息分级清晰，减少误操作
三方交流：维修进度出现问题时能及时反馈，帮助用户解决
快捷寻找：将急需处理的工单与重要信息优先、突出呈现，提高工作效率
这四方面是基础，和移动端的使用场景决定了需求的交互架构和功能。
立项背景
过去，PC端是为了管理维修而建。随着业务的发展，简单修改后台后对底层维修员开放了部分权限，维修员通过移动浏览器访问后台进行工单操作，维修员数量增加后，原系统效率低下的问题开始凸显，不方便、不稳定，难以适应移动化工作的新要求，主要有以下问题：
项目目标
1.将PC上常用的功能与信息剥离并迁移到APP上；
2.相比于PC的繁琐操作，APP需要简化流程并避免重复输入相同信息，提高效率；
3.辅助业务方优化原业务流程；
4.利用移动端可轻易采集信息的特点，监控维修员的行为并加以规范。
需求流程
项目按照标准流程进行管理，概括为需求交付（调研设计评审）→需求开发→需求测试→上线验收四步。
一、需求交付
1、需求调研
在需求调研阶段，我们需要了解我们做此项目的业务背景（问题来源、涉及的部门/同事及流程）、项目目的（愿景和功能要点）和实现方式（基于现有系统改造还是打造新系统，前端用APP还是H5等）
针对此项目，我们调研需求时需要确定项目的需求方/关联方有哪些部门和同事、需要解决的问题都罗列出来，如：
在确认对接人之后，我分别对接需求方进行现有业务流程的调研梳理，在调研业务流程时，有三种方法：
1.在对接人工作时观察其操作行为，并聆听和记录对方的反馈——涉及报修人、一线维修员、二线调度人员与客服、管理经理等；
2.获取现有业务流程相关的文档，如部门培训文档和系统操作手册等——涉及维修员培训手册、原PC后台文档、报修人前台后台流程文档；
3.获取现有业务依托的后台账号，直接上去查阅或操作已有数据——涉及报修人端、维修员端、admin端。
经过上述过程后，基于项目的目标，收集好相应记录，再将各需求部门的流程进行整合，统一输出一份跨职能流程和项目功能列表，如下：
注：只展示一部分
2、需求设计
基于调研阶段确定的内容，在需求设计阶段，产品需要输出原型，让需求方可以提前感知项目未来的界面和操作流程。
产品结构图：
3、部分原型页面
文档备注：
1、技术细节提前与研发人员沟通了解，减少反复修改的次数；
2、不同状态的工单详情页大同小异，总结其差别后用表格归纳方便开发人员；
3、复杂流程除了页面原型以外，线框画出流程；
4、将业务细节与对应岗位人员也在文档内做备份，方便将来其他产品经理查看文档；
5、状态变化节点按规范统一标明，push节点、内容等用表格整理归纳。
设计细节：
1、输入过或数据库里已有的字段直接调取，减少输入内容，提高维修员使用效率；
2、从前台限制维修员操作，减少管理成本；
3、简化操作流程，去除繁杂的中间步骤，优化现有工作系统；
4、只展示必要信息，通过信息合理分级、页面布局优化、消息高频提示等举措增加维修员专注程度；
5、对接风控、增加定位等举措，从前台监控维修员的工作行为，带来了更好的管理效果。
4、数据埋点
基于业务需求、产品迭代需求，对app页面埋点，通过SDK上报埋点的数据结果，记录、汇总并进行分析，推动产品的优化或指导管理运营。
5、其他注意点
1、数据兼容
由于项目上线前，已有原PC系统，移动端上线准入相关功能需要考虑原有数据是否同步和处理，保证PC、移动的一致性。
2、用户设备
服务端app的用户经常使用低端安卓机，性能差、屏幕小、耗电高，需要对这些特点做对应优化。例如，在输入框输入内容时，有些低端安卓机的系统自带键盘没有确认搜索的按键，所以搜索框旁得放置确认按键。
建立产品设计需求自查表
1、各个流程节点中的通知形式与内容（弹窗、通知栏通知和短信等）是否确定；
2、前台内容是否需要后台添加字段并返回内容；
3、用户的提交操作、状态变化是否有toast反馈；
4、设计过程中是否考虑到临界和极值情况，比如数量大小，内容长度、图片大小；
5、是否和UI设计师沟通页面中内容的字数长度，设计细节；
6、需求开发完成后是否对产品中的一些关键操作埋点；
7、是否考虑到流程中会存在中间状态，如何对中间状态进行设计，
比如维修员完成工单本状态的操作后，需要手动操作工单进入下一状态，这一时期应该如何设计；
8、需求设计是否能够形成闭环；
9、需求设计是否充分考虑到目标用户、场景、核心功能；
10、用户操作完后返回上一层是否需要自动刷新数据；
11、信息填写页面是否考虑过需要给用户缓存内容；
12、信息填写页面是否对填写顺序以及内容跳转有要求
13、设计过程中需要考虑到用户拇指的点击区域，在靠近拇指的地方放置点击操作入口；
14、做网站要考虑浏览器兼容问题，前端设计还需要考虑极值（文字、数量、行数）、对齐方式（参数物、对齐类型）；
16、迁移PC功能到APP时，需要注意是否需要做多终端数据互通和数据一致性问题；
17、用户操作完成后跳转到哪里，是否需要缓存进度条；
19、数据为空、网络连接断掉等情况如何处理。
其他小结：
1、app用户有教育程度低、学习能力差的特点，应尽可能减少用户误操作与学习成本，app结构层尽可能简单、清晰；
2、用户的注意力和时间是有稀缺性的，一切的需求（功能，交互路径、视觉UI）必须考虑到优先级的问题；
3、给与用户操作反馈，无论是正向还是逆向，比如当维修员处于等待申请批准的状态时，用户最需要的就是获知申请进度与结果第一时间通知，所以必须有对应设计；
4、产品经理需求的主动性要掌握在自己手里，需求的来源、受理和用户尽量要自己第一手接触，而不是引用别人讲的；
5、产品设计需要考虑用户以往的习惯，包括操作上和心理预期的；
6、需求方有无限个伪需求，面对一个需求确认问题，同一个对接人可能前后给出两个截然相反的答案，眼见为实耳听为虚，产品经理一定明确需求；
7、对已有后台的改动牵一发而动全身，如有必要修改也应该多方确认。
二、需求开发、测试
1.开发阶段
需求讨论明确、原型更改没有异议后，产品经理需要根据产品功能复杂度等综合因素，安排开发进度。开发进度的安排尤其重要，因为如果开发期限过长，则容易导致开发人员缺少激情产生惰性，而开发期限过短则会使开发人员心理压力过大，容易降低代码质量从而对后期版本更新产生隐患。
当正式进入开发阶段后，产品经理需要做的是：一边跟进开发进度，把控开发质量，一边设计下一版本产品原型。
这一阶段对于产品经理也尤其重要。产品从0到1的过程以实现核心功能、减少产品bug为主，而当第一版本发布后，需要根据市场变化和产品理念进行迅速迭代。因此这个开发阶段是产品经理思考产品发展方向和规划下一版本改进目标的关键时刻。
2.沟通技巧笔记
可以通过问题的发生的概率和带来的影响、方案带来的提升和开发的成本去说服对方：
1.当你想要解决一个问题的时候需要考虑一下这个问题发生的概率和带来的影响；当你告知别人你有一个方案的时候需要考虑下方案带来的提升和开发的成本。这几件事情想明白之后你才可以去和你的同事沟通；
2.发生设计问题时先判断发生频率，立即评估，而不是立即去改。因为此时产品已经开发过半，返工和延期都是很影响研发进度的，而且还会影响到后续功能的设计。发生频率很低的问题可能重要但是不紧急，可以推后到后续版本更新中解决。当需求进开发后发现设计缺陷时，或是要和其他部门竞争开发资源的时，先评估。
3.如果真要修改设计，必须通过邮件让大家明确产生这种修改的原因，让所有人明白，这个是全团队的大事。
好的沟通是确保未来长期良好合作的基础。
三、上线验收
更新迭代
产品从0到1的过程以实现核心功能、减少产品bug为主，而当第一版本发布后，需要根据业务变化迅速更新迭代。因此上线后产品经理也不能松口气，需要跟进bug修改，继续思考产品优化方向。
