如何在产品设计过程中描述一个完整需求场景.pdfVIP

如何在产品设计过程中描述一个完整需 求场景 【编者按】本文作者朱晨，供职腾讯CDC。对于交互设计师而言，描述应 用场景是在对产品需求进行分析时最简单直接的阐述方式。 在文中，作者将应用场景描述为需求场景，这种讲法更加形象。因为对场 景的描述就是一个分析用户需求的过程，解读这个过程可以更容易的对用户需 求做出分解并从中找到吸引用户的关键。 需求场景是一种更接地气的分析和描述用户需求的方法(个人偏爱“需求场 景”这个词)。它应该拥有这样的结构： “在某某时间(when)，某某地点(where)，周围出现了某些事物时(with what)，特定类型的用户(who)萌发了某种欲望(desire)，会想到通过某种手段 (method)来满足欲望。” 需求场景的意义 传统的软件开发流程中，产品经理/产品策划首先会提供一份功能列表。这 种功能列表所使用的描述方式往往是以程序为导向的，比如“商品列表支持按 照价格从低到高排序”。 这种描述方式的弊端是： 产品经理得出该结论往往是因为竞争对手拥有了该功能，而非分析了用户 的真实需求。 合作伙伴(交互设计师/视觉设计师/开发工程师)不能直接体会到该功能是 为了帮助用户实现什么目标的，也就不知道这个功能的价值，究竟能给真实的 生活带来何种变化。 而以需求场景的方式描述需求，就能够有效避免这些弊端： 产品经理知道这个新开发的功能是为了帮助用户解决什么问题 交互设计师可以从中获知这种需求场景的细节：“发生频率，需求强度， 用户有什么样的能力和辅助工具” 其他合作伙伴更容易了解到这个功能的价值，更能够及时表达意见，否决 不靠谱的功能，并对有价值的功能产生更强烈的共鸣，干劲儿十足。 如何判断一个使用(需求)场景有价值? 依照以前所学习的心理学知识，当用户具有某种需求时，会尝试使用各种 手段来满足它。当环境中不存在转为为之设计的解决方案时，用户就会用各种 尽可能能找到的东西来凑活(你们知道飞机杯、充气娃娃之类的东东对吧)。 当实在是找不到任何解决方案时，用户就只能憋着了。当很长时间里都无 法发现解决方案时，用户就会绝望(学名叫习得性无助)，并压抑尝试的行为(没 有网购前，正在上班的你无论多么强烈地想给老婆买结婚纪念日的礼物，都不 会去开网页)。但是，一旦把这种解决方案拿到用户面前，请他试用，他在体验 到成功的喜悦后就会对它爱不释手(想想在12306 上订票成功时的心情吧，虽然 确实烂)。 所以，就诞生了两种衡量需求场景靠谱程度的方法： 调查现阶段用户是否在凑活着使用某种产品，心里在骂娘，但还忍着用(又 想到了12306 对吧)。 用最低廉的成本做出一个基本能用的解决方案，请目标用户试用，询问体 验。 使用(需求)场景的描述方法和各部分必要性 前面提到，需求场景应该如此描述： “在某某时间(when)，某某地点(where)，周围出现了某些事物时(with what)，特定类型的用户(who)萌发了某种欲望(desire)，会想到通过某种手段 (method)来满足欲望。” 各部分信息存在的意义如下： when，where，with what 这几点信息其实统一地描述了需求产生的环境。从这些环境信息可以分析 出诱发需求的条件和需求产生时的环境条件。 例如，“在候机时，候机厅里，用户看到手机电量过低时，会想要充 电”。 基于此，可以分析出，用户是在电量低的信息刺激下，想要充电。当时他 所在的位置是候机厅，一个充满电器，但是没有插座开发给乘客的地方。 who 需求场景还需要分析是什么样类型的人有这种需求，他有什么样的能力可 以潜在地帮他实现目标。 继续前面的例子，坐飞机的手机用户都可能会有这种需求，因为他们下了 飞机一般都会联系家人报平安，联系别人来接机，等等。坐飞机的这些人一般 都比较有钱，会带着现金或者信用卡。 desire 对需求的描述有一些注意事项，那就是某种需求背后往往还有更深层次某 种需求，它只是这种需求的解决方案。 比如想给手机充电是一种需求。但背后的需求可能是打发无聊、给家人保 平安、看目的地城市地图、联系旅行社等等。给手机充电只是这些背后需求用 户自己能想到的一种解决方案