今天继续为大家更新《启示录-如何打造用户喜爱的产品》
第19章
用户体验设计与实现
User Experience Design VS. lmplementation
先定义用户体验再动手开发
在软件开发过程中，有很多工作可以同时进行。比如，我一直认为需求调研和产品设计(用户体验设计)是互相影响的，应该同步展开。我不喜欢老式的瀑布式开发模型，产品经理先完成需求调研，然后交给交互设计师设计。业界已经认识到这是一种陈旧的产品开发思路。
此外，多数软件开发团队已经尝到了开发与测试交叉进行的甜头， 我认为这是巨大的进步。以前的做法是开发人员先编写代码， 全部完成后再交给测试人员测试，不但耗费时间，而且可靠性差。
尽管如此， 有些工作不能同步展开。许多团队把用户体验设计和软件开发放在一起进行，这是行不通的。原因如下。
1.与软件开发团队合作的人要记住一点：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。因为开发团队必须根据确定的用户需求和产品定义设计软件架构，然后进行开发。前期架构决策极大地制约着后期的开发工作，事后修改软件架构，无异于推翻重来。另外，从心理上说，事后修改设计会打击开发人员的斗志，引发消极的心态。随着时间一分一秒过去，返工和波动会增加团队的压力。尽管敏捷方法提倡不断修改和完善，但并非所有的修改都受欢迎。
2.用户体验设计要保证产品同时具备可用性和价值，任务很重。为了拿出既可用又具有价值的设计，必须尽早、反复地验证设计思路。有些人觉得可以等到每个迭代周期结束再观察设计思路是否合适，甚至等到产品公开测试时再收集用户反馈，这样低效的验证方法肯定是行不通的。优秀的用户体验设计师一两天内要尝试几十个点子，哪怕只是2~4周的迭代周期都会慢得让人无法忍受。
3.我认为验证设计思路必须使用高保真原型。有人说，迭代结果和公开测试的产品可以当做原型。抛开要等很长时间不谈，这些开发中的产品与产品原型有很大的区别，不能混用。为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该被丢弃。而开发中的产品应该以固定的原型为基础。
4.尽管产品开发可以分成多次迭代(这样做可以降低风险，提高质量，便于产品集成)，用户体验设计却不能拆分。设计师必须全面地、连贯地看待用户体验，考虑以往用户的使用习惯。让用户放弃不可用的软件很容易，要他们放弃使用习惯却很难。
5.用户体验设计不一定是最费时间的工作(像软件开发一样，所需时间取决于具体的方法、特定的产品需求，以及从业者的技能和经验)，但至少需要一两周时间。如果产品设计和开发同步展开，那么多半会出现这样的情况：一方面， 开发人员等着设计师的设计结果无事可做；另一方面，设计师饱受压力， 要在几天内完成原本需要几周完成的工作。为了应付差事， 设计师只好不情愿地拿出仓促完成的设计交给开发人员。开发人员一边开发，设计师一边修改设计。等设计师最终完成设计，为时已晚，开发人员会说: “等下一轮再修改吧。”但下一轮又有下一轮的重点。设计师对产品不满意，用户更不会喜欢这个结果。
如果我遇到这种情况， 肯定会辞职，到一家看重用户体验的公司去谋职。
还好，这个问题不难解决，关键是确定先后顺序。虽然需求调研和产品设计可以同步展开，产品开发和测试可以交叉进
行，但是用户体验设计应该在软件开发前完成。
敏捷方法里有个概念叫“第零次迭代(sprint zero)”，产品经理和用户体验设计师利用这段时间先完成产品设计工作，然后交由开发人员开始迭代开发。这需要更详细地定义待开发任务(backlog) ，但团队工作会更愉快，产品也会更好。
只有在开发人员要开发大量后台基础软件的情况下，用户体验设计和软件开发才能并行展开。在这种情况下，开发团队可以利用设计师设计产品的时间完成这部分工作。虽然双方的工作会有一些依赖关系，但可以解决。多给设计师一些时间定义详细的待开发任务。
请注意，尽管我提倡需求调研和产品设计都要在软件开发前完成，但是在此期间至少应该邀请一位软件开发人员检查设计工作，他可以协助你评估设计的可行性和成本，作出更明智的决策。别忘了，我们的目标是打造有价值的、可用的、可行的产品。
许多产品团队在尝试敏捷方法的时候，出现了设计上的混乱。这实在是可惜，因为只要稍作说明和调整，敏捷方法相对于传统的瀑布式开发方法来说是巨大的进步。我在第26章会讲述出现混乱的原因，以及如何合理利用敏捷方法。
第20章 基本产品
Minimal Product
削减功能还是延长工期?
我号召产品团队放弃老式的产品设计方式。比如，不再试图定义最终产品，转而定义只满足基本要求(价值、 可用性、可行性)的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，它就是一个不可分割的整体，去掉任何元素，都不可能获得预期的效果。
你见过这样一幕吗?产品经理制作了完善的产品说明文档，详细标注了各项产品功能的重要等级。然后，开发部门根据这份文档估算开发成本和开发时间。虽然剔除了开发团队力不能及的功能，但得到的进度表还是比产品经理设想的多几个月时间。于是双方开始协商，先是争论估算是否准确， 然后不得不削减功能，缩小测试范围，减少公开测试时间，要求雇佣额外的开发人员.....不知不觉时间已经流逝。我猜测你多半见过这一幕，即使没有见过，也能猜到结果：最后开发出来的产品完全不是有机的整体，产品经理不满意，开发人员不满意，用户更不会满意。很多团队把这种情况看成理所当然的、不可避免的，其实这是不合理的流程造成的结果。因此，我建议采用另一种产品设计方式。
第一，产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因而是非常重要的。
第二，邀请一位开发人员(比如架构师或主程序员)参与设计原型。请他检查原型， 帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，他详细估算出所有产品功能的时间成本。这样一来，各项功能孰去孰留已经明了，而且对各方都是透明的， 开发团队心里也有底了。
第三， 请真实用户验证(测试)产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验证。这好比不能仅仅因为开发人员相信代码没问题，就允许发布代码一样，必须对代码展开测试。
一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能。如果还能削减，那说明你定义的不是基本产品。当然，根据产品原型估算的开发时间也不是完全准确，比如，对某些功能的开发时间的估计可能过于乐观。如果出现这种情况，只能延长工期，不能削减功能，因为你已经没有东西可削减了。尽管如此，由于估算的依据从一纸文档变成了精减功能的原型，精度还是大大提高了。即使延长工期，情况也远没有以前严重。
由于开发的是基本产品，一旦进入软件开发环节，产品经理就不能再随意修改设计。过去产品经理经常要求更改产品设计，主要是因为一开始构思不全面、不彻底。 设计高仿真原型能够迫使产品经理改掉这个坏毛病。
有人认为，类似Scrum这样的敏捷开发方法可以用另一种方式解决这个问题。虽然我也建议大家采用敏捷方法(因为敏捷方法确实有其优点)，但它并不能解决这个问题，反而可能带来新问题。相关内容请参考第26章。
因此，设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的——断腿的狗打不了猎。
第21章
产品验证
Product Validation
证明产品的价值、可用性、可行性
前几章里已经提到了产品验证的概念。产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。
过去验证产品的代价不菲，而且困难重重。通常只有生产成本极高的产品才会这样做，比如汽车。如今创建仿真原型的成本已经非常低了，如果还有不做产品验证的团队，我会感到非常惊讶。
产品团队对自己的产品往往过于自信，不愿意验证产品，只顾埋头开发，总想等到公开测试时再收集反馈意见。毫无疑问，到那时再想大幅修改产品是不可能了，因此许多产品刚发布时表现得非常糟糕，这也不足为奇。
产品经理向产品团队提供最终的产品说明文档前，需要进行以下三项重要的验证。
可行性测试
首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。有些方案通向死胡同， 但总有些是可行的。
重点是让开发人员寻找产品设计里那些难以克服的障碍，现在发现远比损失了时间和资金后发现来得好。
有些产品的技术风险较大，如果你的产品存在可行性风险，一定要提前解决这些问题。
可用性测试
交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。
可用性测试往往能发现没能成功实现的产品需求，如果测试得当的话，甚至能发现原本被忽略的产品需求。最好规划多次迭代测试，确保实现最佳的用户体验效果。
一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息。虽然产品经理和设计师也能从设计和使用原型的过程中掌握大量信息，但这些都不能代替让真实用户体验原型的作用。
请注意，为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。
价值测试
最后，仅仅知道产品能够开发出来、方便使用，这还不够。同样要紧的是知道用户是否觉得你的产品有用，是否愿意购买，有多喜欢产品的设计。
价值测试可以和可用性测试同时进行，使用的原型也是一样的。只不过可用性测试重在观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式。
简单的产品也许在纸上画画原型就够了，但对于大多数采用复杂用户界面、运用新技术的产品来说，必须借助产品原型评估设计是否符合要求。
不同的产品有不同的原型，比如，常见的原型是可点击的页面，当然，原型也可能是物理设备，或是软件与硬件的结合。无论哪种形式的原型都必须足够真实(高保真)，可以提供给目标用户测试，并获取有效的用户反馈信息。
不久前，还有人争论究竟应该使用高保真原型(如我所提倡的)还是低保真原型(主要是图纸)。我认为这样的争论已经没有意义了，因为使用高保真原型的成本已经大大降低，而通过它得到的反馈信息绝对物超所值。
过去使用原型主要有两个的阻碍。其一是缺少制作原型的工具，制作原型非常耗时；其二是管理层不明白原型和真实产品的区别，产品团队被迫在原型的基础上开发产品，最终的产品质量可想而知。
如今有各种原型制作工具可供选用，设计师和开发人员只要几天时间就能根据要求制作出原型，模拟未来的产品，提供给用户测试。多数管理者已经明白，制作原型与开发产品完全是两码事，好比制作房屋模型和建造房屋的差别。
使用原型并非验证产品(尤其是互联网服务)的唯一方式，还有其他简单有效的方法，但它们都强调在正式开发软件前验证产品设计，因为设计总有考虑不周、出人意料的情况。越早发现问题越好，不要等到产品公开测试，甚至正式发布才醒悟。一旦进入开发阶段，修改产品设计的难度和成本会越来越高。
以上从用户体验和设计、基础产品、产品验证三个阶段告诉产品经理在面对日常工作中时，如何去平衡产品的功能点，如何和开发进行沟通、以及如何验证自己设计的产品最终是否符合最初的期望。每个阶段的经验方法都很有启发意义，希望能对各位产品经理的工作有所帮助。
想要了解更多产品经理的经验和技能，欢迎加入我们。
网友评论