阶梯法访谈怎么问？从功能偏好追到它真正重要的原因

协作工具改版，几个岗位都提出要版本记录。设计师准备加一个历史列表，但有人想恢复误删内容，有人想对照修改，也有人只是需要确认交接用的是哪份。功能名字相同，设计要支持的结果却不同。

阶梯法（Laddering）从具体属性出发，在一对一交流中追问它带来什么结果、结果为什么重要，逐步了解个人价值。它适合用来深挖一项功能或服务特点，不要求每场访谈都一路问到某个宏大的词。

“版本记录”先要说成一件具体事情

假设一家企业更新协作资料工具。研究者想了解版本能力应支持恢复、对照还是交接，就从近期事件进入：“最近一次你需要查看旧版是什么时候？”

参与者说的版本记录，可能是修改历史，也可能是最新版本的确认标记。研究者要先问当时在哪一步、需要看到什么。自己的产品定义不能直接套进对方回答。

等属性含义清楚后，再问“有了它，你会少做什么”“如果没有，哪一步会受影响”“那次后来怎样处理”。这些问题让人解释功能与工作之间的联系，比一开场问“为什么它让你安心”更中性。

属性是具体能力，结果是它帮助完成或避免的事情，价值是这个结果对个人的意义。层次需要通过讲述建立，研究者不能看到“喜欢自动保存”，就替对方写上“追求安全感”。

向深处问，也要允许停下来

在这个假设示例中，一位参与者可能描述：能对照改动，就不用逐个询问；少了核验，交接时更有把握。另一位可能说：能恢复内容，自己更新时就不怕误删。这两条都是关系演示，不能写成实际用户结论。

当结果已经清楚，可以问“这对你为什么重要”“它让你更容易做到什么”。用上一句里的具体内容追问，交流会更自然。反复只问“为什么”，容易听起来像责问。

好处与代价一起了解。自动通知能减少遗漏，也会打扰。若只追问正面意义，团队最后可能得到一条过于顺滑的偏好链，漏掉用户想控制频率的需要。

参与者开始重复、答不出、不想继续，或者话题离任务越来越远，就停下来或回到事件。有人只想少做一次重复操作，已经足以说明结果，无需逼他回答更深的价值。

阶梯法不是心理诊断，也不应要求披露无关私人经历。深入程度由相关性和参与者舒适度决定，而非提纲预设的层数。

关系图保留多条路，才便于设计

记录者需要保存属性含义、发生事件、参与者说明与研究推断。一项属性可能通向不同结果，同一种价值也可能由多种功能支持，不必把图画成所有人相同的一条梯子。

前三层必须有本人说明，第四层明确标为研究者提出的待验证方向。不要将分析补写成用户原话，也不要给所有回答套上预设动机标签。

用亲和图寻找共同关系时，把不同路径与反例留下。功能被多人提出，不说明它对每个人重要的原因相同，也不能证明某个价值普遍存在。

涉及个人意义，一对一交流通常更便于理解差异；多人讨论中形成的说法，要留意是否来自附和。关系还可与任务观察相互核对，自述不直接等于行为证据。

从意义返回功能，才知道该改哪一处

若团队要支持交接时的把握，可以提出最新版本标记、改动对照、责任状态与恢复入口。然后分别检查这些能力解决什么，不能把四项都当成关系图自动推导的必做需求。

请目标用户用原型确认最新版本、查看修改和交接资料，观察哪里仍需询问同事。语言表达也可单独测试：参与者是否理解“已确认”，是否把它误认成“已经收到”。

如果将价值用于品牌或服务文案，应确认产品确实有对应能力。访谈提到安心，不证明某句广告更有说服力，也不支持把无法提供的结果写成承诺。

成功标志是主要关系都能回到本人解释与事件，团队知道每条线索支持哪种设计判断，也保留停止位置和待确认事项。交付事件摘要、关系图、反例与测试问题，比一组抽象价值词更有用。

版本记录该怎么做，最终要回答它帮助谁完成什么。58UI设计工作室可通过UI/UX设计处理版本与交接支持，并在企业官网设计开发、品牌视觉设计中，让服务表达与实际能力一致。

可查看设计服务与作品，或联系58UI说明想深入理解的一项功能。

相关服务