我们重点介绍了 Microsoft Clarity,它是一款由真正了解像 Switas 这样的公司所面临挑战的产品开发人员,以实际应用场景为导向打造的产品。诸如“愤怒点击”和 JavaScript 错误跟踪等功能,在识别用户痛点和技术问题方面发挥了至关重要的作用,从而能够进行有针对性的改进,直接提升用户体验和转化率。
持续探索是指在产品开发过程中与客户保持定期、持续的联系,而不是在产品交付前进行孤立的调研项目。详细阐述这一方法的特蕾莎·托雷斯描述了产品开发团队每周与客户进行多次接触,并将由此获得的洞察应用于后续决策。
反对项目式研究的理由很实际。分阶段进行的研究会生成一份报告,其结论在撰写之时或许具有参考价值,但之后会逐渐过时;而且,研究产生的理解主要掌握在研究人员手中,而非负责日常决策的团队手中。由于一项新研究的筹备需要数周时间,因此研究间隙的许多小决策都基于假设。而每周一次的节奏则改变了经济效益:周一提出的问题可以在几天内向客户提出,因此,证据的获取速度与决策速度同步。
坚持由产品三人组(通常是产品经理、设计师和工程师)亲自进行访谈至关重要,而非无关紧要。洞察力在交接过程中会损失大部分价值,因为那些细微差别、犹豫不决以及能够改变团队思维的出人意料的言论,往往难以在总结中保留下来。直接与客户沟通的团队能够培养共同的直觉,从而改进数百个原本无需研究即可做出的小决策。
该方法以结构化工件为支撑,主要体现在机会解决方案树上。机会解决方案树将预期结果与可能实现该结果的客户机会以及针对每个机会的解决方案和实验联系起来。其作用在于确保解决方案思路与已验证的问题紧密相关,并使决策背后的假设链清晰可见,从而避免团队积累大量功能想法却与任何客户需求或业务成果没有明确联系的常见模式。
障碍在于组织层面而非方法层面。每周招募参与者是一个后勤难题,除非通过产品内置提示、客户名单或常设小组等方式实现自动化,否则大多数团队都难以应对。面临交付压力的团队往往会优先削减访谈环节。而在客户数量少、级别高或只能通过销售关系联系到的企业中,每周进行访谈可能根本无法实现,在这种情况下,采用其他证据来源并放慢频率才是更现实的替代方案。
这种做法也改变了研究成果的记录方式,因为每周一次的更新频率产生的是连续不断的成果流,而非零散的报告。维护一个可搜索的访谈片段、观察记录以及由此产生的决策资料库变得必不可少,而非可有可无。否则,团队会积累一些无法证实的印象,并重复回答已经解答过的问题。将观察记录与其相关的机会进行标记,并将决策与其背后的证据关联起来,也使得在情况发生变化时能够重新审视之前的结论成为可能。而如果推理过程仅仅存在于参与访谈人员的记忆中,则很难做到这一点。
持续探索并不能取代更深入的研究,将其视为替代方案只会导致理解肤浅。基础研究、民族志研究和大规模定量研究能够解答每周例行对话无法解答的问题,而这两者作用的深度也各不相同。在实践中,成熟的 用户研究 该功能支持两者,既能定期开展深度工作,又能让团队保持日常沟通,而由此产生的证据则为优先级排序和路线图决策提供依据。 产品研究 育明在 产品工作室 设置。
我们重点介绍了 Microsoft Clarity,它是一款由真正了解像 Switas 这样的公司所面临挑战的产品开发人员,以实际应用场景为导向打造的产品。诸如“愤怒点击”和 JavaScript 错误跟踪等功能,在识别用户痛点和技术问题方面发挥了至关重要的作用,从而能够进行有针对性的改进,直接提升用户体验和转化率。