从用户的真实任务，走到有依据的设计判断。

01 / 先定性找问题，再定量看规模

用研：把「凭感觉」换成「有依据」

设计最怕的是凭感觉拍板：觉得哪里不好，就直接改哪里。用研（用户研究）做的事正好相反——在动手改之前，先弄清用户是谁、任务是什么、卡在哪里。我们的基本打法是先定性找问题，再定量看规模，两套手法各司其职：

定性研究 · 访谈与观察

样本不大，回答「为什么」——请用户重走真实任务，观察停顿、绕路、求助的时刻，听他们边做边想。用来发现问题和形成假设，不做统计推广。

定量研究 · 问卷与数据

样本更大，回答「有多少」——某个问题影响多少人、优先级怎么排。解释不了原因，所以用来验证规模。

小范围的改进，一轮定性就够了；牵动面大、需要排优先级时，再上定量验证。

Infra Design SystemInfra Design System（基础设施设计系统），简称 InfraD。由设计与前端共同建设维护，连接组件、业务模式、页面模板、使用指南与 Design Tokens，支持多业务主题及持续演进。 的官网就是一个完整示例。它已经投入使用好几年，经历过多个版本迭代；2025 年，我们发起了一轮系统的用户研究，想弄清前端、TPMTechnical Product Manager，技术产品经理：负责技术类产品的需求、推进与跨团队协调，与业务产品的产品经理不同。 和设计师到底怎样使用这些资产——从哪里开始、在哪里卡住。起点是一个常见的反馈：「不常用官网」。但接着问下去，原因可能不同：有人缺的是内容，有人找不到入口，有人早在别处完成了任务；它不该直接变成同一个改版需求。

定性访谈覆盖 12 位参与者：5 位前端、4 位设计师、3 位 TPM。我们没有让他们笼统评价官网，而是请每人回顾一个近期的真实需求，在官网和新版 Demo 上重走「查找—选择—配置」的完整路径；访谈中记录停顿、困惑和思考出声用研中的观察方法：请用户边操作边说出当下想法，记录真实思路，而不是事后回忆。的内容，也注意他们中途转向其他工具的时刻。

这些时刻比打分更有信息量。一位前端说，遇到信息不全的组件，他会直接跳去 Ant Design广泛使用的 React 组件体系；InfraD 的基础组件基于它统一，保留交互、调整颜色与圆角。 查；另一位说，Figma设计师使用的界面设计与协作工具：组件库、原型和设计交付都在其中进行。 里的文档版本混乱，不知道哪个组件库才是官方最新——两个人都不算「官网用得不好」，一个缺的是内容，一个缺的是「哪份才是对的」的确定性。我们还问过一个更尖锐的问题：有没有因为找不到某个功能，就误以为它不存在？「找不到」的代价从来不只多花几分钟，它可能让一个人对整套系统的信任打折。

定量侧用分角色问卷补充覆盖面。最终产出 15 类建议，拆成官网与 Figma 两类任务，分别记录优先级与研发依赖。每项建议都要说清依据：同样是「组件不好找」，可能是分类名称的问题，也可能是不知道该选哪一类——前者调整入口，后者补选型说明。找到一条反馈之后，不能直接跳到一个功能。

02 / 三件工具，一条标准

体验度量：把质量变成可衡量的标准

研究之外，团队还共建了一套体验度量，由三件工具组成，分别解决不同的问题：

度量模型 · 定标准

把「体验好坏」落到三个维度——有效性（能不能完成任务、达成目标）、易用度（好不好学、好不好用）、接受度（愿不愿意继续用）。参照两套国际标准指 ISO 9241-11（可用性的经典定义：效益、效率、满意度）和 ISO/IEC 25022（使用质量的度量框架）。我们用它校准体验度量的维度定义。对可用性的经典定义，结合 Infra 的产品体验维度（性能、达成、情感）与设计价值观（高效、自然、灵活、开放、智慧共生），落到具体指标。

设计自查表 · 设计师自查

进入评审前先对照清单：思考层看产品目标、用户需求和行业现状，构造层看信息结构、功能场景与主次任务；允许去掉不适用的细则。自查通过，才能进入评审。

质量评价规则 · 评审人打分

对每条细则按五级同意程度打分（从强烈反对到强烈同意），有效性与易用性下细分项各带权重。它评的是「合格」不是「好看」——拉高基准线，不是上限；关键流程的缺陷，不能被平均分抵消。

为什么需要这套东西：以前设计好坏「凭感觉」，问题说不清位置，讨论落不到同一套标准上，改进也没法衡量。把体验变成可衡量的数据之后，协作才有了共同语言。这三件工具由团队共建，我参与其中。

03 / 事实、方案与未决问题

Design Prephase：让材料能进入下一轮设计

需求在聊天里，业务规则在文档里，参考产品又是另一种做法——前期设计最怕的是材料散落、理解不一。我们建的 Design Prephase团队共建的前期设计实践：整理需求与来源，区分已确认事实、提出的方案与未决问题，形成下一轮设计输入。 先把需求整理成三类：已经确认的事实、提出来的方案、还没有答案的问题，再把确认后的对象、流程和状态组织成下一轮设计的输入。后来它被封装成了插件——插件只是形式，内容才是重点。它包含七项能力：

Requirements Organizer · 需求整理

从会议、聊天与转写材料提取设计信息，区分确定规则和未决问题，保留原始语义。

Feature Benchmarking · 参考调研

先形成带来源的资料包，再按任务逐项对照参考产品；比较的是具体任务和设计选择，不是抄界面。

Design Definition · 设计定义

依据已有材料解释范围、结构、状态与用户操作流程，避免把并列功能硬画成线性流程。

AI Design Input · AI 设计输入

集中维护确认后的逻辑、现有页面上下文与已采纳参考，减少多个下游版本互相矛盾。

SeaTalk Feedback · 用户反馈分析

分析团队内部沟通工具（SeaTalk团队内部沟通工具：需求与反馈常在其中讨论，反馈分析会把结论追溯到原始消息。）上的问题和回复，区分能力缺失、故障、发现性、权限与体验；结论追溯到原始反馈。

Skill Audit · 交付审计

记录产物质量、用户反馈与修订问题，为后续调整工作流提供依据。

Workflow Routing · 流程编排

检查已有输出，续接当前阶段；根据实际需要进入下一步，避免重复整理。

三套手法指向同一件事：让判断有依据。用研告诉我下一步改哪里，度量让质量有标准，前期方法让材料能接续。对一项改进来说，后续要看的也不是访问量：用户有没有找到、用对、继续用下去，才是真的变化。