背景介绍
伊智OA（顾问SaaS）是公司内部销售顾问、运营顾问、和管理人员使用的工具，主要用于在与客户谈合作时能快速拟定合同和完成签约，利用数字化手段提升业务端录入客户、签发合同的效率；其次是做客户资源管理（包括构建公海客户和线索跟踪等客资管理功能）、实时的量化数据管理。对内部来说是一个提升合同签约效率和客户信息管理维护的工具。
挑战
设计+研发，16个工作日
1.) 缺少流程
e.g. 签约流程、续约流程、合同改价审批流程都缺少，这些都是这个项目的核心流程。
2.) 功能描述仅基于业务考虑，缺少对基础交互、技术限制的考虑
e.g. 创建客户表单分为基本信息和合同信息，合同信息为非必填项，但只要有一项填写了，合同信息剩余的项都必须要填写。
3.) 信息框架、功能交互不合理
e.g. 客户名片（客户详情）页面的功能按钮排放杂乱无逻辑，仅是为了表明有这么一个功能。
e.g. 基础交互组件如时间选择、下拉选择等都基于PC，不适合移动端。
4.) 功能细节描述不完整
e.g. 不同类型的合同签约、续约、升单等操作缺少前置条件和结果事件。
e.g. 单店、连锁签约续约的约束条件不明确。
顾问、产品和后端在一处办公地点，设计和前端又在另一处办公地点，在前期有沟通困难，而且时效性长。
做了什么
重新沟通和确认需求
现有的需求文档缺少关键流程和细节交互操作说明，如果直接设计，会预判到进入开发阶段会有很多问题。整理需求疑问点和，再拉着产品和开发逐点沟通，确定相关方案和让开发考虑实现可行性问题。
明确业务模型
电子合同的完整功能交互，包括签约、续签、升单，都依赖于 门店 - 合同类型 - 合同版本 这三者的模型关系。在没确定之前，基础的事件交互容易做得天马行空。为了让产品和开发明确了解清楚，以及保证整体交互和设计方案的完整性、可行性，对它们进行了简单的业务建模。
合同签约有针对单店和连锁（包含主店和分店），这两者的在签约处理上会有差别。下面这个界面是门店签约的入口页面，可以选择签约哪种类型的合同，但在这之前我们需要解决几个关键问题，才能知道在具体签约合同时的交互要怎么做。
要回答这些问题 ，其实是先整理清楚门店--合同类型--合同版本三者之间的对应关系，下图所示
除了上面这个门店-合同类型-合同版本的关系问题，也存在其它方面不确定的问题，比如不同合同类型的计价方式，特别是连锁的主店或分店在签约时的价格计算方式；还有合同在续约、升单后的记录要怎么处理等。
梳理流程
创建合同（首签、续签、升单）、合同管理、合同审批，这三者的流程在产品提供的文档都缺少清晰的描述，在沟通后，将这部分流程的需求重新转译为可实现的合理的方案，以及整理整条流程之间涉及到的干系人、操作和状态流转关系。
下图是合同从创建到审批流程相关的部分页面
优化交互和页面框架
由于产品所设计的原型没有考虑到基本的移动端交互、表单校验、信息框架如何合理布局等问题，在设计阶段充分了解和把握真实需求动机后，把这些问题逐一想办法解决，最大程度地保证了设计的可行性。
下面两图是部分做过调整的页面：
页面展示
总结
设计流程上跨职能敏捷协作:
1、设计沟通，目的是充分了解需求和发现问题。沟通需求、疑点问题、方案探讨 (结合需求、设计、技术)，通过提问题引导产品反向得出真正的需求点，渐进式地协助产品发现问题，再共商提出更好的方案。
2、设计梳理，目的是重新梳理功能点和流程逻辑，保证功能的完整闭环，以及采用什么样的交互和设计语言。
3、设计输出，产出设计稿和完成交付。
思考：
- 如果缺乏对基本业务的理解，脱离业务和使用场景的设计是很难落地的。像合同几个表单信息的页面，它背后所关联的业务逻辑和流程交互是整个项目里最为复杂和最有挑战性，从合同数据的对应关系，到创建、续约、升单和审批都互相关联着，影响到整个流程交互的状态流转和闭环设计。
- 职责不要仅局限在设计的好看，也不要仅局限在设计执行。多深入看看实质的需求触点和业务。
设计、产品、研发合作，多次沟通在方案上达到共识，比起设计被动地接受需求更有助于发挥设计价值和推进方案落地。