摘要:有些概念代表着反直觉的闪光点,有些则在你说出来的时候显而易见。以用户为中心意味着倾听使用你产品或服务的人的声音,并将他们的痛点、需求和愿望融入你的计划中。这听起来绝对显而易见,然而大多数组织并没有这样做。
直接将反馈转化为功能特性会毁掉你的软件产品。反馈的价值在于深入理解你的用户,而不在于愿望清单。
译自 What Organizations Get Wrong With User-Centricity,作者 Steve Fenton。
有些概念代表着反直觉的闪光点,有些则在你说出来的时候显而易见。以用户为中心意味着倾听使用你产品或服务的人的声音,并将他们的痛点、需求和愿望融入你的计划中。这听起来绝对显而易见,然而大多数组织并没有这样做。
通常,组织认为他们对问题领域已经足够了解,无需与用户交谈。他们可以节省棘手对话的时间,并专注于交付功能。任何因使用食品配送、预订旅行或提交费用等任务的应用程序而感到沮丧的人,都遇到过这种情况的结果。
并不是这些应用程序无法工作;只是软件能够满足其需求的用户群体仅限于那些与开发人员相似的人。
然而,走出你的圈子以融入用户的需求可能会导致另一个错误,这就是我们今天要讨论的内容。
无论您是制造实体产品、开发软件产品还是设计服务,以用户为中心的理念都可能很熟悉。这个术语已经有 50 年的历史了,它是由唐纳德·诺曼推广的,他的 1988 年出版的著作“The Design of Everyday Things”曾是畅销书。
以用户为中心描述了您在多大程度上利用与用户的对话来深入了解他们的领域。这使您可以将用户的需求和愿望融入您的开发路线图中。
以用户为中心的团队:
了解用户想要完成什么根据他们为用户提供的价值来评估成功通过与用户交谈不断发现机会根据他们的学习成果更新他们的计划您可以使用非正式流程(例如非结构化访谈和动手可用性测试)来收集反馈,或者您可以使用更结构化的技术,例如以用户为中心的設計。甚至还有更适合现代软件交付的方法,例如持续发现。至关重要的第一步是与真实用户进行对话。
DORA 的《DevOps 现状加速报告》 发现,专注于用户的软件团队的工作满意度更高,倦怠感更低。该报告还发现,以用户为中心的组织的绩效比那些自认为比客户更了解情况的组织高 40%。
至关重要的是,如果您倾听用户的意见,您更有可能发现改进领域,而如果您的路线图仅由组织内部人员的意见驱动,这些领域将是不可见的。
以用户为中心使您可以开发更少的功能,这些功能对用户价值和满意度产生更大的影响。
许多团队通过产品内窗口小部件或电子邮件调查收集反馈。随着净推荐值跟踪一段时间内的观点可能很有用,但这并不能帮助您更好地了解用户。要获得关于他们问题和愿望的高价值知识,您需要与他们交谈,最好是进行一些结构化的对话。
重要的是要有一定的结构,以避免浪费用户的时间,并确保您收集反馈的方式不会使回应产生偏差。正如 Teresa Torres 在她的著作“Continuous Discovery Habits”中解释的那样,询问某人“你如何决定预订哪个酒店房间?”会引发过多的想象,因为人们倾向于根据他们理想的自我形象来提供答案。相反,询问“告诉我你上次预订酒店房间的情况”会将答案建立在生活经验的基础上,并获得更现实的答案。
一旦你养成了经常与用户交谈的习惯,你就可以开始了解他们。这使您能够更好地发现机会,通过解决痛点和满足他们的需求来取悦他们。
这将我们引向用户反馈中最常见的绊脚石:将听到的一切都视为新的功能请求。
每当你与用户交谈时,你都会得到功能创意。用户要么直接要求某个功能,要么他们会描述一个机会,这会给你一个功能创意。直接将反馈转化为功能会导致问题,并会毁掉你的软件产品。
在与用户交谈的过程中,如果用户描述了他们想要的功能,您可以通过询问他们拥有该功能对他们意味着什么或它能解决什么问题来发现潜在的机会。您并非在寻找功能创意,因为这些创意无助于您了解用户。您想要发现的是驱动每个请求的潜在需求。
反馈的输出是对用户的共同而深刻的理解,而不是愿望清单。
所有反馈都应传输给团队,以便每个人都能更深入地了解用户。这意味着将对话翻译成有用的摘要,而不是分享通话录音或记录。目标是最大限度地从这些对话中学习。
可以对反馈进行汇总和映射,以便您获得一些能够将来自许多用户的反馈联系起来,转化为可操作的路线图实验的东西。有了这些,您可以根据您的学习成果进行迭代,并测试您在决定如何应对机会时所做的假设。
如果每次对话的结果都是向积压工作中添加请求,您很快就会不堪重负。您还会添加可能很少使用的功能。当某个功能过于特定于单个用户的需求时,它的采用率就会很低。
对一个用户的请求说“是”,可能会增加所有其他用户必须忽略不适用的菜单选项或界面元素的复杂性,因此,如果这意味着您的产品更容易理解和使用,那么拒绝一个机会有时是正确的答案。
您的工作不是响应从以用户为中心的方法中出现的每个机会,而是确定哪些机会与您自己为创建的软件设定的目标相符。
每当采用率成为软件产品的一个因素时,诱惑就是赢得每一笔交易,并让尽可能多的人使用该软件。大多数开发人员都经历过这种情况,即来自销售团队的一系列需求,他们承诺为客户提供他们需要的一切,以换取合同上的签名。
当您唯一的反馈来源是与客户联系的其他团队时,您就失去了发现潜在机会的能力。您只能通过直接与用户交谈来深入了解用户。这还可以让您控制对话结果的叙述,即更好地了解他们的需求,而不是收集需求列表。
优秀的软件产品是有主见的。人们不仅仅购买软件产品;他们还在购买您在该问题领域的专业知识。这就是人们购买监控工具而不是将信息流式传输到数据库的原因。关于存储格式、数据保留、异常检测、警报方法和可视化的观点是产品的重要组成部分。
这并不意味着您的客户必须遵守您所有的观点。您可以创建逃生舱,让他们根据自己的情况调整软件的各个方面,在这些方面,他们的需求与其他组织和行业的需要不同。对于这些异常具体的案例,逃生舱比添加利基功能更好的解决方案,因此考虑人们如何调整他们对产品的使用,可能是对利基机会说不的重要因素。
以用户为中心并非要给予用户他们想要的一切。而是要深入了解他们的挑战、痛点、需求和愿望。这部分知识,而不是单个请求,激发了新的功能创意。
这使您能够在具有重大影响的领域进行创新,并创建用户会发现非常有价值的功能。
来源:璐璐课堂