那些总是让你满意的功能，究竟是如何被设计出来的？

反面例子，是冗长的百度地图启动页，我只想静静地导航。

场景是归纳需求不可缺少的前提，需求蕴含在场景里。

截止到目前为止的步骤，我们用一个例子来串起来看看。假设我们现在要做一块超市购物车上的屏幕，用来帮用户更顺利愉悦地购物（idea），那我们代入流程可以归纳出以下表格（的一行），一行就是一个需求：

Rose是人物角色，她的身份是个阿姨？学生？她关注的是什么类型商品？对价格敏感吗？她平常去超市会经历的场景有逛货架？排队？停车？在这些场景中，需求是找促销商品？买特定物品？知道购物车里的商品价格？排队的等待时长？回答这些问题，我们就能大致判断出接下来设计的方向了。

1.2 假的需求

假的需求不是异想天开的需求，也不是看上去没啥用的需求，还是用超市购物车屏幕的例子说明，“能用屏幕听歌”跟购物关系不是很大，但它是个需求，只不过最后可能优先级相对较低罢了（当然也可以作为亮点啊，哈哈哈，边逛边听歌多好）。假的需求是指我们做用户研究的时候，用户给我们的“解决方案”。有个经典到烂大街的例子，福特说问用户要什么，用户会告诉他，他们想要更快的马，而不是汽车。这里的“更快的马”，就是用户提供出来的解决方案，其实用户真正的需求是什么呢？“更快”。看以下例子，能说出哪些是真哪些是假吗？

灰色的就是真的，黑色的是假的，绿色的是真正的需求：

可以看出来，用户往往会帮我们想好解决方案，或者用解决方案来表达他们的需求。解决方案是我们来设计给用户的，一个需求可以有n种解决方案，所以我们只需要知道需求就好，那是不是用户给的方案都丢掉？也不是。我们从这些方案去反推挖掘需求，也可以把方案都暂存起来，等到后面设计的时候，没准就是我们的重要灵感来源呢。

以下是用户帮我们现在的产品提的解决方案：

要找到看过的内容，他们会说“给个搜索”，当然我们最后可能给个“最近浏览”，受不了颜色，他们会要求“自主定义”，当然我们最后可能给他们换个颜色但不是自定义，全部听用户的解决方案，会显得团队不负责任和慵懒。

知道了需求是什么，接下来就要过滤它们，因为此时我们的需求是散的，要去掉没用的，并且给剩下的排优先级，确定哪些是核心场景的核心需求。这里我没有特别的方法，就是从用户、从自己特长、从市场环境等综合考虑，大家坐下来讨论决定。总之，100条需求最后就剩下了10条：

在把需求过滤好，列成需求列表时，往往我们会用一个方法把最终的这些需求表达出来。这个方法叫“情境场景剧本（scenario）”，这个概念来自《交互设计精髓 about Face》，也有人叫“故事板（storyboard）”，但我把故事板用做后面的概念表达的工具，后面再提 。

情境场景剧本的概念：随时间推移，捕捉产品、环境和用户之间的理想交互方式，用来定义、表达需求。让需求的呈现更丰满生动，被（通常是汇报对象）更好地理解。

通常我们会抓用户的一天或某个时间段在典型场景的经历，把需求融进写成故事。这里留意是“理想交互方式”，所以，故事除了一些润色的情节让故事生动外，更重要更大权重的内容应该是关于需求的，而且是“理想”的，这也许使得一天看上去总会提到我们的产品，但我觉得是可以允许的，只要不离奇。再一个需要留意的是除了用来表达需求，还用来“定义需求”，需求不是在前面已经确定了吗？其实在编写剧本的时候，也是再一次梳理需求的机会，当你发现某个需求在故事里总是显得别扭的时候，就要重新考虑一下这个需求啦。

以下是从《交互设计精髓》截取出来的例子，黄框框起来的部分就是藏在故事里的需求：

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!