创建设计系统，而不是页面

很久很久之前，这些东西被称为书。记得吗？这些东西由枯树的的果肉制成，又沉又笨重。书里面的东西被称作页。你翻阅它们，它们会割到你的手指。

糟糕的东西。我很高兴这些书再也没有它们锋利的页面了。

噢，等等......

我们标页码的过去

页面已经和我们共存很久了，实际上是几千年。第一本书是在约4000年前用厚厚的粘土板制作的，很快卷轴成了更好的替代品来写字。尽管阅读技术已经走了很长一段路——从纸莎草纸到羊皮纸再到平装书再到像素，但页面的概念至今仍然很强。

页面这个隐喻从一开始就融入了网络的字典中。蒂姆·伯纳斯·李发明了万维网，以便他和他在欧洲核子研究组织的同事以及其他学者能够轻松的共享和连接他们的文档世界。Web这种以文档为基础的学术起源解释了为什么页面已经深深根植于网络的词汇表中。

所以呢？

正如我们将在本书中讨论的那样，事物的命名方式非常影响人们对其的理解和运用。将网页当作页面会对人们与网络体验进行交互产生真正的重大影响，也会影响我们去创建web界面。

从一开始，页面隐喻就为用户提供了一种熟悉的语言，可以用这种语言来浏览这个新颖的万维网。像加书签和翻页的概念帮助新的Web使用者用他们最习惯的习俗来探索和最终掌握这个全新的媒体。

对于Web用户而言，该页面（注：指的是chrome的该页无法访问页面）曾经是（并且将继续是）一个非常明显和有用的隐喻。它还对如何创建Web体验产生深远影响。

在web的早期，一些希望登上网络的公司只是为了把他们的纸质材料放到他们的网站上而已。但即使是这些宣传册网站提供了一个非常一维的web可以提供的视角，对于开发者来说，认真思考之后还是很容易将浏览网页作为纸质页面的数字化形式替代。

但是我们进入这种新媒体已经25年了，这种曾经很必要的表现形式已经过时了。不幸的是，页面的隐喻还在深深的影响我们检查和实行我们的web项目。这里有些例子我会时不时听到：
“我们将在这个10月推出一个5个页面的网站......”
“Brad，做一个首页需要多久？”
“我们要怎样去重构一个超过30000个页面的大学网站？！”

所有上面的这些情况都犯了一个根本性的错误，他们将页面视为一个整体，孤立的，量化的东西。实际上web是流动的，相互依赖与相互影响的。一旦我们接受了这个事实，页面的概念就会快速的消失，（这个事实将）成为我们检查和创建web体验的助力。

一个首页需要多久来创建？好吧，这取决于里面有什么内容，对吗？可能首页仅仅由一个宣传词和一个背景图组成，这意味着可以在午餐时间就能解决。或者它充满了轮播图，动态表单，和一些第三方整合。那种情况下可能首页需要几个月去完成。

至于30000个页面的大学首页，可能听起来吓人，“成千上万的页面？！喔，听起来有挑战性！”但实际上，那些个页面可能就由三种内容和两种布局组成。

最后，一个项目级的工时花费很大程度上取决于那些页面包括的设计功能和组件（components），而不是页面数量本身。

页面的隐喻服务于它帮助用户熟悉web的目的，同时给开发者提供必要的过渡语言去创建一个全新的媒体。但是要创建一个体验好的界面就意味着要服务于大量的连接的设备，对我们来说是时候在页面的基础上继续演变了。

撕碎页面

谢天谢地，web社区在建立规范和实践来帮助我们有效的讨论和创建web下了一番功夫。同时，在关于如何构建成功的web体验中讨论中有一个概念一直会被提到：“模块化”（译注：原文为modularity）

模块化要远远早于网络。工业革命时出现了可交换的部分，亨利·福特（译注：福特汽车公司创始人）的流水线永远的改变了汽车的制造工艺。早期的汽车和零件都是独立手工制作的，这就导致了很多安全和维修方面的噩梦。福特将汽车分解成它的零件部分然后将装配工艺模块化。最后就像他们说的那样：更加统一，更加可靠，更加安全的汽车从工厂出来，然后在记录的时间内启动。

随着机器时代之后是计算机时代，计算机科学家开始实践面向对象的程序，创建重要的模块化概念，就像关注点分离和单一对象原则。这个世界诞生了万维网，那么模块化设计快速成为了web体系的设计原则也就不足为奇了。

这些概念缓慢而确定地进入了web设计者的工作流程。在2000年代早期我们可以看到诸如YUI和jQuery UI等ui库的引入为开发者提供了一个模型和部件的小工具包，去为开发者们创建一个更加一致的用户界面。

模块化存在了这么久了，为什么我们现在还要讨论它呢？

简单地说，模块化比以前更加重要了。现在我们整个行业都淹没在大量设备，（不同的）视窗大小和在线的环境中。而且短期内这种情况将不会改变。

混乱只会加速。连接设备的数量和多样性（许多我们至今还未想到的）将会爆炸，使用这些庞杂的设备的人们也会爆炸。我们当前的标准，工作流程，基础设施将无法维持。当前的设备的冲击已经将这种爆炸推至了一个临界点，之后将无可抵挡。——未来友好宣言（The Future-Friendly manifesto译注：是一个网站，但是目前已经无法访问）

不管你喜不喜欢，多设备的宇宙已成现实。让我们的网页在少数的桌面浏览器中显示得一致已经是很难做到的了，但是我们现在的任务是要确保我们的网页体验能在令人头晕目眩的设备上看起来漂亮。（诸如智能手机，平板电脑，笔记本，台式机，游戏主机等等）

为了在我们保持理智的时候实现这些，我们绝对有必要退一步，将巨大的任务分解成更小的更便于管理的部分。

那正是大伙正在做的事情。模块化的精神正在进入web创造过程的各个方面，并对组织的策略，过程，内容，设计和开发产生了深远影响。

• 可管理的策略

每个机构最终都意识到将他们的网站推倒重来并用3-8年替换成一个New-And-Shiny™式的网站不是（而且从来不是）一个最佳的解决方案。
（译注：Google了一下也没有找到这个所谓的“New-And-Shiny”，可能就是字面上的意思——新鲜有光泽的233）

辞旧而迎新，这无疑是个吸引人的展望。但即使是在启动会的庆祝纸片飞舞之前（译注：脑补电影里面国外的庆功宴或者婚礼抛洒的五彩纸片），电话仍旧会打过来。“你动了我的奶酪！”那些已经花了很多年去学习以前的界面和功能的用户真的是哭了。

当大规模重构启动而且将对用户体验产生重要改变时，用户会被Jared Spool提到的“获取知识的神奇的自动扶梯”（Magic Escalator of Acquired Knowledge）所绊倒。巨大的重构对于系统来说是一个震动，新的沮丧的用户必须花费大量的时间和精力去重新学习经验，以便慢慢爬上“获取知识的扶梯”。

此外对于迷惘的用户，庞大而单一的重构并没有get到问题的根本。没有一个流程上的根本转变，历史势必会重演。这就是为什么今天是New-And-Shiny™明天就变成了Old-And-Crusty™（译注：从新鲜有光泽到老而暴躁2333）。当公司推迟小的更新直到下一次大重构，这种循环会一直重复。这个过程最终会麻痹公司自身而使用户沮丧。

值得庆幸的是，即使大型的公司也在从小的初创公司身上寻找灵感，努力的进行更快的发布。通过创建更小的可行的产品来向市场经常迭代以提升用户体验，这些公司能更好的解决用户反馈并跟上瞬息万变的web环境。

摆脱 Ron Popeil式的想法，设置并忘记——重构需要在组织架构和工作流程中进行小心翼翼的改变。这说起来容易做起来难。

• 模块化内容：我在一个chunk团队中

当桌面web应用主宰整个web的时候，发布web内容是一项简单的工作。如今，状况改变了。现在，我们的内容被大量的智能手机，非智能电话，上网本，笔记本，平板电脑，电子阅读器，智能手表，电视，游戏机，数字标牌，汽车触控板等所占用。为了恰当地应对这种日益多样化和数字的环境，我们需要彻底改变我们对内容的认知以及用于管理内容的工具。

各个团队认识到有必要创建模块化的内容，以更好地覆盖他们的受众，无论他们身在何处。内容管理系统已经超越了Web发布平台的根基，逐渐发展成为可以优雅地创建和维护模块化内容的工具。多年来，复杂的内容管理系统以自定义解决方案的形式存在，例如NPR的COPE（“创建一次，到处发布”）平台，而智能模块化思想正在进入主流内容管理系统。

• 优雅的代码

正如我们前面所讨论的，模块化一直是计算机科学领域的主要原则。尽管该原则早在Web发明之前就已经存在，但它花了一些时间才根植于Web开发人员的思想和内心。

尽管自1995年以来一直存在，但JavaScript（网络的编程语言）首先必须忍受不断增长的痛苦，才能发展成为如今的有能力，受人尊敬的语言。如今，JavaScript已经发展起来，开发人员可以将这些久经考验的计算机科学原理应用于其Web开发工作流程。结果，我们看到人们在开发复杂的JavaScript模式和体系结构。

将模块化编程原理应用于JavaScript有点麻烦，因为JavaScript本身就是一种编程语言。但是，面向对象的思想也正在融入网络的其他方面，包括CSS，即网络的样式语言。诸如OOCSS，SMACSS和BEM之类的方法已经出现，以帮助Web设计人员创建和维护模块化CSS架构。

• 系统的UI设计

我们不是在设计页面，而是在设计组件系统。 ——Stephen Hay

几年前，Ethan Marcotte向我们介绍了响应式Web设计的思想及其三个核心原则：流畅的网格，灵活的媒体和CSS媒体查询。这三种成分为设计人员创建灵活地适应任何屏幕尺寸的灵活布局提供了急需的基础。也许更重要的是，响应式设计使设计师对创建周到，适应性强的多设备Web体验感到兴奋。

正如设计人员很快发现的那样，创建多设备Web体验所涉及的内容远远超过创建多页面的页面。界面的每个部分都包含自己独特的挑战和机遇，以使其在许多屏幕尺寸和环境下都能美观地工作。

我们如何以周到的方式在较小的屏幕上呈现主要导航（通常在大屏幕上显示为水平列表）？灯箱，面包屑和轮播如何转换为较小的视口和替代输入类型？正是这些问题促使我创建了This Is Responsive，这是响应模式的展示，该模式演示了特定组件在响应环境中的各种执行方式。

尽管“This Is Responsive”成功地阐明了这些界面模式如何在屏幕尺寸和环境之间扩展，但仍然需要设计师和开发人员才能将这些模式付诸实践。事实证明，这需要大量工作。

UI框架的理论与实践

设计人员和开发人员已经被时间和资源所束缚，现在他们面临的任务是使界面在任何环境下都能美观和正常工作。这是一个很高的要求。

满足不断增长的设备多样性的需求，同时仍然明智地开展项目，这产生了诸如Foundation by Zurb和Bootstrap的前端框架。这些用户界面框架为设计人员提供了预组装的HTML模式，CSS样式和JavaScript的集合，以向交互式组件（如下拉菜单和轮播）添加功能。本质上，这些框架是用于快速组装界面的便捷工具套件。

这些框架最吸引人的方面之一是速度。诸如Bootstrap之类的框架使设计人员能够迅速将想法付诸实践，快速创建原型，并尽快启动站点。因为工具包提供的模式已经过跨浏览器测试，所以开发人员可以将时间花在更重要的任务上，而不必费心去测试一些古老版本的Internet Explorer。并且如果设计人员确实陷入困境，这些框架的社区可以提供有用的支持和建议。

对于自由职业者来说，这种速度的提高可能意味着他们可以承担一个或三个额外的项目，从而在一年中产生更大的财务稳定性。在启动世界（Bootstrap无所不在的地方）中，最低限度可行的产品可以更快推出，从而为产品的可行性提供了更快的答案。

• 框架天堂的烦恼

就像现实世界一样，Web项目的各种需求，目标和愿望导致了各种各样的解决方案。当然，所有内容都有时间和地点，设计人员和开发人员需要敏锐的知识才能知道何时使用哪些工具。

前端框架是提供特定解决方案和特定外观的工具。这些解决方案有助于加快开发速度，但最终获得的体验却类似于那些科幻连身裤。当每个人都使用相同的按钮，网格，下拉菜单和组件时，自然就会开始看起来相同。如果耐克，阿迪达斯，彪马和锐步使用Bootstrap重新设计各自的站点，它们的外观将基本相似。当然，这不是这些品牌想要的。当然，每个品牌都可以修改和扩展默认的外观，但是过一会儿定制就意味着要与框架的给定结构，样式和功能作斗争。

除了外观相似的问题外，这些框架还可能给体验带来不必要的膨胀。框架提供了许多预构建的组件和功能，这真是太棒了，但是很大比例的设计人员和开发人员不会采用框架的每个方面。不幸的是，用户仍然必须下载框架未使用的CSS和JavaScript，这会导致页面加载速度变慢并且令人沮丧。

另一方面，框架可能远远不够用，导致开发人员需要创建大量的自定义代码来实现其项目目标。在某个时候，跨越了一个门槛，使用框架的最初收益（即开发速度）被修改，扩展和修复框架所花费的时间所抵消。

既然我们已经将框架付诸实践，那么退后一步并认识到这些框架在概念上非常重要是很重要的。使用设计工具套件来提高一致性并加快开发时间是一个好主意。在讨论位于奥斯汀的网上商店Paravel对Microsoft主页的重新设计时，开发人员Dave Rupert强调了为客户创建和交付设计系统的重要性。Dave明确指出，不一定要为每个客户端使用Bootstrap，而是要为“每个客户端创建微小的Bootstraps”。

这不只是关于使用设计系统，它是关于创造你的系统。

设计系统节省了时间

那么健壮的设计系统是什么样的呢？他们采取什么形式？您如何创建，维护和实施它们？

好的设计系统的基础是样式指南，该指南记录并组织设计材料，同时提供指南，用法和约束。

碰巧的是，样式指南有很多风格，包括关于品牌标识，写作，语音和基调，代码，设计语言和用户界面模式的文档。本书不会详细介绍样式指南的所有类别，但重要的是要仔细研究每种样式指南，以更好地理解每种样式指南如何影响其他样式指南，以及网络样式指南如何适应更大的生态系统。

......

• 代码样式指南

对于团队来说，编写清晰，可伸缩，可维护的代码至关重要。但是，如果没有提高和强制执行代码一致性的方法，事情就很容易崩溃，并使每个开发人员都无法自拔。

代码样式指南提供了有关团队应如何使用其代码的约定，模式和示例。这些准则和约束有助于遏制疯狂，使团队可以专注于共同完成出色的工作，而不是重构一堆草率，不一致的代码。

风格指南的挑战

到现在为止，创建设计系统的好处应该已经很清楚了，希望关于美好的愿景和精美的风格指南在您的头上飞舞。但是要达到风格指导的必杀技，您必须首先克服该领域带来的许多险恶挑战。

• 时间问题

也许最大，最不可避免的挑战是样式指南的创建非常耗时。我不认识你，但我每天都不上班，不停地摇晃拇指，想知道如何处理我的时间。我从未见过一个没有压力的人，这个压力自然导致他专注于主要的Web项目。不幸的是，即使团队致力于此事业，积极的时间表和有限的预算也会减慢制作样式指南所需的精力。

• 维护与管理

即使分配了时间和金钱来建立样式指南，但如果这些宝贵的工具没有给予他们充分发挥其真正潜力所需的重点，它们也常常会死在藤蔓上。

维护和管理策略对于样式指南的成功至关重要。样式指南将丢入垃圾箱（在所有这些PSD和线框旁边），并且在没有适当的策略来管理，维护和执行它们的情况下被丢弃。

• 风格指南结构

为了使样式指南对组织中的每个人都是有用的资源，他们应该清楚地传达自己的含义和重要性。样式指南应有吸引力，引人注目，可见，清晰且易于使用。如上所述，他们应该意识到，将有大量的观众在观看它们，因此，其目标应该是尽可能多地欢迎和有用。

寻找界面设计方法

为了使我们能够为这种折衷的网络环境创造体验，我们必须超越自网络诞生以来一直伴随着我们的页面隐喻。值得庆幸的是，组织在Web创建过程的各个方面都拥护模块化，从而带来了更智能的工作和更可持续的系统。

随着设备，浏览器和环境的数量以惊人的速度持续增长，创建周到的，精心设计的界面设计系统的需求比以往任何时候都更加明显。

（所以让我们）进入原子设计。

小结：本章前面主要表达了我们需要打破固有的页面思想，建立组件化，模块化的前端开发思路，后面讲到了一些设计师的设计思想（由于不是一个前端人员的主要关注点，所以大部分我都省略了），这些思想已经在多年后的今天得以充分在产品开发中运用。最后讲到了虽然市面上有很多流行的ui库，但是我们也需要设计适合自己公司的ui库。我个人认为如果做c端项目的话是需要一套风格鲜明独特的原创ui库的，如果只是做一些后台管理系统或者其他并不是面向大量用户的产品，使用现有的成熟的ui库是很好的选择。正如文中所说，开发自己的ui库需要时间成本，需要考虑兼容性，需要严格测试，需要考虑易用性等等，对于小团队，特别是没有什么中大型公共框架开发经验的团队来说很难。

再及：翻译到正文才发现每一章还是很长的，加之下半年深陷加班泥潭，以我的翻译水平和时间精力还是节选重要内容翻译出来比较合适吧

又及：文中提到了一个用户体验相关的网站值得关注 https://www.uie.com/（需要梯子）

下一章 【译】原子设计2——原子设计方法论(节选)
译文目录在这里： https://www.jianshu.com/nb/47456777