采购负责人已经看过产品页，也下载了资料。销售以为可以谈报价了，对方却说还要等工程同事确认。又过了一阵，项目没再推进。此时把联系按钮放大，未必能解决问题。
案例研究适合追问这样的具体过程。选定一次事件，找回当时的页面、文件和工作记录，再听不同参与者怎样解释，才能知道决策在哪一处停下。它关心过程中的关系，包括不顺利的部分；作品集里的成功案例通常有另一种展示目的。
沿着一份资料，看它经过了谁
以下是一个假设场景。一家设备企业要改版官网，采购负责人从参数页下载资料，转给工程人员。工程人员想确认设备能否接入现有系统，文件里没有写清。销售补了说明，审批人员又问维护怎样安排。几轮确认以后，采购暂停了。
团队很容易把这件事概括成“官网资料不完整”。但工程人员缺的兼容性说明、审批人员缺的维护安排，未必应放在同一个文件里。还有一种可能：资料已经够用，只是企业内部暂时没有做出采购决定。
我们更愿意把这些解释一起留在研究桌面上。否则，报告会证明团队原本就想做的改版，却没有解释这次采购为何停住。
这次可以把研究范围定为“下载资料到内部审批暂停”。邀请采购、工程和审批角色分别回忆各自收到什么、做了什么，收集允许使用的材料。一个人讲完全过程很方便，但他未必知道另一个人当时在等什么。
时间线要接得上，原因也要经得住追问
整理材料时，把每次交接写到时间线上。采购何时下载，工程何时提出问题，销售何时发了补充说明，审批后来又需要什么。记忆有冲突，就回查当时版本和时间，不急着替故事补齐。
网页今天已经更新，不能用今天的内容解释此前的选择。研究也需要保留当时的页面或文件，否则一句“这个信息明明有”，很可能是在比较两个版本。
| 要追问的节点 | 先找哪些材料 | 还需要问谁 |
|---|---|---|
| 下载后转给工程 | 当时网页、下载文件 | 采购为何选这份资料 |
| 工程要求补充 | 提问记录、补充说明 | 工程缺什么才无法继续 |
| 审批后来暂停 | 审批要求、事件时间线 | 暂停与资料、预算或计划的关系 |
访谈可以从一个动作问起：“你把文件转发以后，对方先问了什么？”接着追问：“收到补充说明后，哪项问题解决了？还在等什么？”这样的问法比“是不是官网不好用”更容易得到具体过程。
如果用户说找不到安装要求，先请他说明怎样找过。信息可能没有，也可能藏在他不认识的栏目里，或者下载后无法方便地转发。三个原因对应三种改法，不能都写成“增加内容”。
涉及邮件、审批文件和内部沟通，要取得必要授权，只保留本次问题需要的内容。人名、客户身份和商业敏感资料应脱敏；无法使用的记录就注明缺失，不靠推测补写。
从一次采购，得到怎样的设计决定
假设材料显示，工程人员每次都要另外确认兼容条件，那么候选方案可以是增加工程资料入口，或在参数文件中提示适用条件。如果审批者拿到材料仍不了解维护责任，就需要另一份便于内部讨论的说明。
这些方向还需要检查。让相关角色用原型或资料完成原来的任务，看他们是否能判断适用条件、是否仍须向销售反复追问。一次采购事件帮助你提出问题，不足以证明所有客户都有同样需求。
材料多时，可用亲和图整理跨角色的相似说法。但分组之后仍要回到各自事件：两个角色都说“信息不够”，缺的可能完全不同。
成功标志：没有参与研究的同事，也能沿着时间线找到每条建议的来由，说明哪个问题已被材料支持、哪个仍待确认，并据此安排一项具体的原型检查。
报告可以很短。保留事件起止、参与角色、关键交接、相互冲突的解释和建议依据，比铺满所有访谈内容更有用。如果只剩一人的回忆，就交付探索线索，不写成完整因果结论。
先弄清暂停发生在哪里，再决定改哪里
官网之外的采购安排、内部审批和服务交付，也会影响是否继续联系。案例研究把这些因素放到同一过程里，帮助企业看见：哪些能通过页面和资料改善，哪些需要业务团队接手。
58UI做企业官网设计开发、UI/UX、品牌视觉与响应式适配，也提供体验诊断和改版。遇到“看了、下载了，却没继续”的问题，可以从设计服务了解我们能介入的部分，或带着已有资料联系58UI，一起确定值得深挖的那段过程。
相关服务
