产品设计阶段中的设计准则

21天Excel零基础速成训练营,导师带学+答疑辅导+实战作业,让你真正掌握Excel技能,了解一下>>

产品设计是与时俱进的,而产品设计的准则也是如此。

 

我目前的团队自去年底组建以来,经历过多次的团队协作迭代,逐渐找到适合自己开发模式。每个开发团队的项目性质不同,或是因为项目初始成员的特质影响,会逐渐形成自己团队的特殊文化与适合产品设计的标准。

在 Medium 上有一篇产品经理写的文章,作者根据自己多年的经验,将产品开发团队分成了下列六种:

  1. 用户中心团队:例如 medium
  2. 增长型团队:例如 booking.com
  3. 功能型团队:例如 Atlassian
  4. 设计中心团队:例如 Apple
  5. 技术中心团队:例如 Google AI
  6. 初始团队:原文指的是具有满腔热血但还没有明确 KPI 的团队,常见于新创团队或是黑客马拉松项目(Hackathon Project)

虽然每个团队专注的焦点不同,产品设计的标准也有可能不同,不过产品设计的通用性「准则」,应该是可以应用到多元的团队上。

虽然这几年开发团队不断朝著扁平化发展,一个产品的好坏不再是产品经理的全权责任,但产品经理在产品设计的整个阶段,仍扮演了十分关键的角色。也因此,产品设计的通用准则,对产品经理而言,不仅要熟记于心,更要灵活运用这些准则,培养使其成为一种直觉。

探索问题阶段

1. 想解决人们的什么问题?

这是一个一开始也是最后的问题,这个问题的关键角色,永远不会是问题本身,而是使用产品的「人」。

2. 为什么这个问题值得被解决?

听起来有点玄,但实际上并不是所有问题都值得「被解决」。

跟大家分享个小故事:我们现在使用的键盘叫做 “QWERTY 键盘”, “QWERTY” 就是键盘左上边数来的字母排列顺序。你可能会想,这个键盘的排列方式是希望能帮助打字更快、更有效率,很抱歉,刚好恰恰相反。

QWERTY 键盘推出时,还是 1800 年打字机的年代。当时技术发展有限,打字机的响应速度比不上人类打字的速度,因此常常出现打字机故障的情况。 QWERTY 键盘的设计,其实是为了降低打字效率,特意将最常用的几个字母分开,在当时也成功解决了打字机卡死的问题。

随著技术不断进步,许多人想解决 QWERTY 键盘降低打字效率的问题,也的确推出了更符合人体工学、能提高打字效率的键盘,但一推出到市面上,最终都是以失败收场。因为人们早已习惯 QWERTY 键盘,甚至有除了键盘输入以外的信息输入方式。也因此,「QWERTY 键盘降低打字效率的问题」,就不是那么值得需要被解决了。

3. 这个问题是否是一个真正的问题(本质的问题)?

我们团队曾遇过一个真实的案例:业务主管跟你说他想要做一个实时监控业务员定位的功能,如果 IT 团队将这个功能实现了,会发现实时监控不但对于数据传输量的要求相当高,也非常耗费业务员的网路流量,而且业务主管平时工作忙碌,几乎不可能「实时」监控。

其实业务主管提出这个需求的背后,是想了解业务员是否确实执行工作,而实时监控,只是业务主管基于这个本质的问题所提出的一个可能的解决方案,但却不一定是个合适的解决方案。

4. 这个问题是否简单、清晰,足够被其他人理解?

换句话说,如果一开始就无法清楚定义问题,那又怎能产出具体有效的解决方案呢?

执行阶段

(1)全局在前,细节在后

深入一个解决方案之前,确保已经尝试过其他的方案。最快的验证方式,就是当团队其他成员提出「怎么不试试 XXX」建议的时候,就代表想的还不够全面。

(2)原型图快速验证方案

如果产品已有明确的目标使用者,在进入开发之前,可以通过简单的原型图先让这群使用者进行测试(可用性测试 Usability Testing),藉此快速验证方案。

(3)设定产品的预期结果

包括任何质化或量化指标,比方说减少 20% 的操作时间、提升整体使用满意度……等等。

(4)排序功能开发优先级

一个完整的功能里,一定有最重要、次重要以及较不重要的排序(MoSCoW 优先级)。过去强调全面、完整功能的瀑布式开发流程,在现代快速迭代的数字世界里已逐渐被敏捷思维所取代。

举个例子:当 A 团队还在为那从 90 分进步到 95 分的功能苦恼而迟迟无法推上线时,竞争对手 B 团队早已将 80 分的产品推上线,虽然 80 分的产品让终端使用者不是很满意,也有不少抱怨,但 B 团队收集到了真实使用者提出的问题,并进行改版。

当 A 好不容易将 100 分的产品推上线,却发现市场早已被 B 占据,而且 B 的产品经历多次改版,更符合使用者的需求,当初 A 团队坚持的 100 分产品也不是当今市场的 100 分了。

(5)快速试错,迅速调整

以更包容的心态来面对错误的发生,检视个人或是团队在面对错误发生时,是否有足够快速的应变能力,能迅速调整方向,并且记录问题、总结归纳,不再犯同样的错误。

(6)阶段性反思总结

无论产品成功或失败,团队反思是整个执行阶段中最重要的一个环节。团队反思,绝不是互相抱怨的批斗大会,而是一个阶段性任务完成时,让团队彼此都能够沈淀思考,调整步骤继续迈步向前的机会。

尤其在跨功能的团队里(cross-functional team),可以更好了解各个团队成员在协作中遇到的挑战、当下的解决方式,以及未来可以如何调整合作的方式。

团队反思的时间可以是在一个大的开发版本上线前后发起,通过 1-2 小时的会议,有明确的主持人、会议记录者,分别感性与理性的两个时间段。感性的时间里,让大家说说过去的开发过程中看见好的、不好的以及要感谢的地方;理性的时间里,明确的提出问题点,让团队一同来思考解决方案。

验证阶段

(1)设定验证指标

在产品上线之前,就必须将验证指标设定好,并确保团队每一位成员认同各项指标。

(2)设定反效指标

这个验证方式是 Facebook 产品设计副总监(Product design VP)Julie Zhou 提出的,验证一个指标是否成功,就把不成功的指标条列出来。

(3)找出问题比调整方向更重要

产品上线后,如果发现偏离指标的情况,无论是好的或是坏的方向,首先厘清问题发生缘由,再来调整策略。

 

作者:Yvonne Wu,微信号:yvonneyvonnewu  领英:Yvonne Wu

本文由 @YvonneWu 原创发布于人人都是产品经理。转载请标明原作者与出处。

题图来自 Pixabay,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
4人打赏
评论
欢迎留言讨论~!