产品设计中的 “快速迭代” 思维

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了产品设计中的 “快速迭代” 思维相关的知识,希望对你有一定的参考价值。

一谈到“互联网思维”,大家都会想到“快速迭代”。但我发现,很多人对于快速迭代的理解是不够全面的。

 

大部分人对“快速迭代”的理解是:一个产品,所有的功能不用一次做出来,做好一部分上线一部分,一些功能的完善可以等产品上线后,靠后续版本,慢慢改进。

 

有人基于上述的理解,会对“快速迭代”提出疑义:

1.     在总的工作量一定的情况下,分几次开发和上线,要完成所有的功能,所花费的总时间往往会更长,“快速迭代”究竟是提高了效率,还是降低了效率

2.     为了快速上线,“快速迭代”中第一个版本往往是不够好的。这样的版本是否会影响用户体验,导致口碑不好,不利于产品的后续推广

 

之所以有上述的疑义,关键还是对于“快速迭代”的理解不够深刻。

 

首先,“快速迭代”应该应用在探索型的产品设计上。探索型的产品,意味着大家对产品是否能很好满足用户需求,是否能成功并没有把握,这时如果做一个完整的产品再推出,一旦发现不符合市场需求,就会造成很大研发成本浪费,因此需要“快速迭代”,用一个不完整的版本去验证产品设计的合理性。探索型的产品的研发工作量是不定的,它会根据市场反馈增加功能或调整功能,因此采用“快速迭代”可以避免大的研发成本的浪费。如果是确定性的产品,的确可以尽可能完善后,才把产品推向市场。

 

其次,在应用“快速迭代”做产品设计时,一个不完整的版本,不等于一个粗糙的版本。不完整的版本,只是辅助功能有所缺失,但核心功能不会缺失,且在易用性,美观性上也会达到一定的标准。因此并不会造成产品口碑的大幅下降。

 

在产品设计过程中,应用“快速迭代”思维,关键是要找出“需要验证的市场假设”,用一个简单的产品来验证。下面是我过去工作中的一些例子:

 

1.     曾经我的团队做一个新产品,原型出来后,内部讨论时,大家觉得上线前,有20几个地方需要改进。当时,我发现这些改进点都不影响用户对核心功能的使用,所以我的决策就是一个都不用改,直接先给用户试用。我给团队的解释是,有可能我们新产品最核心的功能打动不了用户,我们会把产品整个推倒重来,如果是那样的话,做这20几个的改进点,就是一种资源的浪费。即使新产品打动了客户,后续需要做进一步完善,我也倾向于与先听听真正的客户觉得产品哪些地方最需要改进,有可能客户提的和团队讨论出来的20几个点是一致的,但更有可能客户觉得优先需要改进的,是其他方面,或只是这20几个点中的一小部分。后来,事实证明,新产品还是受到了用户的好评,但团队原来觉得要优先改进的点,大部分从用户角度来说,并不是很重要。

 

2.     我曾经规划过一个 SaaS 产品,当时新产品有3种可能的侧重点,吃不准客户会更接受哪一个。为了决定究竟选择哪个方面作为产品的侧重点,我们并没有在内部做过多的讨论,而是飞快的推出了第一个版本,这个版本是一个不完整的版本,网站上只有产品介绍,和“申请试用”按钮,申请试用后的功能什么也没做。当用户“申请试用”时,会弹出一个类似“谢谢你对我们的产品感兴趣,我们会主动和你联络”的页面。而产品介绍其实我们有三种,分别对应了一种产品设计的侧重点,某个用户在看产品介绍时,会随机看到三种中的一种。根据一周内,用户“申请试用”的转换率,我们知道了大部分用户更认可其中一种的产品方向。有了这个结论后,我们才开始真正做下一步的产品设计。

 

当对一些重要的产品决策没有把握时,在传统的思维中,往往会通过内部讨论,慎重地做一个决策,在决策基础上做完整的方案设计。如果决策错误,就会导致产品的失败,即使发现错误后再修正,也会造成大量时间和精力的浪费。而在“快速迭代”理念的指导下,我们会用尽可能少的资源,尽快推出原型产品,通过用户反馈来验证产品决策的正确性并决定下一步的方向。


本文出自 “千里之行,始于足下” 博客,转载请与作者联系!

以上是关于产品设计中的 “快速迭代” 思维的主要内容,如果未能解决你的问题,请参考以下文章

谈谈产品敏捷开发的几大要点

Python设计模式 - UML - 总览

模块化的设计思维在产品造型中的应用

如何敏捷开发 如何快速迭代

腾讯敏捷开发及快速迭代

一号旺铺小程序优点之产品迭代 好产品都是改出来的