UCD:巧谈需求与功能

前言：一直有在梳理自己的知识结构，也靠这些所谓经验做了几年行业培训，今年是从业的第十一年，我觉得差不多是时候把这些最初来自同行、互联网和书籍的知识再还给行业，我会把所有所得分章节逐渐整理发出，希望能对行业尽一份绵薄之力，同时也作为一种仪式，好让自己重新出发。

上回说到UCD的全貌和第一环节“分析研究”，补充一个问题：“凭什么你说的用户就是目标用户？”如果被这么问到，你可以回答，哥推导出来的。怎么推导呢？过程分成“假设”“验证”“形成”三步。其实跟我们写论文一样的，一般我们会先通过前期研究假设出一个结论或者模型，然后我们就通过各种调研各种论证，最终验证假设的成立，假设就变成结论。用研也一样，先通过分析研究，假设我们的用户是哪类或哪几类人，然后针对性地进行研究，在研究过程中，可能会修正假设，可能分拆出更多类用户，也可能合并几类用户，最终得出我们的结论。所以我们认定的目标用户不是拍脑袋拍出来的，是推导出来的。

 

好了，分析研究的结果是得到需求，接下来我们需要把需求结构化并排排坐。

 

 

1 什么是用户需求

排排坐之前，先得把需求描述好。什么是需求呢？我把需求分两类，商业/技术方提出的需求及用户的需求，当然这两者有时候是交叉的，而且最终表达为用户需求，比如业务方说要做虚拟货币发红包，既能给企业带来现金收入又能满足用户玩、融洽关系的需求。需求可以用一句话来表达：

在什么场景下，用户通过产品做什么事情。

比如：

在关灯的房间（场景），用户（什么人）用阅读软件（产品）阅读（做什么）。

在接完朋友来电后（场景），用户（什么人）通过通话列表（产品）存储联系人信息（做什么）。

在寻找怎么到某目的地时（场景），用户（什么人）通过地图（产品）搜索最优路线（做什么）。

1.2 场景

这里有一个关键词很重要：场景。

场景不仅指物理环境，比如在车上、飞机上、教室里，还指任务场景，比如下午肚子饿的时候、被蚊子咬到的时候、购物时填单的时候，更细一点，考虑产品载体和协作工具。

基于场景的需求（及后续研发的功能）才能站住脚，甚至迎来爆发。比如大家熟悉的微信红包，有多少人是因为“过年”这个场景，玩上红包、绑上银行卡的？绑上银行卡后发现又有更多消费场景迎面而来…

 

设计离不开场景。任何产品都是一种物质存在，要使其有意义，就应该置其于恰当的社会环境中，而且这种环境与其他工具或人密不可分。

 

大家看这张mp3播放器的广告图，3个演员围绕一部机器很hi，这种事情可能发生吗？没人会这么hi吧…这是广告的世界，广告的世界是完美的。再比如说苹果的广告，苹果产品特写一出来，背景都是纯白的，现实生活中，你用苹果产品时背景都是白的？做设计可不能像做广告，产品所在的场景可不都是光鲜亮丽。桌面产品还好，周遭环境相对稳定，移动产品就指不定了，可能需要考虑位置、网速、光线、噪音、单双手、横竖屏等等。举个栗子，如果我们做一个地图导航，用户可能边走边看屏幕，就需要考虑户外光线过强导致屏幕暗淡，适当加大亮度和对比度，还需要考虑用户走路时要看红绿灯、不要撞到电线杆，也就是注意力的分散，所以数据不要呈现的过多，还需要考虑到用户会通过周围建筑道路特点来判断自己位置，所以界面上需要有跟现实一致的标识。

用迅雷举几个例子，

 

下载时遭遇龟速，让你开通会员，也是基于场景，开通会员的入口这种打开方式才是正确的。

还有下载完，给你提供的打开文件和文件夹按钮。

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

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

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

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

1.2 假的需求

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

 

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

 

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

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

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

2 表达需求

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

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

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

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

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

剧本的形式除了文字，还有更多，只要你能想到，能把故事说出来，就可以，比如拍个视频，比如照片书，比如连环画。以下是我参与过的项目的剧本：

3 确定功能、数据

需求确定了，表达了，那接下来就要决定用什么来满足需求了，也就是把抽象的需求变成具体的功能和数据，功能和数据就是实打实的看得到摸得着的产品内容。

 

 

把之前超市显示屏的例子继续走下去，这时就是：

3.1 什么是功能和数据

功能是对数据在界面上的操作表达，比如一些工具、或者操作入口。

数据是产品中的一些可阅读对象，比如相片、邮件、客户记录。对象之间可能有关系，比如相册包含照片。

数据对象本身也能作为功能入口，比如头像是一个可阅读数据，同时点击它还能跳转到个人主页。

作者：Danis

公众号：Danis体验设计（ID:DanisUX）