决策支持不足
代理人需要比较价格、保障、佣金和产品卖点，并根据客户需求完成推荐。但这些信息并不总是在真正需要做决定的时候被清晰呈现。
问题不是展示多少信息，而是什么信息应该在什么阶段支持什么决定。
← 全部项目
IGNITE / PURCHASE EXPERIENCE / CASE STUDY 01
为多产品、多市场建立一套可扩展的保险购买流程
Ignite 是一款面向保险代理人的数字化销售平台，覆盖多个东南亚市场和保险品类。随着业务扩展，不同产品、保险公司和市场规则不断增加，购买流程需要承载越来越多的业务差异。
我主动发起并主导了这次 redesign，希望回答一个更根本的问题：
如何在保留不同保险产品必要差异的同时，建立一套清晰、一致，并能够持续扩展的购买流程？01 / REFRAME THE PROBLEM
从多种调研信号中，重新定义问题。
我结合真实使用行为回看、代理人与内部团队访谈、东南亚同类产品研究，以及 PM、设计师和业务相关方的反馈，从不同角度梳理现有购买流程，并将发现收敛为三个核心问题。
不同来源的信息最终指向三个核心问题。
复杂度变成操作负担
保险购买天然包含核保、客户资料、文件和市场规则等复杂要求。这些无法被设计消除，但重复输入、冗长表单、不一致的交互和不清晰的验证，又增加了额外负担。
目标不是让保险变简单，而是让复杂的业务过程更容易理解和完成。
相似问题反复设计
不同保险品类虽然业务不同，但产品发现、报价、比较、信息录入、文件处理和购买确认等问题不断重复出现。过去每增加一个产品，团队仍需要重新完成相对完整的设计工作。
哪些问题值得设计师重新判断，哪些问题应该被系统一次解决？
02 / ALIGN ON THE RULES
从优化流程，到建立购买流程规则。
在 Design Sprint 中，我组织 PM、设计师与业务方梳理调研发现，将分散需求收敛为三个共同问题，作为后续设计取舍的依据：
各页面承担什么任务？
- 列表页帮助代理人发现产品
- 报价页呈现保费、佣金与关键保障等帮助代理人做决定
- 详情页提供最完整产品信息
- The product list helps agents discover products.
- The quote page shows premiums, commissions, and key coverage details to help agents decide.
- The product detail page provides the most complete product information.
如何减少资料填写负担？
- OCR 识别资料，减少录入并提高准确性
- 根据历史保单和客户资料预填信息
- 分步填写，清楚显示当前进度
- 实时校验，错误提示定位到具体字段
- Use OCR to extract details from documents, reducing manual entry and improving accuracy.
- Pre-fill application details from previous policies and customer records.
- Break the form into steps and clearly show where agents are in the process.
- Validate entries as agents fill out the form, and show errors beside the relevant fields.
哪些设计不必为新产品重做？
- 将重复的浏览、比较、填写与确认沉淀为共享页面和交互规则
- 报价字段、核保要求、保障内容及保费计算仍按产品与市场配置
- Turn recurring browsing, comparison, data entry, and confirmation into reusable page structures and interaction rules
- Keep quote fields, underwriting requirements, coverage, and premium calculations configurable by product and market
03 / DESIGN DECISIONS
三个设计判断，定义新的购买体验。
信息如何组织、复杂度如何取舍、哪些规则需要共享。
DECISION 01
根据决策阶段组织信息
代理人在浏览、报价比较、查看详情和提交前确认时，需要看到的信息各不相同。我据此安排各页面的信息重点与深度。每个阶段突出支持当下判断的信息，详细程度随任务而变化。
浏览产品
列表页突出承保公司、产品标签和核心亮点，帮助代理人判断哪些产品值得进一步了解。
报价与比较
报价结果集中呈现保费、佣金和关键保障，支持代理人比较方案并做出推荐。
深入理解产品
详情页提供完整保障与投保资格，帮助代理人核对产品是否符合客户需求。
提交前确认
摘要页汇总保费明细和已填写的关键信息，供代理人在继续购买前核对。
DECISION 02
管理复杂度，而不是掩盖复杂度
我区分两类复杂度：影响报价、核保或交付的业务要求必须保留；由页面组织和交互造成的额外操作应当降低。标准化不是让复杂产品变简单，而是不再让设计增加不必要的复杂度。
保留 · 必要的业务要求
报价需要获取影响保费的投保信息；代理人还需看清保障范围、保额限制与投保资格。申请时，核保资料和必要文件也须按产品与市场规则收集。
降低 · 额外的操作负担
OCR 识别上传资料，结合历史保单与客户资料预填信息，减少手动和重复录入。表单分步呈现、显示进度，实时校验并定位错误；同时支持保存草稿后继续。
DECISION 03
标准化体验结构，而不是产品本身
跨产品重复出现的购买任务，可以由稳定的页面职责和交互规则承接。我把共同部分整理为共享页面规范，同时明确哪些内容按保险类别配置。一致的是规则，灵活的是产品。
共享页面骨架
产品列表展示产品与亮点；报价结果突出保费、关键保障与卖点；详情页承载完整信息；摘要页用于核对方案与被保险人信息。
统一交互与命名
比较、切换方案、展开保障与分步填写采用一致的交互；产品名和方案名在报价、比较、摘要等页面遵循同一命名规则。
配置产品内容
按保险类别定义快速报价的输入与回显、摘要中的关键字段；保障项目和具体条款仍按产品呈现。
04 / DELIVERY & OUTCOMES
让新购买流程落地、复用并接受检验
我将前期的设计判断落实为完整购买流程，与团队把可复用规则整理为 Purchase Template，并在上线后通过代理人反馈检验新流程。
FLOW 01
重设计整个购买流程
我主导重设计了原有购买流程，把产品发现、报价、申请、提交和支付重新组织为一套连贯的体验。新版流程保留不同的入口和报价方式，同时明确它们如何衔接共同的后续步骤。最终交付的流程结构让各环节能够作为一个整体推进设计与实现，也为后续产品沿用提供了基础。
REUSE 02
让新版流程支持后续产品
为落实“标准化体验结构，而不是产品本身”，团队将跨产品共用的页面职责和交互规则整理进 Purchase Template，并保留按产品与市场配置的报价字段、核保要求和保费计算方式。
模板将这些字段与规则对应到设计页面和 Turbo 配置。
现有流程适用时，Local PM 填写、项目 PM 审核，开发即可直接配置，无需再参考设计稿；新类别的首个产品或现有设计无法覆盖需求时，设计重新介入。
FEEDBACK 03
用上线反馈检验新流程
新版流程上线后，我设计了 in-app survey 收集代理人反馈。在新流程上线后90天内，累计回收 324 份问卷。
324上线后90天累计回收的问卷
≈79%反馈中给出 9–10 分
≈+70NPS得分
REFLECTION
标准化的本质，是减少重复判断
这个项目让我重新理解了“标准化”：它不仅要沉淀可复用的设计判断，也要明确规则何时失效、何时需要重新判断。只有持续审视这些边界，复用才不会固化过去的答案。