模块负责人

  • 👩‍💻 leeifme / XXXX项目
  • 🚀 XXXX部门 / XXXX事业部
  • 📧 Email i@leeif.me

版本历史记录(History) (可选)

设计稿版本每发生一次比较大的迭代更新,都要记录在版本历史记录里,相比一个个去翻以前的设计稿,版本历史记录可以清晰地展现设计稿的迭代历程,有哪些需求的变动,有哪些设计时没思考清楚需要修改的地方,Review 时大家给出了哪些意见和建议等。有时版本需要回滚,可以更方便地追溯,而项目结束后浏览这一部分,可以看到自己的设计在哪些方面一开始思考不足出现了各种问题,是如何被发现、改进和提升的,下一次设计的时候是否可以更早地思考到和回避掉

排期(Schedule) (可选)

和需求方确认各阶段交付的时间节点,制定完成模块设计的具体计划,每个阶段大概做哪些工作,什么时候内部 Review,什么时候和项目组 Review 等。确保设计以一个合理的节奏展开,可以以较高的质量按时交付

模块概述(Background)

这一部分的内容在开发者和 PM、业务方充分沟通需求之后完成

  • 模块描述,要设计的产品是什么,解决什么业务需求
  • 业务 / 产品现状,总结需求方现在面临的主要问题
  • 功能设计,模块开发关键点以及业务逻辑描述
  • 需要设计什么新的功能,需要优化哪些已有的设计
  • 提高模块哪些使用环节的体验,引导用户做出什么操作

模块详细设计

详细描述模块实现的架构分析,采用的框架、技术栈选型,以及实现算法等

  • 使用第三方服务:采用的框架、什么存储服务、数据库、队列等等的一些服务,以及可能需要用到的算法
  • 程序逻辑描述:有什么样的交互逻辑,处理流程是什么样的,是不是有异步处理任务又是怎样做的
  • 数据结构定义:程序内部主要用到的数据结构、数据库表设计、索引设计
  • 结构 / 架构图:根据使用了什么服务、有什么样的调用流程、或者是程序里面有什么样的结构和流程需要画的图

这些框架、设计都需经过可行性分析,必须是可行的

接口设计文档(Interface)

主要参考 Swagger文档(如果有),这里只做一些补充说明,用来说明调用此接口需要注意的事项(没有可不写)

原型设计(可选)

原型设计之于应用开发,是为第一要素。它所起到的不仅是沟通的作用,更有体现之效。通过内容和结构展示,以及粗略布局,能够说明用户将如何与产品进行交互 。也能更直观的体现出所设计模块的基本功能和交互方式,体现开发者及UI设计师的idea,体现用户所期望看到的内容,体现内容相对优先级等

测试要点(可选)

给出测试模块的主要测试要求,和逻辑操作

注明: 以上设计规范只是通用设计要求,具体视模块功能要求做具体改动

聊天灌水摸鱼区

温馨提示: 遵纪守法, 友善交流!