产品总结：工具类软件设计难点该如何解决？

　　本文笔者通过自身对工具类软件设计的经验，为大家总结了工具类软件的设计难点以及相关的解决方案。
　　近期，做了份地图样式编辑器交互设计任务。地图样式编辑器是款工具类软件，本着以小见大的原则，将以该产品为例着手总结与推理一下工具类软件的交互设计总结。
　　细细回想，在产品设计过程中仍有需要待商榷与调整的地方，但这并不妨碍业务目标与核心功能的用户体验，梳理总结目的之一也是为了改善这些细节点。
　　当然，因为是以小见大原则，该文必然会有它的局限性，比如：作者的阅历与经验局限，举列量少是否具备代表性，工具类软件类目是否可以具体再细分之类的问题。这些问题希望读者能在阅读过程中能一一辩解，毕竟该文仅仅算的上是私人总结。
　　那么，话不多说，开始谈谈：个人在地图样式编辑器设计过程中总结的工具类软件设计经验。
　　一、产品设计背景
　　地图样式编辑器是一款地图可视化类的软件。接到这项任务时，其实地图编辑已有初版核心页面，但产品功能、业务流程、人机交互与界面设计都存在很大的问题点，不然也不会找到我们部门提需求。
　　那么，首先理顺与确认需求，方法论参考5W2H。
　　在这个过程中，注意两点：
　　预计该项目参与人数与制定计划。我是认为参与人数不同，具体配合方式就具有差异性。这个因人而异，涉及团队成员的能力、工作方式以及为人等因素；
　　一定要二次（多次）确认需求，保证我们的设计方向正确。因为，理想工作方式是交互人员参与到定义需求中，但是实际工作，可能往往是产品经理直接制定需求拍板再丢给交互设计师，所以在与他们沟通中，要带有疑问与建议与他们确认二次需求。
　　其次，开始交互设计工作，工作流程如下：
　　二、产品设计难点
　　在产品设计之前，预计将要面临难点：
　　由于两个合作的部门不在同地，所以是异地视频沟通；
　　现存版本混乱，UE体验交互差，任务流程片段式操作；
　　功能庞杂，暂无法做测试判断是否取舍某些非核心功能，以节省开发时间；
　　之前版本无法给到大量用户操作体验反馈数据信息做为设计参考依据，产品本质上依然是理论上假设。
　　梳理这些难点后，会发现其实该产品依然处于0到1的过程。那么，如何解决这些难点？
　　先归纳这些难点所属那方面的问题，然后对应解决方案。
　　第一点属于设计师沟通问题。
　　异地沟通除了面临高成本沟通问题外，其实与面对面沟通没有太大出入，依然是需要设计师在沟通过程中理解人际关系，减少认知负荷，聆听理解与控制自己的心态。
　　（具体参考《设计师要懂沟通之术》）但需要注意一个现象，视频沟通无法营造共现（CoPresence），且心理重视程度：视频沟通小于面对面沟通。那么，必然沟通流畅度不够，需要反复确认。
　　第二点属于人机交互问题。可遵循尼尔森十大定律，不多赘言。
　　第三点属于需求定义问题。这个问题比较复杂，涉及每个公司的工作流程问题即：交互设计是否参与到产品定义需求的过程中。能参与当然最好，未能参与也不用沮丧，那就带着质疑与建议向产品经理反复沟通需求。
　　第四点属于用户调研与用户体验的问题。理论指导可遵循上篇文章《探讨产品价值下的UX设计》。
　　三、遇到的问题点
　　在产品设计过程中，遇到的问题：
　　团队合作，如何保持与能力不同的同事之间共同合作，推进工作。
　　保持个人建议的同时，如何去除个人情绪，以赞成产品经理的产品规划与安排？即，如何委婉的向上级提出建议诉求？
　　只有信息架构的情况下，是否就能满足UE设计的全部需求，什么情况下需要流程图？
　　个人的设计是有一定局限性的，得承认与认识到自己的局限性，聆听他人的更合理意见，并学习它；（老生常谈的问题）。
　　确保一次定义所有需求不切实际，一定会有遗漏点，需要承认这种现象的存在，所以不要怕返工补充（老生常谈的问题）。
　　问题点1、2、4归属设计师沟通问题，不多赘述，参考《设计师要懂沟通之术》。
　　问题点3归属流程问题。当时在设计产品UE时，为了节省时间与偷懒，理清产品信息架构后，就直接上手线框图，结果在中途就与到流程不确定的问题，又返回与沟通流程问题。所以在任何时候，尤其是工具类软件交互设计时，核心流程必须走一遍。
　　问题点5归属需求问题。一次无法定义产品全部需求除了是因为MVP的工作方式外，还因为我们没有给需求分类。当具有需求分类检查的参考时，会很好拾起被遗忘的需求，以便确认。需求可以按照“FURPS”模型进行分类（模型来源《UML和模式应用》第五章进化式需求）。
　　具体如下：
　　功能性（Functional）：特性、功能、安全性。
　　可用性（Usability）：人性化因素、帮助、文档。
　　可靠性（Reliability）：故障频率、可恢复性、可预测性。
　　性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率。
　　可支持性（Supportability）：适应性、可维护性、国际化、可配置性。
　　“FURPS”中“”是指一些辅助性的和次要的因素，比如：
　　实现（Implementation）资源限制、语言和工具、硬件等。
　　接口（Interface）强加于外部系统接口之上的约束。
　　操作（Operation）对齐操作设置的系统管理。
　　包装（Packaging）列如物理的包装盒。
　　授权（Legal）许可证或者其他方式。
　　亦可以使用其他需求分类方式进行检查，并不局限该分类方式。如果记不住，那么，打印出来，在沟通时照着一一提出，若没有就跳过。
　　有些需求是技术上，那就确认技术是否可实现，以及实现到什么程度。
　　四、小结
　　以上地图样式编辑器在设计过程中，遇到的问题以及现有解决版，说是工具类软件设计总结，但也可以说是通用的产品设计难点与目前解决办法总结，只是举的案例恰恰是工具类软件设计。