您最近是否在考虑样式指南？在我看来，它似乎是当今最热门的话题之一。作为一位在普遍观点认为“想法不错，但这些从未奏效”时就尝试以这种方式思考和构建的人，我很高兴看到这种情况的发生。我怀疑样式指南和设计系统之所以流行起来，原因有三方面
- 基于组件的前端架构变得非常流行
- 范围样式的样式哲学变得非常流行
- 社区态度发生了转变，认为样式指南有效
最后一个对我来说类似于加密货币。如果每个人都相信其价值，它就会有效。如果人们停止相信其价值，它就会消亡。
无论如何，在我典型的咖啡和 RSS 早晨，我最近偶然发现了大量关于样式指南的文章，因此我认为我应该将它们汇总起来，供您欣赏。
如何与小型团队构建设计系统 by Naema Baskanderi
作为一个致力于 B2B 企业软件的小型团队，我们在时间、预算和资源有限的情况下深入研究了设计系统的创建……当您没有足够的资源、时间或预算时，您从哪里开始呢？
她的五条建议对我来说感觉很正确
- 不要从头开始
- 了解您正在使用什么（审核）
- 边走边建
- 了解您的局限性
- 保持井然有序
样式指南驱动的设计系统 by Brad Frost
我经常让团队在他们的设计系统计划的第一天建立样式指南网站。样式指南充当展示所有设计系统要素的店面，并充当整个工作的有形中心。
This Also 发布了他们的样式指南（如果您喜欢查看其他人的看法，这里还有数百个其他样式指南）。
对我来说，值得注意的是，它最接近我理解的“样式指南”的含义（与更多关于网站构建部分的设计说明的“模式库”或“设计系统”相反）。他们只包含对品牌最重要的三件事：排版、写作和身份。明智之举。
您撰写的任何内容都应该易于理解。写作的清晰度通常遵循思维的清晰度。花时间思考您要说什么，然后尽可能简单地表达出来。在代表工作室写作时，请牢记这些规则。
为系统设计奠定基础 by Andrew Couldwell
我使用“基础”一词作为设计系统和思维层次结构的一部分。将基础视为数字品牌指南。它们激发并与我们的设计系统相吻合，指导我们所有数字产品。
- 在品牌层面，它们涵盖诸如价值观、身份、语气、摄影、插图、颜色和排版等方面。
- 在数字层面，它们涵盖诸如格式、本地化、号召性用语、响应式设计和可访问性等方面。
- 在设计系统中，它们是以下内容的基础，并涵盖以下内容的应用：文本样式、表单输入、按钮和响应式网格。
再次后退一步，更广泛地看待。是的，这是一个设计系统，但它与品牌价值观并存。
如何创建动态样式指南 by Adriana De La Cuadra
与标准样式指南类似，动态样式指南为应用程序的样式使用和创建提供了一套标准。对于标准样式指南，其目的是维护品牌一致性并防止图形和设计元素的滥用。LSG 以相同的方式用于维护应用程序的一致性并指导其实现。但使 LSG 不同且更强大的地方在于，其大部分信息直接来自源代码
一个简单的首要反应可能是：当然，我们的样式指南是“动态的”，我们并没有打算构建一个静态的样式指南。但我认为这是一个有趣的区别。几年前我写过，样式指南可以在您的开发过程中占据不同的位置。
很容易创建一个置于场外或作为流程“尾气”的样式指南。将您的样式指南直接置于开发工作流程的中心，并且不允许任何旁路，这完全不同。
最后，Punit Web 汇总了一些最近发布的样式指南，如果您特别感兴趣于之前可能从未见过的最新样式指南，可以参考。
我的观点是，样式指南必须由设计团队编写。事物的精神以及它们实际的样子。
然后，开发团队可以构建此样式指南的一种副本，显示实际的实现，并可能解释如何实现这个或那个组件。
我看到的“动态样式指南”（一旦您在代码中添加定义就会自动更新的指南）问题是，如果您创建的样式不尊重任何先前的约束，它无论如何都会成为样式指南的一部分。违反的规则就变成了规则。
从设计的角度来看，当我一直是唯一的 UX 团队成员，并且作为一名比平时更了解 CSS 但坚决不认为自己是前端开发人员的人来说
有一些很棒的组件库工具（Fractal 跃然于脑海），但它们中的大多数都以开发人员为中心。要运行它们，您需要了解 Node、构建工具链、任务运行器、JSDoc 和/或 Git 等。当并非每个人都能做出贡献时，这就会成为一个障碍。
例如，没有多少 CMS 主题适合使用 WordPress 等流行工具创建样式和组件文档。（如果有 CodePen 自定义字段插件就好了？）
有一些面向设计师的 SaaS 工具用于创建在线样式指南，例如 Frontify，但大多数在处理实时代码预览时都会失效（至少在我尝试时，CSS 会泄漏）。
当然，几乎没有真正好的用于 Web 原型设计或样式生成的所见即所得工具。（等待看看 Invision Studio 是否会成为其承诺的圣杯）。
理想情况下，设计师和开发人员会作为一个团队一起构建它——但比我们承认的要多，非编码设计师在自己独立的部门，生成大量静态组件和 Google 文档，众所周知，这些文档几乎会立即过时，如果他们能够对通用工具进行原型设计和贡献样式文档，那将是浪费时间。
因此……如果要真正采用样式指南/组件库，则需要使其对设计师和开发人员都友好。
我认为一个好的折衷方案是在纯 HTML/CSS/JS 中拥有组件的“基础”规范版本作为视觉和交互设计参考，以及针对一个或多个框架的代码……否则，您可能需要在您正在使用的框架中构建您的工具才能使组件正确呈现。
当您需要将这些样式移植到不同的框架时会发生什么情况（例如，当您的公司收购互补产品或您正在为客户定制前端时）？