如何减少需求的含混性（下）
人们想要什么，这永远不是个简单的问题。有一个例子说的是：就算弗洛伊德比同时代的任何人都了解人们的欲望，他也搞不清楚女人到底想要什么。
需求的含混性无处不在，《探索需求—设计前的质量》探索的正是“人们想要什么”这个内容，本篇是此书的读书摘要之三。前两篇请参考：
如果在开始设计产品的时候不能够非常精确地知道产品究竟需要做什么的话，那么开发的进程就会变得混乱，就像没有度量衡一样货币无法流通。在开始这项工作之前，我们可以通过功能、属性，到约束条件，到偏好，再到期望的步骤，循序渐进地得到这些信息。
01 功能
功能指的是产品的“什么”，描述产品要完成什么。它们应该是动词，描述产品是为了做什么的动作。其做法主要有：
记录所有且惟一的功能。第一步是进行头脑风暴，以得到所有客户希望系统具有的功能。在这里，客户是一个集合体，是和产品相关联的所有“利益相关者”。在这个阶段，设计人员暂不提供想法，只需要协助客户充分发挥想象力即可，然后将潜在功能的原始列表展现出来。
一旦列出了功能列表，就可以将它们分为三大类：
E 代表明显的
H 代表隐藏的
F 代表装饰性的
在这里举一个简单的例子：茶壶烧开水，人们并不真正关系茶壶是怎样将水烧开的，只要它足够快速且效率高，烧开水就是一个隐藏的功能。但是我们并不知道水什么时候到达沸点，因此通知我们就是一个明显的功能。而水壶有好看与不好看之分，这可以归类到装饰性功能。
第三步就是努力思考或找寻隐藏功能背后的逻辑，看看是否仍然有隐藏的功能没有考虑到，并再次完善功能列表。在此阶段，暂时不考虑成本的因素，也不考虑是否能实现或者是否被人接受，先让所有的愿望处于开放的状态，不遗漏任何一个功能点，最后我们才归纳功能列表，并综合考虑做哪些以及怎么做。
02 属性
属性是客户希望的特征，通常是形容词或者副词。两种产品可能正好有相同的功能，但是它们的属性可以让它们成为完全不同的产品。一辆劳斯莱斯与福特车的功能或多或少非常相似，但是却有着非常非常多不同的属性。
在设计过程的早期阶段，引导“利益相关者”进行头脑风暴以产生属性的愿望列表。像功能列表一样，属性列表并不是为了在此时做出任何限制，不用考虑如何才能满足一个属性，也不会由于属性之间的冲突产生问题。
以一款产品为例，代表属性的词汇主要有：用户界面友好、利润丰厚、可制造、好卖、可靠、安全、清洁、容易打包、容易使用、连续运行、防水、耗电少、散热好、安全、自适应……。
列出所有属性后，将每个属性分配给合适的功能或功能组，然后进行分类，分为需要和忽略两种，去掉尽可能多的对于客户没有实质性价值的属性。
03 约束条件
假定我们正在设计一个系统，有人说：“数据传输速率必须很高。”
若数据传输速率是每秒1200比特，能够满足约束吗？对于一些人来说，每秒1200比特就是“高速”，然而对另外一些人来说就是“低速”。一个更好的描述应该是：“数据传输速率必须高于每秒6百万比特。”那可能不是正确的约束，但是至少不会对答案还有什么疑问。这样的约束最好是作为争论的起点而不是项目的终点。
还有比如设备上用的螺纹，如果用上约束-采用标准螺纹，那么这种标准螺纹的要求既可以减少成本，也更加容易与供应商交流。当然，我们也可以去探索约束的边界，用非标准螺纹，或许会在某些地方产生某些利益，但是不用考虑每一个部件的螺纹标准会使我们将注意力集中在其他设计问题上，就有可能产生更好的设计方案。
约束做得比较好的一个代表是乐高玩具，即便以前没玩过，也能很快就把它组装起来。因为它的轮子只能装在前叉上，手臂只能装在小人的躯干上，每个部件的接口都不一样，可以执行的操作就那么几种，多尝试几次，我们就能把玩具组装好。
04 偏好
偏好是附加在属性上的一种愿望，但却是可选择的条件。任何一个满足了所有约束条件的最终解决方案都是可以接受的，但其中某些可接受的解决方案也许更符合某些人的胃口。偏好这个概念使得设计者把那些可接受的方案进行比较，并从中选出较好的。
偏好一般来自于用户，而不是来自于设计者。所以偏好也需要量化。举一个例子：比如“信息展示的适应性”如果作为一个偏好，我们可以这样来量化：在人群中随机抽选候选人，通过至少两种感官渠道从系统获取信息，将能够收到所有信息的人的比例作为量化指标。
偏好是当所有的功能-属性-约束都满足之后才开始发挥作用，它指明解决方案空间中的哪些解决方案是更可取的。一般可以按照一定的步骤进行：
制定一个偏好的范围很广的列表
量化偏好，以便设计者确切地知道如何衡量做得好还是差
尽量将约束缩减为偏好，方便设计者有更广阔的解决方案空间
可以开发价值图，用于帮助解决约束和偏好之间的混淆问题
05 期望
每一位有经验的设计者都知道，失望和满意的差别不在于交付的成果怎样，而在于交付的成果与期望的匹配程度如何。
之所以需要考虑期望，是因为我们大部分人都是“非理性的”，接受事物的程度也不同。现实中符合逻辑的，正确的事物并不都能满足使用者的要求。所以如果事先诚实地表达限制问题，客户会更加容易接受产品和系统。相反，当用户在成为事实后才发现限制会有被欺骗的感觉。
可以遵循一个简单的顺序来提出并记录期望和限制：
从有代表性的用户处获得专门的期望列表
处理列表，理解并产生每条期望
通过协商将期望限制到一个合理的水平，为系统将来的修改留下公开的机会，但是坚决地去掉任何不能合理地期望得到的东西
设置一条限制时，确信记下限制的来源，因为今天的限制就可能是明天的机会
06 总结
在日常的产品设计过程中，我们可能习惯直奔主题，但通过“功能—属性—约束条件—偏好—期望”这一系列步骤，需求的含混性得到了比较好的控制。
王尔德曾说：我整个上午都在推敲我的一首诗，最后去掉了一个逗号。而在下午，我又把逗号放了回去。
探索需求类似于这个过程，我们通过一些列手段和工具，目的是避免犯错，以及做一个完整的工作。