模块负责人
- 👩💻 xxxxx / XXXX项目
- 🚀 XXXX部门 / XXXX事业部
- 📧 Email xx@xxxx.xxx
版本历史记录(History) （可选）
设计稿版本每发生一次比较大的迭代更新，都要记录在版本历史记录里，相比一个个去翻以前的设计稿，版本历史记录可以清晰地展现设计稿的迭代历程，有哪些需求的变动，有哪些设计时没思考清楚需要修改的地方，Review 时大家给出了哪些意见和建议等。有时版本需要回滚，可以更方便地追溯，而项目结束后浏览这一部分，可以看到自己的设计在哪些方面一开始思考不足出现了各种问题，是如何被发现、改进和提升的，下一次设计的时候是否可以更早地思考到和回避掉
排期(Schedule) （可选）
和需求方确认各阶段交付的时间节点，制定完成模块设计的具体计划，每个阶段大概做哪些工作，什么时候内部 Review，什么时候和项目组 Review 等。确保设计以一个合理的节奏展开，可以以较高的质量按时交付
模块概述(Background)
这一部分的内容在开发者和 PM、业务方充分沟通需求之后完成
- 模块描述，要设计的产品是什么，解决什么业务需求
- 业务 / 产品现状，总结需求方现在面临的主要问题
- 功能设计，模块开发关键点以及业务逻辑描述
- 需要设计什么新的功能，需要优化哪些已有的设计
- 提高模块哪些使用环节的体验，引导用户做出什么操作
模块详细设计
详细描述模块实现的架构分析，采用的框架、技术栈选型，以及实现算法等
- 使用第三方服务：采用的框架、什么存储服务、数据库、队列等等的一些服务，以及可能需要用到的算法
- 程序逻辑描述：有什么样的交互逻辑，处理流程是什么样的，是不是有异步处理任务又是怎样做的
- 数据结构定义：程序内部主要用到的数据结构、数据库表设计、索引设计
- 结构 / 架构图：根据使用了什么服务、有什么样的调用流程、或者是程序里面有什么样的结构和流程需要画的图
这些框架、设计都需经过可行性分析，必须是可行的
接口设计文档(Interface)
主要参考
Swagger文档（如果有），这里只做一些补充说明，用来说明调用此接口需要注意的事项(没有可不写)
原型设计（可选）
原型设计之于应用开发，是为第一要素。它所起到的不仅是沟通的作用，更有体现之效。通过内容和结构展示，以及粗略布局，能够说明用户将如何与产品进行交互 。也能更直观的体现出所设计模块的基本功能和交互方式，体现开发者及UI设计师的idea，体现用户所期望看到的内容，体现内容相对优先级等
测试要点（可选）
给出测试模块的主要测试要求，和逻辑操作
注明： 以上设计规范只是通用设计要求，具体视模块功能要求做具体改动
许可协议
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
分享文章
