原文传送门: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 - 维护我们的设计系统
积分
- 我们的构建管道是否允许自动化?
- 我们如何自动化测试?
- 我们如何设计我们的设计系统?(语义版本控制)
- 产品团队提交请求的过程是什么? (功能,只有错误修正,测试)
- 我们是否需要具有请求需要传递的规则才能使其进入设计系统?
- 我们使用哪些渠道向我们的产品团队通知新版本?
- 谁更新新版本的更改日志并发送新闻稿?
缩放
- 所有产品是否都需要整个设计系统,还是可以将其分组到插件中?
- 我们的产品团队允许对我们的设计系统进行哪些调整?
- 产品团队可以实施他们自己的组件版本吗?
- 我们如何添加,弃用和删除组件?
其他参考: