Part 1
0-1 调研与设计
2020 年 9 月，合同作为飞书的新商业化项目，2 个设计师需要在 2 个月之内完成产品设计方案，并于 12 月开发完成 MVP 版本，与潜在客户进行共创。
角色
用户调研，设计师
时间
2020.09 - 2020.12
1.了解市场和用户
0-1 的项目启动必须理解合同国内外的市场现状和业务流程，中国企业级合同软件的渗透率约为 15%，电子签普及率30%，市场空白较大。在国内企业数字化与合同电子化并不普及的阶段，通过用户访谈内容与市场调研，我们总结了合同的生命周期，用户类型与需求洞察。
2.探索产品结构与 MVP 方案落地
整体来说，海外合同产品发展较早，已经形成了可灵活配置且重视用户体验的体系。国内产品依然是大量堆砌功能、灵活性差的定制化产品。
国内现在没有标准化、功能强大且易用性高的合同类产品。
→ 我们的设计就是要去平衡「灵活性」和「严谨性」，基于用户动线设计，而非基于功能散点拼接。
经历了多轮的框架探索，我们最终决定使用类似海外竞品的横向导航结构，只外露基础功能模块，在流程性和功能深度上做到流畅。
MVP 设计方案 👇
3.客户测试产品与反馈迭代
上线后进行客户访谈，收集客户反馈，整理不同类型企业用户画像与用户旅程，了解功能缺失点与体验问题。
建立更细致的用户旅程地图，洞察各角色在各触点的痛点，找到产品迭代的入口。
Part 2
智能化设计与迭代
2021.04 起，飞书合同将「智能化」列为主要竞争力，作为智能化模块的设计师，从 0-1 搭建起「OCR 比对合同」、「智能审查风险」、「合同安全性体检」三个功能，成功帮助「OCR 比对合同」渗透率达到 80%+。2021.09 进行的「智能审查风险」改版，整体提升了用户满意度，获得 3 项发明专利，3 项外观专利。
角色
智能化模块 Designer
时间
2021.04 - 2021.11
1.什么是智能风险审查，为什么进行设计改版?
「智能风险审查」在多方协商合同内容过程中，让不懂合同的业务人员快速了解风险，让了解合同的法务人员解放人力。
第一轮用户需求调研后，我们判断风险应该用「目录」方式展示，先了解风险类型 → 再逐条看风险点。😭 然而上线后，「智能审查」功能使用率不足十分之一。
2.发现问题所在，找到 AI 审查应有的形态
为了发现并解决问题，设计侧启动了重构专项，发掘潜在的用户诉求和使用方式。
在一条条反馈中，发现了我们一直忽略的事实：用户按文本顺序阅读合同，所以需要按文本顺序审查风险 👇
和「飞书文档」类似，评论就是用户的 todos, 用户怎么处理文档的评论，就应该怎么处理风险。
和「Grammarly」类似，语法错误就是用户的 checklist，用户怎么修改语法错误，就应该怎么修改文本风险。
当我们确定这个思路后，根据业务目标、用户调研、现有问题重新梳理了用户的心路历程，反向推导出设计目标和策略。
3.设计方案
Step1: 分类 —— 审查要素重新聚类
用户不理解风险是什么，表面看是文案和表述问题，但本质是聚类不清晰，命名有歧义。于是与 PM 协作，对线上 17 个风险审查点重新归类、优化文案表述。
Step2: 风险卡片 —— 信息结构优化
目前的 17 个审查点未来会拓展更多，需要一个既有一致性也有扩展性的风险卡片结构，告诉用户：
“风险是什么、在哪里、为什么、怎么改”
Step3: 框架 —— 风险审查整体交互
改版前
风险点是以一个个散点的方式聚类在对应类别下的，用户每点击一个风险点，都会存在文本来回跳动的问题，没有阅读连贯性。
改版后
我们首先有一个总览，让用户明确知道“待处理”的问题有多少，再一一排查、一一处理。
Step4: 细腻的反馈机制
由于算法准确度的限制，如果我们不把风险的决定权交还给用户，很容易让用户产生对系统的不信任感。
于是我们将 AI 审查功能定位成 “Assistant” 角色，对用户、前端与系统的输入输出状态做了详细的梳理，用动效、颜色、输入失焦刷新、忽略风险等方式，增加及时反馈，降低用户等待成本，提升用户信任度。
改版后的两个月内，得到了良好的数据反馈，回收到的用户反馈对于算法准确性的提升也有重要的价值。在用户满意度调研中，智能化功能排在最喜欢的功能/体验前三位。
5. 设计反思
为什么会忽略最显而易见的现实 —— 文本阅读顺序？
在以产品视角定义信息结构时，很容易陷入功能本身的分类视角，将我们的逻辑误判为用户逻辑。AI 审查的载体是「合同文本」，而我们把关注点只放在「风险」上，就很容易陷入误区。
→ 设计不仅是分类，更是分类之后，如何与用户对话。
为什么用户会受到 AI 产品的冒犯？
专业性强的用户会有很强的「专业判断」。尤其在算法准确度不高时，用户很容易产生“系统在帮我做决定”的负向情绪，感觉系统不仅没有帮我提效，反而增加了无用信息量。
→ 以温和谦卑的助手姿态，辅助而不是要替代你做决定 —— "a second pair of eyes"，在 AI 与用户之间建立「信任感」：
提供透明度：告诉用户我们为什么觉得这里是风险，未来提供“置信度”等判断依据；
给予决策权：承认 AI 的能力边界，把「决策权」给到用户；
反馈机制：给用户「掌控感」，帮助我们“训练模型”，并让用户觉得自己在参与产品的成长。
6.其他智能化项目
通过「OCR智能比对」的入口和交互优化，渗透率达到 80%，一个月内提升 30%。
通过「合同安全性体检」的提醒机制优化，访问率一周内从 50% 提升至 77%。
2021.11 飞书发布会上的展示，智能审核、OCR 智能比对、体检都作为「飞书合同」最亮点的功能发布。
Part 3
在线协作流程优化
随着功能迭代，「协商」模块的信息结构很难再承载更多功能，积累了大量用户负反馈，于是对「协商」的全流程体验进行优化。项目设计方案历经 3 个月打磨，通过 demo 测试拿到用户的正向反馈，逐步迭代上线。
角色
协商模块设计负责人
时间
2022.04 - 2022.08
1.聚类现存问题，启动项目规划
😔 现存负反馈众多：易用性低，文件管理和编辑无法满足用户需求，引导性差，交互结构承载不了更多功能。
经过多渠道的问题收集、访谈总结和聚类，用户原声主要集中在：“不清楚有几个文件” “不知道上下文是啥，我来干嘛” “看不见修订记录，不知道改了什么” “不知道改到什么版本了” 。
2.为了解决问题，重新定义「协商」这件事
我们重新访谈了用户，了解他们的诉求。我们发现在使用 SaaS 产品之前，多方合同协作的方式多种多样：
有的用户习惯线下（方便却不能留痕）
有的用户喜欢群聊（快速但难以追溯）
有的用户喜欢邮件（可留痕可追溯，但效率偏低）
这打破了我们之前的认知，合同协商并不是类似「飞书文档」「Google Doc」一类的在线协作，更注重的是「流程管理」「留痕追溯」「版本管理」—— 一个更类似于项目管理的流程。
💡 重新定义
协商是几个人你来我往，对合同文本达成一致的过程。那么作为一个协作平台，我们的目标是：所有参与「人」理解「背景」，明确「任务」，修改并确认「文件」，同步「结论」，最终完成协商。
定义每个角色、每个流程节点的任务：
发起人：发起协商，邀请参与者，修改合同，完成协商…
参与者：修改合同，确认合同
3.设计方案：从发散到收敛
在竞品调研的过程中，我们发现项目管理类产品的共性：强调背景与记录的重要性。
第一版设计探索：完全打破用户习惯，着重项目与流程管理
👍 收到了小白用户很好的反馈，背景与任务非常清晰；
🤔 收到了现有用户、资深法务的大量反对，合同文本的触达成本太高，迁移成本太大，基于文本内容的协商，一进来看不到文本很焦虑。
最终设计方案：保持用户习惯的基础上，做基于文本的流程管理
👇
1.信息分区
2.强化所有角色的任务引导
3.统一的文件管理
4.清晰的版本管理
4.可用性测试
设计改版后，基于高保真设计 demo，通过本竞品对比、用户反馈、可用性测试等手段评估方案有效性，逐步迭代上线。
Part 4
国际化出海
2022 年初，飞书套件整体加快国际化进程，飞书合同需要在 Q1 三个月内完成日本、东南亚市场的多语言版本设计，并根据不同市场特点，做国际化功能适配。
作为国际化项目的设计 Owner，协调设计与研发资源，制定多语言设计规范，完成 10+ 功能需求，修复 200+ 双端问题，做到国际化 0 bug 上线，根据可用性测试结果持续迭代。
角色
专项 Owner，规范设计师
时间
2022.02 - 2022.05
1.项目背景
Q1 刚接到国际化战略，而现状是：😧产品 0-1 过程中主打国内市场，几乎忽略国际化。
无国际化：设计方案/组件无法适配多语言，时区、金额、时间等无国际化考虑；
无本土化：国内外工作流程有差异，彼此兼容有难度；
于是为了快速落地，并长远考虑设计的通用性，我们制定了两个阶段目标：
🎯 短期 —— Q1 解决多语言阻塞性的功能、视觉与交互问题
🎯 长期 —— 全球一致性 & 本地相关性
2. 解决策略：制定可执行的设计规范，系统性解决
Web 与手机端走查过后，发现了 200+ 视觉、交互与功能性问题。
🤔 设计挑战
如何在两个月内，解决这么多问题？补齐这么多功能？翻译这么多文案？
团队国际化规范宽泛，无法应用于具体场景，如何快速制定出可执行的设计规则？
设计策略：收集线上问题 > 组件化解决
推进策略：设计规范、功能修复、翻译、研发多线并行，最终进行可用性测试
3.规则设计：多语言设计规范
首先制定衡量维度，再定义设计规则，最后给出执行的工具、资料库。
▼ 通用规则文档 ▼
由于业务属性，涉及到大量格式化字段，在多语言下语序、书写方式都会有很大区别，以金额为例：
参考飞书、IBM、Alibaba 等国际化设计原则，总结出了如下决策树，帮助设计师在任何设计场景下，都可以遵循同一套决策逻辑。
在制定设计规则时，「省略」和「布局」是疑问最多的部分，涉及到的场景复杂，变量也很多。
首先给出 判断依据，什么时候可以省略，什么时候上下布局，什么时候左右布局；
再对 各个组件 进行省略、布局方式定义，同时给出 正反示例；
最后和前端合作，对于
min-widthmax-widthflex比例等等 调试参数，总结出可以复用的省略和布局参考规则。
制定布局规范时，我们观察到国内外产品的「表单布局」和「筛选/选择」设计相差甚远，于是综合调研国内外的差异，优先考虑使用上下结构，并根据不同文化下的用户习惯，灵活布局。
4. 可用性测试
Q2 初期为了保证上线采取了 2 个测试方式：
通过英语与日语专家的走查评估，度量翻译可理解性、页面可读性水平。
与产品、用研同学合作，邀约 6 位专家评估 8 个核心任务，为设计持续迭代提供优化建议。
随后对遗留问题进行快速修复，完成国际化版本的上线，不仅解决了 200+ 多语言问题保障了业务出海，界面一致性、流程完整性都有大幅度提高。
关于国际化的反思
—— 语言和文化决定了思考方式，进而决定了设计方式
从一个选择页面引发的多语言思考，为什么用户习惯会相差甚远？最初的疑问来源于筛选、选择、表单页面等的布局差异：
1 的布局方式在中国的 App 中十分常见，包括外卖、电商等；
2/3 的布局方式在罗曼语系下更常见。
当然，我们可以把原因归结于社会文化：东亚的用户更喜欢拥挤与热闹，而欧美是个人主义社会，且崇尚 less is more。
而根本原因，其实是「语言文字的特性塑造了我们的认知与思维习惯」：
东亚语言通常可以简短地表述抽象且复杂的概念，而拉丁语系的短语长度，完全不可控（例如：协商 → Negotiate，协商中 → Under Negotiation）
不是东亚的用户喜欢拥挤，而是语言本身的精炼程度、空间承载力，让我们养成了复杂信息接收能力与习惯。
《语言学的邀请》中谈到，认识一门外语才知道母语的相对性，当一个人只知道母语的时候，很容易陷入一种个人所在的地方性本位的误区（我的世界是唯一的世界）。
→ 设计的时候也同样如此，打破中文思维习惯，才能站在更广泛的用户群体立场
→ 我们会发现，很多欧美软件为了降低用户认知负担，会采取任务引导性更强、更直接的交互结构，以英文为原点设计，有时会给我们更多样化的设计思路。