《启示录》读书笔记系列--笔记十三

需求调研应与用户体验设计同步进行，因为两者相互影响，而不应是瀑布模型

开发与测试也应该同步进行

但是.......

用户体验不能与软件开发放在一起，原因如下：

1，一旦产品进入开发，修改思路非常困难，越往后成本越高。因为开发团队根据用户需求和产品定义设计软件架构，后期开发一直围绕架构进行，返工容易打消积极性。

2，用户体验设计同时保证可用性和价值，任务重，应该反复验证。等到迭代周期后，在观察思路是否合适，是行不通的。

3，验证设计师的思路必须用高保真原型。

问：是否可以把迭代结果和公车的产品当作原型？

答：不可以，抛开等很长时间不说，开发中的产品与原型要很大区别。为了验证各种思路，产品原型可以随意修改或抛弃，但是开发中的产品不可以，成本太大。

4，尽管产品可以很多次迭代，但是用户体验不能查分。必须全面、连贯，考虑用户使用习惯。

5，用户体验虽不是最费时间，但也至少需要1-2周。

 

在时间紧迫的情况下，削减工期还是延长工期？                                                                        

建议采用另一种产品设计方式。

第一，产品经理与设计师合作设计产品的高保真模型，这个原型只具备商业目标的最基本功能要求，以及来了更好的体验和用户吸引力。可以降低复杂度，减少时间。

第二，邀请一位开发人员参与原型设计。请他检查，帮助产品经理和设计师估算各种功能的直接成本和间接成本，支持设计上的误区，并分析、评估尚不确定的功能，这样开发端对心里也有底了。

第三，请真实用户验证产品原型，这一点至关重要。开发前，产品经理必须确定产品是用户需要的。一旦通过用户测试，就不能再削减任何功能。

上述方法类似SCRUM，有句话--断腿的狗打不了猎。

 

证明产品的价值、可用性、可行性。                                                                                           

产品经理向开发团队提供最终产品说明文档前，需要进行以下三项重要验证。

可行性测试

首先，在现有技术明确的条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。

可用性测试

交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都明白如何使用。可行性测试往往能发现没能成功完成的产品需求，如果试用得当的话，甚至能发现被忽落的产品需求。最好规划多次迭代，获得最佳用户体验效果。此阶段，一定请真实用户测试可用性原型，得到反馈信息。为了测试可用性，即使模拟复杂的后台实现也是值得的。

价值测试

还应该知道，产品开发出来用户觉得是否有用，是否愿意购买，有多喜欢产品设计。价值测试可以和可用性测试同时进行，使用的原型也是一样的。只不过可用性测试重在观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式。