系统全面的敏捷设用研指南.docx

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