工作人员在收货终端前停了几秒，研究者写下“按钮难找”。可他也许正在看纸单，等同事确认，或等设备响应。只知道发生了停顿，还不知道为什么，直接改按钮可能处理错了地方。
用户观察（Observation）系统记录人、物品、环境、事件与互动，帮助团队理解任务怎样完成。它要把可见动作、当时条件、参与者自述和研究解释分开，再为关键原因补证据。
先把收货看成一段工作
假设一家企业改版仓储终端，团队怀疑收货步骤太多。研究范围从工作人员拿到货物开始，到记录完成或异常转交结束，既看终端，也看核对单据、扫描和协作。
只数点击，会漏掉核对；只看总耗时，又可能混进货物差异和设备等待。研究开始前，确认现场权限、安全位置与记录范围，去除不必要的单号、人员身份和客户资料。
如果对工作不熟悉，先开放观察，留意没想到的活动。若已知道要比较求助、返回或失败状态，可以试用结构化字段。两种方式能配合，先探索，再试记和调整。
字段总要留“其他”“无法确认”和环境变化。结构化不保证无偏，位置、时段和事件定义仍会影响记录。没有栏目的事情，也不能因此不记。
一次尝试从哪里开始，到哪里结束
正式记录前，团队定义事件单位。示例中的一次确认尝试，从开始录入到成功、取消或转异常结束；返回页面是其中一个动作，不自动成为新样本。
同时说明何时算求助、什么是技术等待。请两位记录者试记同一小段，再比对分歧。若一个把看纸单记成等待、另一个记成核对，就回看定义，而非先争谁的数量准确。
试记还检查能否跟上活动速度，位置能否看见屏幕和物品关系，研究者是否挡道。位置调整或必须介入时记录下来，无法看清的内容标缺失，不能事后补造。
把“他不信任系统”拆回可见动作
记录“拿起纸单查看后返回终端”，比记录“不信任系统”更稳。前者描述过程，后者只是一个可能原因，可以放在待核实栏。
| 记录层次 | 示例方向 | 要保留的区别 |
|---|---|---|
| 可见动作 | 查看纸单后返回终端 | 观察者看到的活动 |
| 界面状态 | 等待提示仍在显示 | 当时系统条件 |
| 物品与环境 | 扫描器放得较远 | 可能影响操作的因素 |
| 参与者说明 | 说自己在确认规格 | 本人的自述 |
| 初步解释 | 并列规格可能有帮助 | 研究者待测试的判断 |
相关的异常要留，也要记录顺利完成的任务。只收失败片段，会让团队看不到哪些条件下流程正常。
研究者参加了任务，就说明角色和影响。自己的体验可以成为线索，不能冒充普通旁观，也无法代表其他岗位或熟练程度。
比较之前，先看条件是不是同一类
把相近任务放在一起比较，记录与问题有关的货物类型、班次、设备和熟练度。复杂收货耗时更长，不说明界面必然更差；屏幕相同，工作内容也可能不同。
同一人反复尝试、不同人各做一次、同一任务跨班次交接，分析单位不同。报告任何计数时说明单位、分母、重复与缺失。小范围观察不能直接写成人群发生率。
示例中如果停顿主要出现在需额外核对的货物，研究者就应补问核对什么；如果不同货物都在提交后等待，则需要检查系统反馈和响应。现象相似，处理方向可能相反。
原因留待合适时机核实
活动后，在适当时机问“刚才拿起纸单时，你要确认什么”，避免提示“是不是按钮难找”。将说明对应到事件，保留无法确认或不同的解释。
如果确实需要同时核对规格，可提出并列信息原型，让目标用户再走收货任务；若是设备等待，先查系统状态和反馈，而不是凭猜测减少步骤。
成功标志是同事能从设计判断回到一条事件链，分辨观察、自述与推断，也知道尚缺什么证据。发现问题数量多，不代表研究更好。
整理成果可包含任务过程、关键事件、条件差异、证据缺口和验证问题。用少量清楚的过程说明障碍怎样产生，比只汇报总次数更便于设计和开发选择动作。
AEIOU框架适合检查活动、环境、互动、工具和使用者是否遗漏；空间位置是重点时，可结合行为地图。按问题选工具即可，无需全部叠加。
收货变慢的原因，应在动作和条件中核实。58UI设计工作室可通过UI/UX设计与体验诊断处理终端和后台流程，并在企业官网设计开发、品牌视觉设计中结合任务与信息表达。
可通过设计服务了解范围，或联系58UI说明当前观察到的停顿及其上下文。
相关服务
