新平台还没开始，功能清单已经有了账号、消息、工单和仪表盘。看着完整，团队却不知道客户在哪种工作中需要它，也不清楚现有电话和纸单为何没有被替代。
探索性研究先理解陌生领域里的人、任务、环境与工具，再形成设计问题。平台是可能的回应，不是研究必须证明的答案。
它多用于早期；新角色、新渠道或新情境出现时，也值得重新探索。计划可以调整，但调整应有理由，不能无限收集。
先把不知道的事情摆出来
假设设备企业想让客户问题线上化，可以先区分三种信息：已经确认的业务情况、团队猜测、尚未了解的问题。
“公司希望统一受理”是业务目标；“客户不喜欢打电话”可能只是猜测；“客户什么时候必须找现场人员”则是未知。三者混在一起，就容易把希望做的功能写成用户需要。
优先研究会影响范围的未知：请求从哪里来，谁补资料，谁判断优先级，哪些事情需要现场确认。不必把行业知识全看完，才开始设计。
电话为什么还在用，可能比有没有工单更重要
观察和访谈应围绕实际请求，在授权下了解它怎样开始、怎样交接、怎样结束。电话可能用于澄清情况、确认责任或处理异常；这些工作不因为媒介线下就没有价值。
有人说想要通知，还需要追问何时、通知什么、没有通知会怎样，以及现在如何应对。愿望可以提示问题，但还没有决定必须开发什么。
看似无关的纸单可能保存客户说法，也可能提醒下一班人员。通过物件分析了解它的用途，再判断支持、替代还是保留。这里分析的是实际工具与资料，不是整理UI组件库。
用未知选择方法，别先挑一套热闹活动
| 想了解什么 | 可采用的方向 | 需要防止的误读 |
|---|---|---|
| 工作实际怎样发生 | 情境观察与访查 | 把标准流程当作所有实际流程 |
| 工具承担什么工作 | 物件与文件分析 | 认定线下工具都应删除 |
| 参与者怎样理解经历 | 具体事件访谈 | 把自述当完整行为 |
| 时间怎样影响协作 | 跨时间记录 | 一次到访代表全部节奏 |
| 内容怎样被理解 | 分类和理解任务 | 内部栏目等于用户分类 |
方法可以互补，每项活动都说明要回答哪个未知。AEIOU框架有助于检查人与环境的覆盖，但框架填满并不意味着任务已被理解。
选择相关角色、地点和任务差异，留意现有、互补或竞争工具。只访问熟悉人员、只看顺利流程，都可能让探索结果偏向团队原本的方案。
意外发现可以改变重点，例如请求其实在部门交接后才丢失。但要记录调整理由与新范围，不让一个线索带着研究无限扩展。
汇总材料时，留下不符合主要故事的部分
用亲和图归纳主题，保留来源索引，再检查不同角色和例外。“所有人需要统一状态”若主要来自客服，现场工程人员的判断仍需核对。
问题可以写为：“请求交接后，发起人无法确认接手情况。”这比“需要智能工单”更有用，因为它允许团队比较共享摘要、交接确认或其他响应。
早期交付不必是功能清单。任务范围、角色差异、情境限制、关键问题与待研究项，同样能防止后续方案建立在错误理解上。
怎样知道已经可以进入下一轮
不必等所有未知消失。检查核心任务与角色是否清楚，关键风险是否发现，主要方向是否有材料支持进入原型。
若新材料不断出现完全不同的工作方式，可能需要调整范围；若同一问题已经重复出现，却仍无法决定改法，下一步可能是聚焦验证，而非继续广泛采访。
成功标志：团队能说明接下来探索或制作什么、依据在哪里、哪些条件先由业务确认，以及哪些问题暂不承诺开发。探索暂时结束，意味着能带着清楚的问题继续设计，不意味着需求永久确定。
探索发现，别替尚未使用的方案背书
探索帮助提出问题和方向，评估再检查候选方案。新原型失败时，也不必立刻否定全部早期理解；可能是回应方式不合适，需要回看问题与设计之间的连接。
保留范围、方法、参与覆盖、证据、主题、反例和下一步。资料有用，不表示全部都应公开，个人经历和敏感业务仍需受控使用。
58UI可以在官网或数字产品方向未明时梳理任务与内容，再开展UI/UX、企业官网设计开发、品牌视觉、响应式适配及改版诊断。可了解设计服务，或带着业务目标和未知问题联系58UI，先确定研究范围。
相关服务
