编写设计系统文档，并让它保持最新

## 确定设计系统文档的范围，从原则到组件 既要记录系统的无形基础——原则、决策和工作方式，也要记录其有形资产：模式、组件、使用规则和实施工具。在开始编写之前明确展示范围，使遗漏成为待办事项，而不是意外问题。 ## 把文档拆成页面，从大家最困扰的地方写起 将工作拆分为内容完整、可独立使用的页面。优先处理造成最大阻力的领域，然后处理使用频繁或依赖关系复杂的组件。跟踪进度，并在约束条件变化时重新审查优先级。可以使用团队能够可靠维护、搜索和共享的任何工具。 ## 用四个问题说明每个组件 针对每个组件回答四个问题：它是什么，包括其状态和选项？为什么选择它，而不是类似的替代方案？在什么情境下使用它才合适？应如何使用它，包括受支持的变体、示例以及明确的应该做和不应该做事项？ ## 先为设计师和开发者编写，给其他角色简短说明 首先服务于设计师和开发人员，提供清晰的行为说明、决策标准、实施参考以及代码链接或组件示例链接。为产品、QA和研究岗位提供更短的验证路径。复用其他系统中的优秀模式，但要加以调整；能否顺利获取和使用内容比视觉上的完美更重要。 ## 发布前确认文档、设计和代码保持一致 将文档视为持续演进的产品。在评审中审查新组件和指南，在项目启动时评估文档需求，通过用户测试和无障碍检查来检验组件，并在发布前验证设计、代码和文档是否一致。当证据表明维护惯例无效时，应予以改变。