杨朋翰 · 行为研究 / 人因工程 / AI 工作流

所有问题都是技术性问题。

我负责 Noldus 中国的咨询与业务拓展,把研究用于产品决策,也探索 AI 怎样减少专业工作中的重复劳动。对我来说,“技术”是把难事拆清楚、做出办法,再检验它是否有用。

把主张放进真实工作

换一个问题, 才能找到下一步。

三个案例分别展示:怎样组织产品决策的证据、把验证提前,以及在功能完成前模拟交互。每篇说明我的职责、工作过程与结果边界。

查看全部案例与实验
  1. 证据的组织方式
    让判断有出处254GB 研究记录,按任务和观察整理,形成六类共 86 个可追溯问题。连线只表达整理关系,不表示数据分布。研究记录254 GB访谈 · 测试 · 行为保留原始上下文问题索引86个问题归入六类任务情境观察片段原始出处每个判断,都能沿线回看
    1. 原始记录保留任务与情境
    2. 任务与观察区分动作和解释
    3. 可追溯问题每个判断都有出处

    记录 → 任务与观察 → 可追溯问题方法示意

    DELIVERED · 已交付2018金融科技 · 用户研究金融 App:把现场记录变成产品能改的问题从“整理 254GB 记录”到“找到支持产品改动的证据”:按任务片段梳理行为,形成 86 个可追溯的问题。交付与进展交付 86 个问题,按六类组织,并连接任务、观察记录与优先级。
  2. 验证进入设计的时机
    把检查放进过程洞察进入设计,设计与观察之间反复迭代,之后再安排确认。图中的轨道表示反馈关系,不表示轮次、时长或项目进度。设计 ⇄ 观察仍然可以修改洞察确认反馈回到设计,之后再检查
    1. 洞察明确要检查的假设
    2. 设计 ⇄ 观察反馈回到仍可修改的设计
    3. 确认再检查是否回答了问题

    洞察 → 设计与观察反复迭代 → 确认方法示意

    持续开展的咨询方向2019—现在医疗器械 · 人因工程医疗器械:把测试提前到设计还能改的时候从“完成测试”到“在还能改时检验设计”:把关键任务、可能的使用错误和验证时机放回开发过程。交付与进展参与建立研究方案、记录模板与评价流程,相关服务累计覆盖 25+ 家医疗器械企业及机构。
  3. 交互原型的前台与后台
    先体验,再实现前台保留用户体验的发起、执行与结束;后台由人员模拟尚未实现的响应。先验证交互能否被理解,再确定开发方式。前台 / 用户体验后台 / 人工模拟发起 · 执行 · 结束Wizard-of-Oz
    1. 前台 · 用户体验发起、执行任务、结束
    2. 后台 · 人工模拟按规则模拟尚未完成的响应
    3. 观察与判断先检验理解,再讨论开发

    前台观察理解 · 后台模拟响应方法示意

    DELIVERED · 已交付2019智能硬件 · 人机交互服务机器人:功能没开发,先验证人会不会用从“等功能完成”到“先看人能否理解”:拆开互动阶段,用后台人工模拟关键响应,再讨论开发投入。交付与进展使用四阶段模型和后台模拟开展研究,并整理团队可复用的研究流程与记录方法。

元思维 / 我怎样检查问题本身

先检查题目, 再寻找解法。

先分开目标与方案,再把观察、解释和建议分开。用一次研究、一段模拟或一个工具原型,检查下一步是否值得做。完整方法页展开提问步骤、案例推演和工具选择。

查看完整工具箱阅读核心主张:我所说的“技术”是什么展开我的思路与工具

关于我

从理解人的行为, 到重构做事的条件。

心理学、四年教学和一线研究,让我习惯看人具体怎么做。一个人“不会用”,可能是入口难找、反馈不清,也可能是流程安排不对。我喜欢把这些条件拆开,再动手试着改变。如今组合 AI 工具,也是同一种思路。

了解我的经历和工作习惯

技术与思考

我为什么这样想, 又如何继续追问。

浏览技术与思考
  1. AI 系统与人机协作待验证的方法7 分钟阅读需要人一直照看的 Agent,究竟自动化了什么后台运行只是起点。把配置、监督、恢复和注意力中断纳入评价,才能判断自动化是否让使用者真正少操心。阅读这篇文章
  2. 行为、测量与解释观点与分析7 分钟阅读把行为编码成标签时,我们究竟保留了什么动作识别正确,解释仍可能错误。从一次伸手的不同含义出发,讨论编码体系、符号落地,以及行为分析应该保留的情境。阅读这篇文章
  3. 核心主张观点与分析8 分钟阅读所有问题都是技术性问题我说的技术,是拆解目标、约束与关系,重新组织现有条件,找到可执行、可检验的办法。这句话如何指导我做研究、用 AI,以及与人合作。阅读这篇文章