27
MAR
2017
如何简单描述用户的需求
by 痞客邦 UX
如果要在三分钟内，甚至一分钟内快速让一群主管们理解「用户是谁」，你会怎么做？在项目开发过程中，有时候我们需要非常简单扼要地说明用户的需求与轮廓给利害关系人（Stakeholders）知道，例如 PM（产品经理或 Product Manager）在项目初期时，需要跟管理阶层说明这个产品是为了满足哪一种用户的需求，以便于评估在商业上的策略调整、技术限制下的可行作法与影响，这时候用户的需求就需要被描述的简短清楚。
等一下，不是有人物志（Persona）吗？而且也有做过用户经验地图（User Experience Map），为何不拿来作为沟通的工具呢？当然这些工具非常完整，也具有专业说服力，如果是在一个 workshop 的场合中，有一小时以上的时间可以运用，人物志跟用户经验地图都可以提供深度的了解，并让大家形成更完整的共识。但是如果 PM 在一个演示文稿场合，必须在三分钟内让各部门的主管们对用户的轮廓有个概念，那么带他们认识一个叫做 Jimmy 的人物或是打开一个需要 zoom in 的庞大历程地图并不容易带来好的效果与事后记忆。
所以，有什么简易方法？
用户需求架构
如上图，用户需求的架构分成四个项目，是谁、行为、目的、问题。假设我们要描述一个「找美食餐厅」的用户需求，就会以这四个项目分别带出简单的文本描述：
用户是谁
描述这个产品的用户轮廓，可以带入性别、年龄区间、职业、刻板印象（例如轻熟女甜点控），如果可以的话，用量化的数据来帮助说明用户轮廓。
用户有什么行为
行为模式着重在描述用户平常有的行为、习惯。在这个例子中，会描述女性外食上班族在「外食」这个命题下有什么既存的行为模式，尽量在两句话之内讲完，当然这些行为的描述都应该要根据真实的用户访谈数据而来，而不是凭空想像或是用自身经验来推敲，如果是既有产品且有做过 Persona，可以把其中的内容精简后放进来。
用户有什么目的
「目的」也是围绕在命题（找美食）上的，也就是回答一个问题：「这种用户为什么要找美食，为了什么目的？」，通常是要回答更高层次的问题，为了满足用户心理层面的什么需求，安全感、自尊、社交认同等等。产品的情感面设计或是想要满足的较高层次需求应该是要朝着用户的这个「目的」推进。这个项目能让利害关系人较容易联想到产品的愿景，另一方面行销人员也能从「目的」去发想产品在行销时可以说故事的方向，例如强调这个产品是能更方便有效地让大家开心聚餐。
在用户研究的数据收集与分析过程，「目的」往往需要在访谈的后半段或是访谈结束后，用户在充分放松的状态下，问出他们心中最真实诚恳的想法。有时候并不是那么容易做到，如果得到稍微「低层次」一点的答案也没关系，例如「想跟朋友们开心聚餐」可能只有「想跟朋友们聚餐」的程度，仍然可以算是有效的「目的」。
另外如果 PM 有 User Stories 的话，也可以从句型中「As a …., I want to …., So that …...」的 So That 那段来设置为「目的」。
用户有什么问题
「问题」指的就是用户的痛点（Pain Points），是我们通过用户访谈归纳而来的重要痛点，同时也是产品要解决的最主要问题。这里的「问题」若能通过量化的数字说明问题的严重程度或规模会更具体。
到目前为止四个用户需求的架构应该可以在三分钟内快速让人理解，并且可以通过一页的演示文稿来呈现：
当你说明到这时，你的利害关系人应该对用户以及用户痛点有一个大致的理解。这时候可能会开始讨论产品要做的方向，也就是该如何解决我们定义出来的「问题」，你也许会需要更深入的说明「问题」是什么，背后有什么原因。
五个 WHY
如果只从前面的字面上来看，这个「问题」的解决方案可能会被认为是「那么就帮用户推荐几间精选餐厅，减少他们阅读时间吧」，或是「帮用户做出文章的摘要，节省做选择的时间」。但是这些解决方案未必有触及到问题的本质，在事前我们可以用一直反复追问WHY 来分析问题的本质，例如：
如果我们能够呈现给利害关系人这个分析过程，就能让大家比较清楚的了解，用户最终想要解决的问题在于想要做出最好的决策（选出最好的餐厅），而「最好」这个标准，即使是同一个人也会因不同情境而做出不同选择，产品能够做的是提供「充分信息」来帮助用户做出最好决策，而这些充分信息中，需要被强调的应该是餐厅的优缺点，并且一定要是可以被信任的信息。
另外在沟通设计风格时，也比较能理解为什么这个产品要营造成快乐温馨的聚会气氛（为了要呼应「想要有一次美好的聚餐回忆」）。
修改成适合你的版本
除了用在与利害关系人的沟通上，这个用户需求演示文稿页也可以放在每一个设计提案演示文稿开头或是每次迭代计划会议的开场。用两页演示文稿描述出用户需求看起来结构简单，但是要花的时间、做的研究其实也少不到哪去。再次强调，这些内容都需要实际的研究访谈数据支撑，在还没做用户研究之前，可以暂时用我们（项目团队成员们）目前的假设代入，并注明这是稍后需要通过用户研究来确认跟调整的。
不管简单快速的介绍或是完整深度的工具，都是为了协助每个人创建同理心，并了解现象的本质。所以在实际运用时，并非一定要遵守这个架构不可，只要能增加沟通的效率，根据每次现况做修改也是很合理的，比如说加上产品情境照或是人物志的用户头像等等，希望大家能够演化出一个适合自己的版本。
作者：Jeff
推荐其他 UX 实验室文章：
