原文传送门：Design System Checklist
此清单是更大的 第一部分 → 设计系统的五大支柱 第二部分 → 设计系统清单 第三部分 → 设计系统资源和链接
支柱1 - 出售我们的设计系统
目标
- 我们的利益相关者期望什么
- 我们的期望是什么？ （它有多完美？这些期望是否满足？）
- 谁将使用这个设计系统？ （开发者，代理商，内容编辑，...）
- 我们是为多种产品设计的吗？
范围
我们将提供什么：
- 原则（品牌价值，目的，......，限制它们！）
- 风格指南（视觉）
- 用户体验模式（互动，最佳实践......）
- HTML / CSS实用程序类（排版，颜色，按钮，表单......）
- 功能组件（可在你的应用内使用）
- 复制（措辞，语气，...）
- 图标，插图和图像
- 声音和动画库
利益相关者和流程
- 我们的团队需要哪些角色才能获得成功？
- 我们的设计过程应该涉及哪些专业？ （业务，产品，软件开发和运维，测试，支持，......）
- 我们是否已经获得了团队和利益相关方的支持？
- 我们需要满足哪些可交付成果和截止日期？
- 我们的系统在初始开发过程中是否已经在产品中使用过，或者我们是否已经发布了完成的v.1？
- 谁需要签署我们的工作以及在哪些步骤？
- 我们的设计系统的路线图是什么？未来如何维护？（范围，MVP，迭代，扩展，......）
支柱2 - 研究我们的设计系统
初始设置
- 它是重新设计还是全新的？（迁移旧应用程序 可能会出现全局性CSS类的意外效果）
- 我们遵循哪些规则和原则？
- 目前的设计在哪里运作良好？
- 我们可以改进现有的设计？
- 我们想要一个严格或宽松的设计系统吗？
- 我们从哪里可以汲取灵感？ （良好的复制/参考其他>槽糕的自创）
- 我们是否定义了最重要的术语来传达我们的设计系统？（设计师，开发者和利益相关者必须讲同样的术语）
用户
- 我们有足够的见解来理解它们吗？（历程，JTBD）
- 我们的应用程序有哪些背景？
- 他们与我们的应用程序交互的频率如何？
- 他们想要使用我们的应用吗？
- 我们的观众对我们的主题有多少了解？
- 我们的用户是否会接受培训或从零知识开始？（B2E，B2B）
- 是否有我们的观众期望的标准或API？（通常是B2B中的情况）
- 我们会满足哪些残障人士？
技术
- 什么输出渠道适合我们的观众？（网络，移动，API，服务......）
- 技术堆栈对我们的设计有影响吗？
- 我们将提供什么？（视觉指南，html和css模板， 功能组件，......）
- 我们需要个性化的帐户和不同的角色吗？（B2C，B2E）
- 访问受限区域内的功能或组件是？
- 将集成哪些系统或来源？
- 我们需要实时数据吗？（数据是否需要推送到前端，例如使用websockets，或者前端是否会主动轮询数据）
支柱3 - 设计我们的设计系统
布局和内容
- 我们设计了哪些屏幕尺寸和输入法？
- 不同产品和平台的一致性如何？
- 我们期望什么类型的内容 （数据，主要是文本和图像，产品......）
- 我们在哪里可以看到最高的复杂性，无论是视觉还是功能？（表格，表格，仪表板，产品，结账......）
- 会不会有外语和他们的需求？ （RTL / LTR，标签需要多长时间？）
- 谁会负责写文字/文案？ （我们的设计系统的标签和描述性文字）
- 我们的信息架构对导航有何要求？（深度，宽度，3年内有多少层级？）
- 用户将如何导航？（菜单导航和/或内容，主 - 细节视图，搜索，对话框......）
- 用户是否可以自定义他的视图？
- 我们的系统能够个性化吗？
- 我们是建立在现有设计系统或框架之上的吗？ （材料，Bootstrap，......）
- 我们的网格外观和感觉如何？（外观，列，空白）
- 我们的产品需要哪些组件？ （创建库存，标记您已拥有但不再需要的库存）
支柱4 - 建立我们的设计系统
操纵数据
- 用户在哪里编辑内容？（对话框，内联，弹出窗体，......）
- 自动保存或保存按钮？
- 我们需要内联编辑（复杂的验证规则会发生什么？）
错误预防和错误容错
- 我们何时验证用户输入以及如何显示验证消息？（对多个领域的复杂验证）
- 是否有撤销选项，如果我们没有用户，我们的用户风险有多大？（对自动保存特别重要）
- 我们需要历史吗？（记录，回滚）
- 会话超时会发生什么？（例如，有人在第二天在打开的浏览器窗口中恢复任务，但会话已超时）
- 我们是否可以使用合理性检查来防止错误发生之前？
通知
- 需要什么级别的通知？ （信息，成功，警告，错误，严重）
- 我们在哪里展示它们？
- 除了屏幕之外还使用了哪些频道？ （推送，电子邮件，短信，信息屏幕......）
- 如果用户错过了重要通知，可能会导致真正的问题吗？
测试和文档
- 我们何时以及如何运行可用性测试？
- 我们如何测试设计系统的代码？
- 我们应该记录哪些部分？ （模式，组件，代码，做和不做）
- 我们在哪里可以记录它？
支柱5 - 维护我们的设计系统
积分
- 我们的构建管道是否允许自动化？
- 我们如何自动化测试？
- 我们如何设计我们的设计系统？（语义版本控制）
- 产品团队提交请求的过程是什么？ （功能，只有错误修正，测试）
- 我们是否需要具有请求需要传递的规则才能使其进入设计系统？
- 我们使用哪些渠道向我们的产品团队通知新版本？
- 谁更新新版本的更改日志并发送新闻稿？
缩放
- 所有产品是否都需要整个设计系统，还是可以将其分组到插件中？
- 我们的产品团队允许对我们的设计系统进行哪些调整？
- 产品团队可以实施他们自己的组件版本吗？
- 我们如何添加，弃用和删除组件？
其他参考：