toss-tech-design

应用 Toss Tech 设计方法

概述

不要把 Toss 设计当作「让界面更好看」，而要将其视为一种运营技术，涵盖问题定义、研究运营、内部工具、UX Writing、无障碍、品牌与信任。

本技能是一份执行指南，帮助你快速应用 sources/toss-tech-design-summary.md 摘要存档中的核心原则。如果需要详细依据，请直接引用这份摘要存档；如果把握不高，应优先依据摘要存档，而不是泛泛而谈。

适用场景

• 设计或评审金融、支付、认证、引导等认知负担较重的流程时
• 希望将研究从一次性验证转变为运营体系时
• 希望从结构上减少重复手工操作、遗留工作流和内部工具低效问题时
• 希望将 UX Writing、错误消息和指南建设成系统，而不是依赖个人能力时
• 需要重新设计无障碍、外国人、老年人、屏幕阅读器用户等群体的实际受阻环节时
• 需要将品牌、图形和交互视为认知、信任与沉浸问题，而非装饰时

以下情况请勿使用此技能：

• 只想模仿 Toss 的视觉风格时
• 不定义问题，只调整界面美感时
• 想在没有原文依据的情况下猜测「如果是 Toss 会怎么做」时

核心原则

1. 不要照搬庞大的流程，而要将其拆分为一个个动作。
2. 询问每个动作「为什么需要」，并区分哪些应该删除、哪些应该自动化。
3. 优先级应依据所有利益相关者的资源和情境，而不是只考虑团队便利。
4. 相比完整解决方案，优先选择小规模测试和渐进式应用。
5. 研究不是代做访谈，而是用于定义问题和转换情境的基础设施。
6. 产品设计应专注于重新设计问题结构，而非增加功能。
7. 像衡量和改进面向客户的产品一样，衡量和改进设计系统、内部工具和文案指南。
8. 无障碍不是检查清单，而是决定实际可用性的核心易用性问题。
9. 视觉元素和交互不是装饰，而是提升认知速度、信任、沉浸感和理解度的手段。
10. 信任优先于转化率压力，避免施压或欺骗用户的文案。
11. 要快速了解领域，不要坐在桌前猜测，而要深入现场和用户的日常情境。

工作方法

1. 重新定义问题
   找出用户表面问题背后的结构性问题。不要照单全收功能请求，先重新定义「什么地方让用户受阻」。

2. 将流程拆分为一个个动作
   拆分为实际行为，而不是宽泛的阶段。例如：选择日期、添加参与者、附加链接、更改公开范围。

3. 询问每个动作的原因
   将每个动作归类为 保留、删除、自动化 或 辅助。此时应从所有利益相关者的角度出发，而不是只考虑自己的立场。

4. 设计最小规模的实验
   不要启动大规模改版，而应先测试风险最低、效果最大的微小改动。

5. 从真实用户的角度看待失败环节
   站在无障碍用户、外国人、老年人、初学者和内部工具用户等实际受阻者的情境中审视问题。

6. 转化为可衡量的运营单元
   通过搜索时间、完成率、错误率、满意度、信任损失、探索成功率等指标，建立可运营的状态。

7. 将一次改进升级为系统
   好的解决方案不应止步于文档，而应沉淀为组件、模板、库、指南或运营结构。

领域视角

• Research Ops：减少研究人员个人的瓶颈，让团队中的任何人都能设计合适的问题并解读结果。
• 产品设计：与其提供更多选项，不如减少用户需要考虑的事项和输入，让下一步操作更简单。
• 内部工具 / 设计系统：像改进面向客户的产品一样，根据 KPI、满意度、探索时间和可扩展性改进内部工具。
• UX Writing：好文案不是个人品味，而是一套系统。应设计模板、原则、降低撰写门槛的方法和团队共识机制，并避免施压或欺骗用户的文案。
• 无障碍 / 包容性：与其增加单独模式，不如重新设计现有的信息结构、阅读顺序、状态传达和输入方式。
• 品牌 / 图形 / 交互：评判标准应是提升认知速度、信任、中立性、状态理解和沉浸感，而非外观是否漂亮。
• 人员 / 文化：角色和文化也应通过标准、反馈和引导机制来设计，而不是停留在宣言上。

执行模式

• 快速模式：仅使用 Core Principles 和 Quick Reference，快速给出方向。
• 深入模式：结合 Domain Lenses 和原文依据，制定具体的执行方案。
• 审查模式：同时查阅 sources/toss-tech-design-summary.md，明确依据、局限和适用范围。

输出约定

应用此技能时，尽可能按以下顺序作答。

1. 如何重新定义问题
2. 如何拆分动作
3. 应减少、删除或自动化哪些内容
4. 最小规模的实验是什么
5. 用哪些指标判断成功
6. 应沉淀哪些可重复使用的系统资产
7. 如果依据很重要，使用了哪些原文依据

快速参考

信号	优先询问	默认倾向
用户觉得复杂	不要问哪里难，而要问用户在哪里停下来了？	减少选项和输入
有很多重复手工操作	将流程拆分为一个个动作后，还剩下什么？	与其大规模自动化，不如从小处着手
研究成为瓶颈	谁能设计问题并解读结果？	将研究建设为共享基础设施
内部工具满意度低	真的变快了吗？变得更容易查找了吗？	衡量满意度和探索时间
文案质量参差不齐	换谁来写都能达到稳定水准吗？	通过模板和系统推广
存在无障碍问题	实际用户在哪些地方无法独立完成任务？	比起检查清单，更关注任务成功率
品牌 / 图形难以判断	比起是否更漂亮，是否能更快被识别？	优先考虑信任和认知速度

实施示例

场景：分享研究日程的流程缓慢，且人为错误较多

1. 将分享日程的完整流程拆分为选择日期、添加参与者、附加链接、设置公开范围和撰写消息。
2. 询问每个动作「为什么需要」，并区分不必要的步骤和可自动化的步骤。
3. 不以自己的便利为依据，而是根据所有参与者的资源重新确定优先级。
4. 先进行最小规模的实验，只实施一项改进，例如自动邀请内部参与者。
5. 衡量分享所需时间、修改次数、人为错误和满意度的变化。
6. 确认效果后，将其升级为研究运营模板或内部工具功能。

常见错误

• 用增加功能掩盖问题，不重新审视结构。
• 一开始就把效率提升变成大型项目。
• 只把研究当作后期验证环节。
• 把内部工具和设计系统当作辅助工具。
• 只把 UX Writing 原则留在文档中，而不通过系统推广。
• 使用施压式转化文案或夸大的说服方式，损害信任。
• 只把无障碍视为法律合规或检查清单。
• 把品牌和交互当作装饰性设计。
• 明明需要原文依据，却用泛泛而谈的内容敷衍作答。

Reference

• 빠른 적용은 이 파일을 우선 사용한다.
• 세부 근거와 기사별 맥락은 sources/toss-tech-design-summary.md 요약 보존본을 본다.
• 기사 원문 URL, 페이지 흐름, 태그 분포, 추출 한계까지 필요하면 반드시 요약 보존본에서 확인한다.