规划及推出超棒用户体验的有效方法
产品经理们 + 设计师们
大部分组织架构下，设计师（们）和产品经理（们）都是亲密合作的。产品经理对产品功能中的元素有很大的发言权。他们有权否决设计决策，也有权决定某个产品的特定用户流程是如何设计的。他们也完全参与到商业需求的分析中，并思考如何塑造产品去满足上述的需求。他们思考用户如何与产品交互，并分析产品是否满足目标用户的需要。他们帮助工程师构建需求的优先级列表。他们是决策者，帮助建立产品路线图和维护/定义产品的愿景。
这是一个责任很重的角色，不是吗？
简而言之，他们是超级巨星，他们工作在高压环境下。在任何给定的时刻，总有超多他们难以啃下的难题。
设计师需要配合达到产品经理的目标，因为归根结底，这两个利益相关者有相同的愿景。
思考流程的不同
说实话，起初，我很难和产品经理的思考流程在同一个频道上。作为设计师，我们倾向思考关于体验，关于路径，以及设计组件有多么一致，并如何使它们更好的工作在不同的分辨率上等等。
另一方面，我们不太关注当前的业务需求、技术的影响、产品策略在未来几个季度的路线图以及资源分配等。
显然，我们不会本能地去关注这些，这就是为什么在产品世界，和产品经理协作是一个基本需要——它有助于描绘一幅更广阔的图景。
在与产品经理密切合作了很长一段时间后，我决定记下那些帮助我设计时更具目标的方法论。
以下是我采取的一些行动，排名不分先后
1. 排列任务优先级
2. 维护一个用户体验债务表
3. 建立一个用户体验测试方案
4. 在产品内追踪用户行为
1. 排列任务优先级
我注意到，一旦提起逻辑不一致或改善样式等话题经常激怒产品经理。后来我意识到不是因为他们不想修复或者那些不重要，而是没到合适的时机。但总有一个合适的时机让你来提起你最大的痛处。
那我们怎么知道什么时候是合适的时机呢？
回答这个是比我想象的要难一点。我的做法是，从更广泛的角度理解产品状态。
我开始注意当前的业务需求和技术的影响。
业务需求 —— 在最早的时候需要做些什么来提供价值。 因为如果你不获利，你就不是一个成功的生意。实际上，没有任何领域是可以为也许不存在的需求做设计的。
技术需求——需要做什么去稳定系统而不会破坏现有的功能。还有那些需要优化去提供一个更好的体验的事情。
理解技术限制对设计决策有很大帮助。一些看上去优雅的交互可能对系统是巨大的负载，所以必须权衡利弊来维持系统稳定。
当功能都被毁了，性感交互的意义何在？
考虑到这两个主要需求，除了「我想做的设计变更」的超长清单外，我开始排优先级清单。
产品需要进行重大更改的模块，优先级通常会下降，创造价值最大的项目会上升。优先级清单帮助我更好地安排工作。
当合适的时机来临（相信我，它会来的），我会立即提出我已经想好的重设计方案，这使得和产品经理的合作更富有成效并较少冲突。
2. UX 债务表
几乎所有的设计师应该都从产品经理那里听过——
「让我们先拿出MVP（译者注：最小可行性产品），我们可以晚点再回来优化它。」
这让我感到非常沮丧，因为我意识到产品目前的变化是非常微小的。这不是我想要的作为一个设计师的理想体验。
我担心如果我们一直用MVP的做法，我们最终会需要加更多的班只为了去修复遗留问题。这更像是一个MVP悖论。
巧合的是，我注意到工程师们有一个技术待办事项的账户，他们称之为技术债务。这是一个待排期的技术任务清单。他们专门用一轮冲刺（Sprint，敏捷开发词汇）完成这些任务。我认为这是一个伟大的想法，不知道在我工作的项目中是否也可以运用这么一个UX债务表。
我和产品经理讨论过后，决定列出所有的用户体验待改进事项。我制作了一种图表，将改变产生的影响和实现的难易程度映射在坐标系上，来作为排列任务的优先级的参考。
你可能注意到了坐标系中有四个象限，数字代表的是优先程度。
第一象限——任务很容易实现并能产生较大的影响。 这些带来最大价值的需要首先解决。
第二象限——容易实现但影响不是很大的任务。 这些需要接着推动的许多小改进能帮助我们带来优秀的体验。
第三象限——接下来我们开始处理产品中那些难实现的部分的任务。这些更难去实现的任务应该具有最大的影响，这点很重要。
第四象限——这个象限的任务优先级很低，通常不会去解决。要想将这些任务从这个象限常年居于次要的位置移除，可以把它们分割为子任务，然后优先级的判断流程可以再次被应用到这些子任务上。处理这个象限的任务是一件很有挑战性的事情，我仍然试图找出如何更好地处理这些任务的方法。
接下来得有个记录的地方，得让它们在视线之内，以免忘记。我所在的团队已经很习惯使用JIRA来跟踪大部分项目进度。
为了将设计的优先级安排更好的曝光，产品经理建议我创建一个「用户体验改进」JIRA项目，这是个明智的举措，现在我们每个人都能随时在看板上看到设计的改进，因为所有完成的原型和文档都共享在那了。
不同的团队使用各种不同的项目管理工具。我们的UX团队用Trello维护UX待处理清单。我也看到某些开发团队使用Basecamp。
3. UX测试方案
我在研究生院时代的设计流程是，在决定怎么设计之前，做大量的用户研究和分析。这意味着有足够的时间计划和执行这些研究。但在敏捷的环境下，并不能总这样。功能设计与某些假设是基于现有的使用模式和对目标受众的了解
大部分假设都会通过用户电话验证。在发布给用户验证之前建立一个测试方案是很重要的。为了尽可能发挥和用户交流30-40分钟的价值，我倾向于和产品经理精心组织给用户电话。
大多数用户反馈电话的结构类似这样——
- 测试的目的
- 需要被证明的假设
- 用户在界面上的操作路径
- 得到接下来他们在产品中期望什么的大概想法
4. 追踪产品中的用户行为
现有用户的行为是重新设计产品的良好依据。如果现有功能的使用流程因技术限制而需要改变，又或者现有用户对功能的可用性存疑，那根据数据去制定重新设计的方案是个很好的办法。类似谷歌分析这样的数据分析工具提供一些途径去评估用户流失率、用户的操作顺序等等。但在大多数情况下，产品需要更细致的追踪。
用户在进行点击操作时发生了什么？用户接下来会去哪个界面？如何衡量一个功能是否成功？这样的问题可以通过追踪操作路径来得到回答。
一个设计师，为了更好地表达他们的设计决策，需要分析和找出需要追踪什么，为什么要追踪，我们最终想达到什么目的。
更复杂的事件追踪和详细的漏斗分析，像MixPanel和Keen这样的工具提供他们的API来让我们自定义更细粒度的追踪。如此丰富的用户数据可以帮助设计师们作出更好的决策并更清楚的传达给其他利益相关方。
能帮助设计师分析这些数据的最好一位朋友，就是产品经理。产品经理可以直接访问这些数据，他们中的一些也深入参与这些工作，所以他们对这些数据更有全局观。
总结
本文不是一篇教导设计师如何规划他们与产品经理工作的广泛指导，但无疑可以告诉大家如何往正确的方向迈出一步。产品经理帮助我学会思考像素以外的东西，帮助我们排列任务优先顺序，为我们正在设计的东西提供了一个全局的视角。
我对你们和产品经理合作的流程同样感兴趣，我很乐意看到你们在下方评论去留言 :)
本文转载并翻译至 uxdesign.cc
原文地址 https://uxdesign.cc/a-designers-guide-to-working-with-product-managers-bcb164a473df？scid=social70785596#.qd6b343ze
原作者信息
I am Adhithya, a Product Designer at OpenDNS, San Francisco. If you liked this article, hit the recommend button below. ️
You can find me on Twitter. Check my work here, or simply write to me at [email protected]