腾讯专业干货!一份系统全面的敏捷设计用研指南精选.pdfVIP

腾讯专业干货 ！一份系统全面的敏捷设计用研指南 “以用户为中心”的体验设计理念 深入人心。但在实际工作中 ，作为用户研究员 ，时常会碰 到这样的情况 ，“这个调研需求比较急 ，这周就要进入开发了 ，必须这周之前出结果” ，或是 这样的反馈 ，“设计和用研好像结合得不够紧密”。摸索下来 ，对用户研究本身 ，我归结到一 个问题 ：设计用研还不够敏捷。今天我们就来聊聊这个问题 ，以及尝试的解决办法。 为何提出敏捷设计用研 ？ 这里所谈的敏捷用研 ，主要是设计用研。什么是设计用研 ？设计用研是我根据用研工作与业务迭代 周期的独立关系 ，以及我的实际工作情况和经历来粗略划分归类出来的。在此之前 ，先来说说目前 互联网企业普遍采用的敏捷开发流程。 敏捷 （A gile ）开发的理念源起于2001年 ，是一种以人为本、迭代、循序渐进的开发方法。敏捷开 发流程包含了一系列小的迭代周期[1] （图1 ）。每个迭代周期3~4个星期 ，甚至更短。它改变了之 前传统的瀑布流开发相对僵化、低效的协作方式。从一般的流程上看 ，用研环节并不在既定的敏捷 迭代业务流程中 ，并没有预留固定的周期和时间给到用研。 pic- 1 图1. 包含了一系列小的迭代周期的敏捷开发流程示意图 而设计用研一般就是发生在业务迭代周期内的。通常是 ，在产品经理和设计师针对要做的产品需求 和功能点进行需求分析和设计讨论的过程中 ，会凸显一些问题和争议 ，还有一些拿捏不定的设计细 节问题。例如 ，这个新功能在产品中的主入口该如何设计 ，功能流程上应该如何设计 ？设计用研即 是需要在这个产品需求进入业务迭代的快速滚动之前 ，通过调研和分析 ，一起解决这些问题和争议 ，因而与迭代周期密切相关。 相比 ，用户研究工作的其他两类对迭代周期的依赖性相对较弱。一类是基础用研 ，是基于某些通用 性的基础问题进行的研究 ，或是针对某类产品的战略和方向性研究 ，是在产品迭代之前的探索 ，重 要而不紧急 ，本身就独立于业务流程和产品周期之外。例如 ，现今时常被提及的90后人群研究 ，或 是为某产品探索契合的生活服务行业研究。另一类是产品用研 ，是针对 上线的产品的实际使用和 反馈层面进行调研 ，用研结果可能会作为评估产品的指标之一 ，同时也会探索产品后续的需求方向 。通常也有时间和空间给到用研 ，可以跨越一定的迭代周期进行。例如 ，常见的满意度调研。当然 ，用户研究工作不只是以上三类 ，这里只是对设计用研做个简单界定。 传统的用研从立项规划、招募用户、执行调研、分析数据到撰写报告 ，整个过程需要一段较长的 时间 ，而敏捷开发流程则对缩短设计用研的时间长度提出了要求 ，因而看起来似乎存在一定的矛盾 。洽洽因为这样的矛盾 ，在实际合作中 ，设计用研的需求可能更少地被提出。设计用研的敏捷之道 ，就是基于上述问题而进行的尝试和探索 ，目标是缩短用研的周期时长 ，而同时又能将用户导向的 需求和反馈有效融于产品设计 ，并按期落实在迭代流程中。 怎么实践敏捷设计用研 ？ 1.对工作模式的思考 缩短用研的周期时长 ，首先应该是尽早发现和提出产品设计中的问题。由于用研不在开发流程中 ， 用研的工作模式 ，特别是新手用研 ，常常是乙方模式——产品经理或设计师提出用研需求 ，用研根 据提出的需求进行规划和调研。这种模式下 ，通常是产品经理和设计师经过几轮讨论 ，发现遇到的 问题无法通过 有资料和现有经验分析清楚 ，需要用研的参与和介入。用研需求提出的时间点可能 到产品设计中期 ，这样在既定产品需求开发计划下 ，用研时间就显得很紧迫。用研中途参与 ，对 需求背景的熟悉和了解 ，以及对需求本身的深入判断 ，可能有一定的限制。 敏捷设计用研 ，需要用研化被动为主动 ，将乙方工作模式转变为参与式工作模式 （图2 ）。在心态上 ，最先需要转变。对待产品的态度 ，并不是“我是支持这个产品的用研工作” ，而是“这个产品是我做 的产品” ；工作的动力 ，并不是“为了完成用研项目” ，而是“为了做出更好的产品” ；角色定位 ，并 不是“我只是用户研究员” ，而是“用户研究和体验设计工作”。 参与式模式一方面是用研全过程参与产品研发过程 ，与产品经理、设计师、开发等团队成员进行密 切的沟通协作。如此 ，用研可以从讨论中主动发现产品和团队所面临的问题和困惑 ，而非被告知 ， 因而可以尽早展开研究和分析。参与式模式另一方面是团队成员也参与到设计用研中来 ，包括前期 规划、调研执行、数据分析和结果讨论。用研需求来源于产品业务 ，用研结果落地于产品业务 ，用 研过程该是开