“以用户为中心”的体验设计理念已深入人心。但在实际工作中，作为用户研究员，时常会碰到这样的情况，“这个调研需求比较急，这周就要进入开发了，必须这周之前出结果”，或是这样的反馈，“设计和用研好像结合得不够紧密”。摸索下来，对用户研究本身，我归结到一个问题：设计用研还不够敏捷。今天我们就来聊聊这个问题，以及尝试的解决办法。

为何提出敏捷设计用研？

这里所谈的敏捷用研，主要是设计用研。什么是设计用研？设计用研是我根据用研工作与业务迭代周期的独立关系，以及我的实际工作情况和经历来粗略划分归类出来的。在此之前，先来说说目前互联网企业普遍采用的敏捷开发流程。

敏捷（Agile）开发的理念源起于2001年，是一种以人为本、迭代、循序渐进的开发方法。敏捷开发流程包含了一系列小的迭代周期[1]（图1）。每个迭代周期3~4个星期，甚至更短。它改变了之前传统的瀑布流开发相对僵化、低效的协作方式。从一般的流程上看，用研环节并不在既定的敏捷迭代业务流程中，并没有预留固定的周期和时间给到用研。

图1. 包含了一系列小的迭代周期的敏捷开发流程示意图

而设计用研一般就是发生在业务迭代周期内的。通常是，在产品经理和设计师针对要做的产品需求和功能点进行需求分析和设计讨论的过程中，会凸显一些问题和争议，还有一些拿捏不定的设计细节问题。例如，这个新功能在产品中的主入口该如何设计，功能流程上应该如何设计？设计用研即是需要在这个产品需求进入业务迭代的快速滚动之前，通过调研和分析，一起解决这些问题和争议，因而与迭代周期密切相关。

相比，用户研究工作的其他两类对迭代周期的依赖性相对较弱。一类是基础用研，是基于某些通用性的基础问题进行的研究，或是针对某类产品的战略和方向性研究，是在产品迭代之前的探索，重要而不紧急，本身就独立于业务流程和产品周期之外。例如，现今时常被提及的90后人群研究，或是为某产品探索契合的生活服务行业研究。另一类是产品用研，是针对已上线的产品的实际使用和反馈层面进行调研，用研结果可能会作为评估产品的指标之一，同时也会探索产品后续的需求方向。通常也有时间和空间给到用研，可以跨越一定的迭代周期进行。例如，常见的满意度调研。当然，用户研究工作不只是以上三类，这里只是对设计用研做个简单界定。

传统的用研从立项规划、招募用户、执行调研、分析数据到撰写报告，整个过程需要一段较长的时间，而敏捷开发流程则对缩短设计用研的时间长度提出了要求，因而看起来似乎存在一定的矛盾。洽洽因为这样的矛盾，在实际合作中，设计用研的需求可能更少地被提出。设计用研的敏捷之道，就是基于上述问题而进行的尝试和探索，目标是缩短用研的周期时长，而同时又能将用户导向的需求和反馈有效融于产品设计，并按期落实在迭代流程中。

怎么实践敏捷设计用研？

1.对工作模式的思考

缩短用研的周期时长，首先应该是尽早发现和提出产品设计中的问题。由于用研不在开发流程中，用研的工作模式，特别是新手用研，常常是乙方模式——产品经理或设计师提出用研需求，用研根据提出的需求进行规划和调研。这种模式下，通常是产品经理和设计师经过几轮讨论，发现遇到的问题无法通过已有资料和现有经验分析清楚，需要用研的参与和介入。用研需求提出的时间点可能已到产品设计中期，这样在既定产品需求开发计划下，用研时间就显得很紧迫。用研中途参与，对需求背景的熟悉和了解，以及对需求本身的深入判断，可能有一定的限制。

敏捷设计用研，需要用研化被动为主动，将乙方工作模式转变为参与式工作模式（图2）。在心态上，最先需要转变。对待产品的态度，并不是“我是支持这个产品的用研工作”，而是“这个产品是我做的产品”；工作的动力，并不是“为了完成用研项目”，而是“为了做出更好的产品”；角色定位，并不是“我只是用户研究员”，而是“用户研究和体验设计工作”。

参与式模式一方面是用研全过程参与产品研发过程，与产品经理、设计师、开发等团队成员进行密切的沟通协作。如此，用研可以从讨论中主动发现产品和团队所面临的问题和困惑，而非被告知，因而可以尽早展开研究和分析。参与式模式另一方面是团队成员也参与到设计用研中来，包括前期规划、调研执行、数据分析和结果讨论。用研需求来源于产品业务，用研结果落地于产品业务，用研过程该是开放式和参与式的，相关实践经验下文具体讲。

图2. 用研工作模式之乙方模式 vs. 参与式模式

参与式模式，说起来简单，实践起来却需要花费大量的努力，还需要团队的支持和配合。实践敏捷设计用研，首先必须练就深厚的用研专业功力。为能够参与到产品研发全过程，与产品经理、设计师、开发等不同角色进行较好的沟通协作，还需要掌握用研本专业之外的知识和能力，包括产品能力、设计能力，甚至开发能力，需要不断补足和修行。

2.相应流程机制

敏捷设计用研必须形成有效的机制。设计用研主要是围绕如何设计这个产品或功能而开展的，因此，核心是将想法和概念通过设计和原型呈现给用户，得到快速反馈，检验与用户行为模式、心智模型是否相匹配 ，再进行修正优化（图3）。对比敏捷开发流程，这其实是未付诸开发前的低成本的敏捷设计流程。在这样一个流程中，用研是组织和牵头的角色。

图3. 设计用研流程机制

灰度放量常常是敏捷开发流程中的一环，灰度用户调研也可以成为设计用研的一环。有些产品和功能，必须是结合线下使用场景和业务触发的，前面的概念设计用研阶段可能也难以发现一些实际使用情况下的问题。通过灰度发布和调研、灰度数据分析，可以了解用户真实使用产品后的反馈和评价。

对于每个迭代都要进行的用研，如版本发布前的可用性测试，可以进行流程化建设，形成机制融入项目流程中，成为其中的一个固定环节。以版本发布前的可用性测试流程化建设为例，可以进行流程化的有：执行时间点和周期、可用性测试操作任务的制定、测试用户招募、问题发现与记录、问题跟进和解决等。这些一旦流程化，可以调动团队一起来进行分工协作，而不单单只是用户研究员的事。

3. 实践经验和思考

基于上述工作模式和流程机制，在实践中，要实现敏捷，用户研究员首先要具备过硬的专业能力和高效的执行力，才能在设计用研的每个环节快起来、游刃有余。

设计用研以定性用研为主。敏捷设计用研，我总结有3个准则：响应变化高于遵循计划，有效沟通高于完美报告，以人驱动而非文档驱动。接下来就用研的不同阶段（图4），说说我的一些敏捷用研经验。

图4. 用研阶段和流程

立项规划

参与式模式下的设计用研，由用研或团队一起提出问题和用研需求，已然省去了反复沟通需求背景和目标的过程，从而缩短了立项规划的时间。

“工欲善其事，必先利其器”，在规划准备阶段，还需有合适的工具。在上述设计用研流程机制中，原型工具是比较重要的一环。

就可交互的移动原型工具，如果是在较为前期的设计方案阶段，主要用于呈现页面结构和关系，以了解用户对产品或功能设计的整体认知和反馈，目前我们常用的是 Prott。在 Prott 中，上传产品页面，设置页面间的点击热区和连接，辅以设置页面切换动画，就可以得到快速原型。

如果是到设计中后期阶段，主要用于呈现细节功能的操作和体验，以了解用户对实际设计方案的反馈，目前我们常用的是 Pixate。 Pixate 需要对不同细节模块设定交互和动画，使用上相比 Prott 要复杂一些、耗时一些，因此我们主要用于细节功能模块的完整呈现。

招募用户

通常我们会邀请第三方中介来帮助我们招募，招募用户时间会受到第三方中介对需求理解度、资源范围等因素影响，因而时间上不完全受控。所以找到一家资质好、稳定的、可以长期合作的第三方很重要。

其他可行的替代办法，一种是建立自己的产品用户库，有需求时可以直接从中筛选和抽取进行自主招募。也可以根据具体产品情况，在社交平台上用产品官方名义进行调研招募。例如，一次针对在华外籍用户的调研，我们在 Facebook 进行了自主招募，利用 Facebook Ad 发布招募信息，并从报名问卷中筛选出有效用户，在短时间内就完成了用户招募。对于一些简单方案的测试，我们还可以采用就近用户测试。所谓就近，就是在我们身边的用户，根据具体用研需求和情况，可以预调研周围同事朋友，可以邀请公司内部用户，可以拦访工作园区的伙伴。

另外，在敏捷设计用研中，招募也可以成为调研的一环，既招募用户，同时又先进行某些问题的摸底。招募时不明确给出要求，而是设计招募问卷以报名筛选的方式，在招募问卷中加入需要预先进行摸底了解的问题。招募先行，摸底后可调整调研。

研究执行

在调研执行过程中，可以邀请团队成员，包括产品经理、设计师、开发一同来访问和观察用户。一场调研完毕就可以第一时间讨论发现的问题和对策，甚至可以产生新想法、新方案，而微调后续调研计划和方案。在敏捷设计用研执行阶段，比较鼓励及时有效沟通和响应动态变化，而非按最初计划一成不变。

另外，在方法运用上，结合实际情况，有可能的话，可以多采用图谱的方式，将研究过程可视化，便于团队后续一起进行分析。

数据分析

定量调研中，我们可以将常用的数据分析模块进行公式化或编程代码化，这样下次统计分析可以继续使用，减少分析时间。

针对定性调研，建议可以将用研记录上墙分析（图5）。通常详细的用户调研记录是调研的中间环节，用户研究员一般是自己分析，然后将分析结果在最后的报告中呈现，调研记录最多作为邮件附件，但很少有人会去详看它。将用研记录贴上墙后，可邀请团队多角色一起来进行分析。上墙后的调研记录铺陈总览、横纵对比，相应重点可以用彩笔进行标注，多角色讨论分析的思路可以用便利贴记录贴在一旁。这样分析就打破了用研独自分析的困境，而且快捷有效。

图5. 将用研记录上墙分析

结果推动

参与式模式下的设计用研，并不等到写好完整报告再来和团队进行汇报和沟通，再推动落地，而是在用研的每个阶段都会和相关人员密切沟通和讨论。敏捷设计用研过程是开放的，除了一起参与调研、一起讨论分析，每日进度、结果沟通和快速输出也必不可少。在用研中间阶段就可以开始推动部分结论的落地。

在时间有限的情况下，有效的沟通远比一份完美的报告来的更重要。报告可以有多个版本，根据时效性要求，分别输出快速小结版报告及陈述研究分析和结果的完整版报告，用于汇报和演示时，可以调整成演示版报告。

为快速有效地沟通结果并推动落地，需要依靠的是人的驱动，而非文档。在和团队沟通研究结果的场所，基于之前的上墙分析，可以选在进行研究分析的房间里，通常我会选择在体验室内进行分析和沟通。这样的好处在于，可以直接用快速小结版报告结合贴出来的记录和分析进行沟通，缩短研究产出到汇报的时间，即使是之前没有参与调研和分析的团队成员，也能再次进入研究情境，回顾研究分析过程，更好地理解研究结果。正是这样的紧密合作和沟通，在参与式工作模式下，用研结果也能更好地落实。

4. 注意点

设计用研的敏捷之道，不只是为了快而快，而是快速有效地解决产品需求和设计问题，打造好的体验。在一味追求快的情况下，往往会发生疏漏、缺少全局思考。敏捷设计用研需要追本溯源、众览全局、向后铺垫。

较多的设计用研需求提出是要去了解下这个新功能的概念设计反馈，此时用研应该跳出设计本身，回溯到考察用户场景、行为模式和心智模型来去考量现有的产品设计。

不仅要关注当前设计的这个新功能，还要跳出这个新功能，思考新功能和已有功能之间的相互影响，如何联动。如何吸引用户来用这个新功能，功能的使用背后是否需要改变用户固有的行为习惯，如何引导这种变化。除产品功能设计和体验本身外，运营、市场、技术等其他方面还可以做些什么。这些都可以纳入研究分析的框架中。

在功能设计阶段，用研还需要进行数据埋点规划和建设，作为迭代需求联合产品经理一起提出，为功能上线后的数据分析和用研作铺垫。

结语

设计用研的敏捷之道，是从用户研究员的角色出发，针对项目迭代内的产品设计，为达成促进团队内合作、增强用户导向理念在产品中落实、提升产品用户体验这个目标而进行的实践。换之，站在产品经理、设计师等其他不同角色的角度，如何践行上述这个目标，也是值得进行探讨和思考的话题。（小杨梅原创）

“以用户为中心”的体验设计理念已深入人心。但在实际工作中，作为用户研究员，时常会碰到这样的情况，“这个调研需求比较急，这周就要进入开发了，必须这周之前出结果”，或是这样的反馈，“设计和用研好像结合得不够紧密”。摸索下来，对用户研究本身，我归结到一个问题：设计用研还不够敏捷。今天我们就来聊聊这个问题，以及尝试的解决办法。

为何提出敏捷设计用研？

这里所谈的敏捷用研，主要是设计用研。什么是设计用研？设计用研是我根据用研工作与业务迭代周期的独立关系，以及我的实际工作情况和经历来粗略划分归类出来的。在此之前，先来说说目前互联网企业普遍采用的敏捷开发流程。

敏捷（Agile）开发的理念源起于2001年，是一种以人为本、迭代、循序渐进的开发方法。敏捷开发流程包含了一系列小的迭代周期[1]（图1）。每个迭代周期3~4个星期，甚至更短。它改变了之前传统的瀑布流开发相对僵化、低效的协作方式。从一般的流程上看，用研环节并不在既定的敏捷迭代业务流程中，并没有预留固定的周期和时间给到用研。

图1. 包含了一系列小的迭代周期的敏捷开发流程示意图

而设计用研一般就是发生在业务迭代周期内的。通常是，在产品经理和设计师针对要做的产品需求和功能点进行需求分析和设计讨论的过程中，会凸显一些问题和争议，还有一些拿捏不定的设计细节问题。例如，这个新功能在产品中的主入口该如何设计，功能流程上应该如何设计？设计用研即是需要在这个产品需求进入业务迭代的快速滚动之前，通过调研和分析，一起解决这些问题和争议，因而与迭代周期密切相关。

相比，用户研究工作的其他两类对迭代周期的依赖性相对较弱。一类是基础用研，是基于某些通用性的基础问题进行的研究，或是针对某类产品的战略和方向性研究，是在产品迭代之前的探索，重要而不紧急，本身就独立于业务流程和产品周期之外。例如，现今时常被提及的90后人群研究，或是为某产品探索契合的生活服务行业研究。另一类是产品用研，是针对已上线的产品的实际使用和反馈层面进行调研，用研结果可能会作为评估产品的指标之一，同时也会探索产品后续的需求方向。通常也有时间和空间给到用研，可以跨越一定的迭代周期进行。例如，常见的满意度调研。当然，用户研究工作不只是以上三类，这里只是对设计用研做个简单界定。

传统的用研从立项规划、招募用户、执行调研、分析数据到撰写报告，整个过程需要一段较长的时间，而敏捷开发流程则对缩短设计用研的时间长度提出了要求，因而看起来似乎存在一定的矛盾。洽洽因为这样的矛盾，在实际合作中，设计用研的需求可能更少地被提出。设计用研的敏捷之道，就是基于上述问题而进行的尝试和探索，目标是缩短用研的周期时长，而同时又能将用户导向的需求和反馈有效融于产品设计，并按期落实在迭代流程中。

怎么实践敏捷设计用研？

1.对工作模式的思考

缩短用研的周期时长，首先应该是尽早发现和提出产品设计中的问题。由于用研不在开发流程中，用研的工作模式，特别是新手用研，常常是乙方模式——产品经理或设计师提出用研需求，用研根据提出的需求进行规划和调研。这种模式下，通常是产品经理和设计师经过几轮讨论，发现遇到的问题无法通过已有资料和现有经验分析清楚，需要用研的参与和介入。用研需求提出的时间点可能已到产品设计中期，这样在既定产品需求开发计划下，用研时间就显得很紧迫。用研中途参与，对需求背景的熟悉和了解，以及对需求本身的深入判断，可能有一定的限制。

敏捷设计用研，需要用研化被动为主动，将乙方工作模式转变为参与式工作模式（图2）。在心态上，最先需要转变。对待产品的态度，并不是“我是支持这个产品的用研工作”，而是“这个产品是我做的产品”；工作的动力，并不是“为了完成用研项目”，而是“为了做出更好的产品”；角色定位，并不是“我只是用户研究员”，而是“用户研究和体验设计工作”。

参与式模式一方面是用研全过程参与产品研发过程，与产品经理、设计师、开发等团队成员进行密切的沟通协作。如此，用研可以从讨论中主动发现产品和团队所面临的问题和困惑，而非被告知，因而可以尽早展开研究和分析。参与式模式另一方面是团队成员也参与到设计用研中来，包括前期规划、调研执行、数据分析和结果讨论。用研需求来源于产品业务，用研结果落地于产品业务，用研过程该是开放式和参与式的，相关实践经验下文具体讲。

图2. 用研工作模式之乙方模式 vs. 参与式模式

参与式模式，说起来简单，实践起来却需要花费大量的努力，还需要团队的支持和配合。实践敏捷设计用研，首先必须练就深厚的用研专业功力。为能够参与到产品研发全过程，与产品经理、设计师、开发等不同角色进行较好的沟通协作，还需要掌握用研本专业之外的知识和能力，包括产品能力、设计能力，甚至开发能力，需要不断补足和修行。

2.相应流程机制

敏捷设计用研必须形成有效的机制。设计用研主要是围绕如何设计这个产品或功能而开展的，因此，核心是将想法和概念通过设计和原型呈现给用户，得到快速反馈，检验与用户行为模式、心智模型是否相匹配 ，再进行修正优化（图3）。对比敏捷开发流程，这其实是未付诸开发前的低成本的敏捷设计流程。在这样一个流程中，用研是组织和牵头的角色。

图3. 设计用研流程机制

灰度放量常常是敏捷开发流程中的一环，灰度用户调研也可以成为设计用研的一环。有些产品和功能，必须是结合线下使用场景和业务触发的，前面的概念设计用研阶段可能也难以发现一些实际使用情况下的问题。通过灰度发布和调研、灰度数据分析，可以了解用户真实使用产品后的反馈和评价。

对于每个迭代都要进行的用研，如版本发布前的可用性测试，可以进行流程化建设，形成机制融入项目流程中，成为其中的一个固定环节。以版本发布前的可用性测试流程化建设为例，可以进行流程化的有：执行时间点和周期、可用性测试操作任务的制定、测试用户招募、问题发现与记录、问题跟进和解决等。这些一旦流程化，可以调动团队一起来进行分工协作，而不单单只是用户研究员的事。

3. 实践经验和思考

基于上述工作模式和流程机制，在实践中，要实现敏捷，用户研究员首先要具备过硬的专业能力和高效的执行力，才能在设计用研的每个环节快起来、游刃有余。

设计用研以定性用研为主。敏捷设计用研，我总结有3个准则：响应变化高于遵循计划，有效沟通高于完美报告，以人驱动而非文档驱动。接下来就用研的不同阶段（图4），说说我的一些敏捷用研经验。

图4. 用研阶段和流程

立项规划

参与式模式下的设计用研，由用研或团队一起提出问题和用研需求，已然省去了反复沟通需求背景和目标的过程，从而缩短了立项规划的时间。

“工欲善其事，必先利其器”，在规划准备阶段，还需有合适的工具。在上述设计用研流程机制中，原型工具是比较重要的一环。

就可交互的移动原型工具，如果是在较为前期的设计方案阶段，主要用于呈现页面结构和关系，以了解用户对产品或功能设计的整体认知和反馈，目前我们常用的是 Prott。在 Prott 中，上传产品页面，设置页面间的点击热区和连接，辅以设置页面切换动画，就可以得到快速原型。

如果是到设计中后期阶段，主要用于呈现细节功能的操作和体验，以了解用户对实际设计方案的反馈，目前我们常用的是 Pixate。 Pixate 需要对不同细节模块设定交互和动画，使用上相比 Prott 要复杂一些、耗时一些，因此我们主要用于细节功能模块的完整呈现。

招募用户

通常我们会邀请第三方中介来帮助我们招募，招募用户时间会受到第三方中介对需求理解度、资源范围等因素影响，因而时间上不完全受控。所以找到一家资质好、稳定的、可以长期合作的第三方很重要。

其他可行的替代办法，一种是建立自己的产品用户库，有需求时可以直接从中筛选和抽取进行自主招募。也可以根据具体产品情况，在社交平台上用产品官方名义进行调研招募。例如，一次针对在华外籍用户的调研，我们在 Facebook 进行了自主招募，利用 Facebook Ad 发布招募信息，并从报名问卷中筛选出有效用户，在短时间内就完成了用户招募。对于一些简单方案的测试，我们还可以采用就近用户测试。所谓就近，就是在我们身边的用户，根据具体用研需求和情况，可以预调研周围同事朋友，可以邀请公司内部用户，可以拦访工作园区的伙伴。

另外，在敏捷设计用研中，招募也可以成为调研的一环，既招募用户，同时又先进行某些问题的摸底。招募时不明确给出要求，而是设计招募问卷以报名筛选的方式，在招募问卷中加入需要预先进行摸底了解的问题。招募先行，摸底后可调整调研。

研究执行

在调研执行过程中，可以邀请团队成员，包括产品经理、设计师、开发一同来访问和观察用户。一场调研完毕就可以第一时间讨论发现的问题和对策，甚至可以产生新想法、新方案，而微调后续调研计划和方案。在敏捷设计用研执行阶段，比较鼓励及时有效沟通和响应动态变化，而非按最初计划一成不变。

另外，在方法运用上，结合实际情况，有可能的话，可以多采用图谱的方式，将研究过程可视化，便于团队后续一起进行分析。

数据分析

定量调研中，我们可以将常用的数据分析模块进行公式化或编程代码化，这样下次统计分析可以继续使用，减少分析时间。

针对定性调研，建议可以将用研记录上墙分析（图5）。通常详细的用户调研记录是调研的中间环节，用户研究员一般是自己分析，然后将分析结果在最后的报告中呈现，调研记录最多作为邮件附件，但很少有人会去详看它。将用研记录贴上墙后，可邀请团队多角色一起来进行分析。上墙后的调研记录铺陈总览、横纵对比，相应重点可以用彩笔进行标注，多角色讨论分析的思路可以用便利贴记录贴在一旁。这样分析就打破了用研独自分析的困境，而且快捷有效。

图5. 将用研记录上墙分析

结果推动

参与式模式下的设计用研，并不等到写好完整报告再来和团队进行汇报和沟通，再推动落地，而是在用研的每个阶段都会和相关人员密切沟通和讨论。敏捷设计用研过程是开放的，除了一起参与调研、一起讨论分析，每日进度、结果沟通和快速输出也必不可少。在用研中间阶段就可以开始推动部分结论的落地。

在时间有限的情况下，有效的沟通远比一份完美的报告来的更重要。报告可以有多个版本，根据时效性要求，分别输出快速小结版报告及陈述研究分析和结果的完整版报告，用于汇报和演示时，可以调整成演示版报告。

为快速有效地沟通结果并推动落地，需要依靠的是人的驱动，而非文档。在和团队沟通研究结果的场所，基于之前的上墙分析，可以选在进行研究分析的房间里，通常我会选择在体验室内进行分析和沟通。这样的好处在于，可以直接用快速小结版报告结合贴出来的记录和分析进行沟通，缩短研究产出到汇报的时间，即使是之前没有参与调研和分析的团队成员，也能再次进入研究情境，回顾研究分析过程，更好地理解研究结果。正是这样的紧密合作和沟通，在参与式工作模式下，用研结果也能更好地落实。

4. 注意点

设计用研的敏捷之道，不只是为了快而快，而是快速有效地解决产品需求和设计问题，打造好的体验。在一味追求快的情况下，往往会发生疏漏、缺少全局思考。敏捷设计用研需要追本溯源、众览全局、向后铺垫。

较多的设计用研需求提出是要去了解下这个新功能的概念设计反馈，此时用研应该跳出设计本身，回溯到考察用户场景、行为模式和心智模型来去考量现有的产品设计。

不仅要关注当前设计的这个新功能，还要跳出这个新功能，思考新功能和已有功能之间的相互影响，如何联动。如何吸引用户来用这个新功能，功能的使用背后是否需要改变用户固有的行为习惯，如何引导这种变化。除产品功能设计和体验本身外，运营、市场、技术等其他方面还可以做些什么。这些都可以纳入研究分析的框架中。

在功能设计阶段，用研还需要进行数据埋点规划和建设，作为迭代需求联合产品经理一起提出，为功能上线后的数据分析和用研作铺垫。

结语

设计用研的敏捷之道，是从用户研究员的角色出发，针对项目迭代内的产品设计，为达成促进团队内合作、增强用户导向理念在产品中落实、提升产品用户体验这个目标而进行的实践。换之，站在产品经理、设计师等其他不同角色的角度，如何践行上述这个目标，也是值得进行探讨和思考的话题。（小杨梅原创）