将网站设计文件转换为 HTML、CSS 和 JavaScript 的组合是许多前端 Web 开发工作的核心，但这项工作的一部分并不完全适合任何特定主题的教程。 有一种分解设计并确定如何处理构建的过程，似乎属于前端开发人员在职培训的范畴。 这不是与核心技术一起教授的东西（无论我们在哪里学习这些技术——大学、训练营还是自学）。
在这篇文章中，我们将探讨如何从设计到代码，以及为什么您可能希望遵循这样的流程，而不是直接一头扎进代码——让我们面对现实吧，我们都喜欢这样做！ 本文内容基于我吸纳新开发人员的经验、我们进行过的各种对话以及我在这些情况下提供的帮助和反馈。
从设计到代码的过程成为前端开发人员的核心专业技能的一个原因是，**如果没有某种方法深入研究并预测您将如何处理某些事情，那么很难估计完成它需要多长时间，或者在您开始之前可能需要回答哪些问题。** 许多设计乍一看可能很简单，但一旦深入研究就会很快变得复杂。 我见过这种情况导致过度承诺，这往往会导致更紧迫的期限、压力，甚至更糟糕的副作用。 突然间，一切都需要比我们最初想象的长得多的时间。 糟糕透了。 让我们看看是否可以避免这种情况。
评估设计
为了说明这一点，让我们使用“营销风格”网页的设计示例，并假设我们已被要求实现它。 我们还可以假设此网站是在营销专业人员可以通过某些内容管理系统 (CMS) 来编辑内容、重新排序部分、替换图像并进行样式更改的上下文中创建的。 因此，我们需要确定页面中将用作 CMS 中构建块的组件。
这涉及到另一个可能在教育中被忽略的原因：通常在我们自己的独立项目中，我们可以将静态内容直接放在 HTML 中，并且组件部分不会被陌生人拼凑在一起以形成全新的页面和部分。 但是，一旦您进入更真实的开发环境，情况就会变得更加动态，我们通常在“制作非开发人员可以用来制作网页的东西”这一层面上工作。
让我们以这个临床试验的网站为例。 正如我们所看到的，这里有很多熟悉的设计元素。 营销网站往往共享常见的模式
- 一个大型的英雄区
- 产品图片
- 强调一件事或另一件事的简短内容的小型独立部分
- 关于公司的信息
- 等等。
在移动设备上，我们可以认为在每个部分中，左侧列将堆叠在右侧之上，并且会发生一些其他相当典型的重排。 在移动设备上，结构不会发生任何变化。 因此，我们正在查看的是设计的核心。
在这个示例中，有一个页眉，然后是许多不同的部分，以及一个页脚。 乍一看，一些部分看起来有点相似——例如，几个部分都采用了双列布局。 按钮和标题样式似乎在整个页面中保持一致。 一旦你查看这样的内容，你的眼睛就会开始注意到类似的重复模式。
这就是我们开始做笔记的地方。 在我们进行任何编码之前，让我们先了解设计中包含的想法。 这些想法可以分为几个类别，我们希望我们的最终产品——网页本身——能够正确地体现所有这些想法。 以下是我常用的类别
- **布局级模式**——重复的布局想法和整体网格
- **元素级模式**——标题、文本大小、字体、间距、图标、按钮大小
- 调色板
- **结构化思想**——部分的逻辑组织，独立于布局
- **其他所有内容**——仅存在于一个组件中的想法
以这种方式记录模式有助于确定我们的 CSS 方法，也有助于选择要使用的 HTML 元素，并在某些内容不清楚时与设计师或其他利益相关者进行沟通。 如果你可以访问设计源文件，其中的部分和图层可能会被标记，这可以让你很好地了解设计师的想法。 当你想讨论特定部分时，这会很有帮助。
因此，让我们看看我们的示例设计中包含的想法。 我们将对设计进行多次遍历，并且在所有遍历中，我们都将**从外到内、从上到下、从左到右**进行，以确保我们评估每个元素。 在五个遍历中的每一个中，我们都在寻找放入一个类别中的内容。
我们并不关心这个列表是否完美；它总可以在以后更改——我们只是想记录我们的第一印象。
第一遍：布局级想法
在这个设计中，我们有一些一开始就突出的布局想法。
- 带有水平导航栏的页眉
- 内容区域内的主要内容列——从页眉到页脚的所有部分中的左右边缘对齐
- 具有两列的部分
- 具有单个居中列的部分
- 具有单个左对齐列的部分
- 具有三列的页脚
- 每个部分内部都有相当大的填充
第一印象
我们应该注意在此第一遍过程中产生的任何其他第一印象，无论好坏。 我们永远无法两次拥有第一印象，如果我们现在忽略记录它们，我们的一些直觉反应和问题可能会被遗忘。 此外，在与设计师交谈时，确定您喜欢的特定内容会很好。 它既有助于赞扬好的方面，也将其与其他建设性批评混合在一起。
我们的第一印象可能是以下内容
- 👍 设计简洁美观，易于阅读。
- 👍 所有部分都以问题为标题（很好，有助于吸引读者并为每个部分赋予明确的目的）。
- 🤨 标题中问号的使用不一致（可能是疏忽？）。
- 🙋♀️ 有时，非常相似的字体大小彼此并排出现（可能需要跟进以查看这是否是故意的，因为它看起来不如网站的其他部分那么流畅和专业）。
- 👍 徽标很好看，带有渐变效果。
第二遍：元素级想法
以下是我们在第二遍中可能注意到的内容
- 主要（蓝色）和次要（白色）按钮样式，以及页眉中的“了解更多”按钮，带有一个小箭头（可能是展开菜单？）。
- 标题和副标题样式
- 三种“正文文本”大小（
16px、18px、20px） - 一个“暗模式”部分，其中文本颜色为白色，背景为深色
- “图像和标题”集的一致呈现
- 各种自定义项目符号
- 文本中的内联链接带下划线，其他链接（如页脚中的链接）则没有。
- 一个重复的卡片组件，顶部有一个图标，卡片内部有一个标题和一个列表。
- 徽标在不同的上下文/大小中重复出现几次。
- 页脚包含在其他地方未出现的标题。
第三遍：调色板
在这个设计中，颜色方面没有太多内容。
- 蓝色/紫色主色调
- 浅色/深色正文颜色
- 浅色/深色链接颜色
- 徽标中“hope”一词下方的漂亮渐变
- 浅灰色背景颜色
- 深海军蓝背景颜色
- 特定的红色和绿色“复选标记”和“停止”图标颜色
一些设计工具允许您导出设计文件中使用的颜色十六进制值，甚至导出完整的 Sass 或 CSS 变量声明。 如果您有此选项，请使用它。 否则，请找到自己的方法来获取这些值并为其命名，因为它们是我们初始 CSS 工作的基础。
在我们的 CSS 和其他代码中，我们希望使用诸如“primary”和“secondary”之类的标签或类来引用颜色，以便我们在整个代码中重复使用。 这使得将来更容易调整值，并在需要时添加主题。
第四步：结构化思考
在这个阶段，我们可以用有意义的方式为页面区域命名，并识别内容的层级结构。通过用通俗易懂的语言描述我们所看到的页面内容的**本质**和**结构**，我们可以开始了解实现方案的可访问性需求。一如既往，我们在进行评估时，遵循从外到内、从上到下、从左到右的原则。
专注于结构有助于我们找出最终成为组件的底层模式，也有助于我们理解希望使用辅助技术的用户如何感知内容。反过来，这将指导我们使用哪些 HTML 元素来编写**语义化 HTML**。语义化 HTML 反映了内容的本质和结构，以便浏览器能够正确地感知它。浏览器使用我们的 HTML 创建可访问性树，辅助技术（如屏幕阅读器）利用该树呈现页面。它们需要一个强大的结构大纲才能成功，而语义化 HTML 提供了这种坚实的结构。
这意味着我们需要充分理解页面上的内容本质，以便在没有视觉支持的情况下，也能用语言进行描述。基于这种理解，我们可以反向推导出正确的 HTML，通过可访问性树表达这种理解，可以在浏览器的开发者工具中检查该树。
如果页面上的所有内容都是div，并且元素的选择正确地匹配了内容的本质，那么下面是 Chrome 中可访问性树的一个快速示例。确定特定情况下最佳的元素选择超出了本文的范围，但可以肯定的是，下面所示的富有表现力、非“泛泛而谈”的可访问性树完全是用 HTML 元素和属性创建的，这使得使用辅助技术的用户更容易感知内容及其组织结构。
因此，在第四步中，我们可以做以下笔记：
- 顶级结构
- 页眉
- 主要内容
- 页脚
对于第一次从上到下的遍历来说，还不错。让我们深入一层。我们目前还不关心各个部分内部子元素的内容——我们只需要足够的信息来标记每个部分内部的顶级项目。
- 在**页眉**中包含以下内容：
- 首页链接
- 导航部分
- 在**主要内容**中包含以下内容：
- 英雄区域
- 关于疾病本身的简短说明
- 关于治疗方法的说明
- 试验简介
- 详细介绍试验的说明
- 关于谁可以加入研究的声明
- 参与研究的号召性用语
- 关于公司的简短说明
- 在**页脚**中包含以下内容：
- 徽标
- 总结语句
- 一些带有标题的链接列表
- 分隔线
- 版权声明
这一步揭示了一些信息。首先，页眉和页脚部分比较浅显，已经暴露了链接和文本等原始元素。其次，主要内容部分有八个不同的子部分，每个部分都有自己的主题。
我们将在进行一次遍历，获取这些部分中一些更深层次的细节。
- **页眉首页链接——**太棒了，它只是一个链接，我们完成了。
- **页眉导航——**这是一个展开式悬停导航，需要 JavaScript 才能正确工作。可能有很多可访问的示例可以参考，但与使用原始链接相比，仍然需要更多时间来开发和测试。
- 英雄区域
- 标题
- 第一列
- 副标题（我们在第一遍元素级遍历中错过了这个）
- 段落
- 主要按钮链接
- 次要按钮链接
- 第二列
- 英雄图片
- 疾病说明
- 标题
- 段落
- 无序列表
- 大文本
- 无序列表
- 图片和标题（图和图标题）
- 链接列表
- 治疗方法说明
- 标题
- 第一列
- 段落
- 第二列
- 图片和标题（图和图标题）
- 试验——简介
- 标题
- 第一列
- YouTube 视频播放器
- 第二列
- 段落
- 试验——更多细节
- 标题
- 副标题
- 卡片（带图标、标题和列表）
- “**谁可以加入**”声明
- 标题
- 第一列
- 段落
- 无序列表
- 第二列
- 段落
- 无序列表
- 号召性用语
- 标题
- 段落
- 次要按钮链接
- 关于公司
- 标题
- 段落
哇，内容一下子变多了！但现在我们已经相当了解需要构建的内容类型以及哪些部分可能比较棘手。我们还发现，可能需要构建一些辅助组件，这些组件在这些部分中没有完全体现，例如，一个在移动设备上堆叠成一列并在顶部带有标题的两列布局组件，或者一个通用的“部分容器”组件，它接受背景色和前景颜色，并提供正确的样式以及标准化的内部填充。
顺便说一句，通过这种分解，我们已经很好地表达了我们希望 HTML 创建的最终可访问性树，因此，我们已经走上了实现平滑体验的道路，而无需进行大量返工即可确保可访问性。
第五步：其他事项
此设计中还包含哪些其他想法？哪些内容突出？我们注意到了哪些挑战？可能不多，但这有点像“第一印象”笔记的另一面。现在我们的脑海中充满了关于设计内容的背景信息。
如果现在有什么内容突出，特别是如果它是一个关于某个内容如何工作的问题，请记录下来。例如，“嗯，导航中的‘了解更多’链接应该做什么？”答案可能是：“这是一个指向每个部分的链接列表，当您将鼠标悬停在上面时，它们会打开。”有时，设计师会认为这种事情已经隐含在设计中了，即使它没有明确记录，而且只有在设计审查阶段（在该内容开发之后）才会出现——这通常为时已晚，无法进行修改而不会影响日期和截止日期。
我们现在还应该深入研究并识别任何隐藏的“粘合工作”——例如，整理样式、处理移动端适配、配置 CMS、添加和测试构建块的创作选项和排列方式，以及添加自动化测试。诸如此类。
此时，我们已准备好确定可以在 CMS 中创建哪些组件。也许我们已经从过去的工作中完成了当前系统的一些基本设置。无论如何，我们都有足够的信息来提供对所需工作量的合理估计，并将其分为几类。例如，我们可以对以下组件进行分类：
- 已经 100% 准备就绪（无需开发时间），
- 已存在但需要针对此新目的进行调整（需要**可预测的**开发时间），
- 完全是新的，但路径清晰且安全（需要**可预测的**开发时间），
- 完全是新的，需要进行一些研究才能实施。或者设计不明确，或者某些方面让你感到不安，你需要与利益相关者进行讨论。越早发现这些问题越好。与负责项目的人员沟通。
现在我们有了足够的信息来做出合理的估计。更重要的是，我们减少了项目所需的时间，并限制了可能遇到的麻烦，因为我们从规划中获得了多项优势。
拥有流程的优势
我们采取的确切步骤以及完成的顺序并不是重点。最重要的是了解在开始项目时需要收集哪些信息。您可能对工作如何完成以及完成顺序有自己的想法，任何适合您的方法都很好。
与仅仅直接开始、“让事情运转起来”以及在出现问题时处理问题相比，以下是我在考虑流程的情况下评估设计时意识到的优势。
进行一些额外的探索
尽管我们希望每个项目都能完整地交付，并完美地准备就绪，但实际上，设计中通常包含一些假设，这些假设在实施时可能不切实际，或者与我们关心的其他内容（如可访问性）相矛盾。在这种情况下，您可以提前评估整个项目，并与能够尽早解决这些问题的人员开始沟通。这可以在您深入研究准备编码的部分的同时进行，并将阻止您在稍后构建该部分时遇到这些障碍。尽早提出问题肯定会受到需要解决这些问题的人员的赞赏。
获得他人的帮助
如果没有计划，就很难理解项目完成的进度，以及是否需要帮助才能按时完成。即使您确实需要帮助并且能够寻求帮助，如果没有将工作分解成可以轻松分配的独立的小块，也很难有效地利用额外的帮助。当您有一个合理的计划时，您可以快速委派某些任务，并确信拼图碎片最终会组合在一起。
对于新手开发者来说，认为巨大的工作量和没日没夜的工作是一件好事是很容易（也很常见）的。但是，随着你在这个角色中逐渐成熟，你会发现深入了解项目整体情况，甚至是一张单一工单，更有价值，同时也能给人留下你“掌控全局”的更好印象。尽早意识到时间线看起来不对劲，会让你有机会考虑如何解决它，而不是试图成为英雄，并为此投入一些周末时间。
组件架构流程更顺畅
架构决策对我来说是最糟糕的。命名组件，确定东西应该放在哪里，哪些组件需要相互通信，在哪里将东西分解成更小的组件。很多这些选择只有在我们着眼于更大的图景并考虑某些元素可能被访客和内容创建者使用的各种方式时才有意义。而且很多这些选择都是边际性的——在两个可接受的解决方案之间选择“最佳”方案可能会非常耗时或完全主观。
有一个流程可以帮助解决这个问题，因为你将在深入开发工作之前获得所有或大部分关于设计所需的信息。对我来说，弄清楚我需要制作哪些部分，以及弄清楚制作这些部分的最佳代码，是两件不同的事情。有时我需要的东西并不是代码中最自然产生的东西。有时，在了解了一些需要的东西后，我可以避免花费时间在边际决策上，因为哪些决策真正无关紧要变得更加清晰。
当然，在编写代码时你仍然会学习新东西，但你现在已经为处理这些弹出问题做好了更好的准备。你甚至对可能出现的这类问题有了一个很好的了解。
样式更有意义
在计划工作时，你可以真正弄清楚哪些样式是全局的，哪些是特定于部分的，哪些是特定于组件的，以及哪些是一次性的例外。如果你还没有一个你喜欢的系统来处理这个问题，Andy Bell 的 Cube CSS 与我正在讨论的这种分解非常匹配。这里有一个 视频，Andy 与 Chris Coyier 共同完成了示例，你可以查看更多关于这种方法的信息。
无障碍性从流程早期开始
这一点对我来说非常重要。通过真正理解设计中包含的理念，你将更容易选择语义 HTML 元素并找到合适的无障碍模式来构建你所看到的内容。无障碍性可以融入你日常的工作中，而不是事后才想起来或额外的负担。我们的观点变成了**高质量的前端代码正确地向所有用户表达其内容的性质和结构**，而无障碍性是我们衡量这一点的方式。
经过一段相当短的时间，你会发现设计中有多少遵循一种或另一种已知模式，并且将某些东西分解成已知模式以实现的流程将大大加快。 Carie Fisher很好地总结了与这种“无障碍优先”方法相关的想法。
总结
就像我在开头说的，很多都属于在职培训，“口传”式的网页开发。这是一种你可能在你的第一个前端角色中刚开始时从团队中的高级开发人员那里听到的东西。我相信很多人会有与我不同的优先级，并推荐一个略有不同的流程。我也知道肯定有很多朋友在没有完善流程的环境中工作，也没有高级人员可以咨询。
如果你处于这种情况，或者还没有进入你的第一个角色，我希望这能给你一个基线，让你在思考如何完成工作时可以参照。理想情况下，工作不仅仅是直接上手，把东西放到 div 里，直到看起来“正确”，但这通常是我们的操作模式。我们渴望取得进展并看到成果。
我非常感谢在我的第一份开发工作中有人与我一起工作，他向我展示了如何拆分设计的一部分并估算大型长期项目的工时。这就是激励我开始思考这个问题的原因，并且——当我开始监督其他开发人员和团队时——思考我想如何调整这个流程并使其成为我自己的。我还意识到，在教授使用特定语言的技术技能时，我没有注意到人们谈论过这件事。所以，谢谢，Nate！
还要感谢 Drew Clements 和 Nerando Johnson 对这篇文章提供了早期反馈。你们是最好的。
精彩的文章！我在课程中教授了很多这些理论：卡莫森学院为商科学生提供的网站设计和维护课程。这篇文章将其分解成一个非常清晰的流程。
谢谢，我喜欢那部分的“和维护”，当你只是试图把东西推出大门时，很容易忘记这一点。
哇！……我正在开始我的前端职业生涯，这篇文章……真的教会了我如何让处理设计变得更容易……谢谢。
谢谢 Brian :)
这是网页开发学校中缺少的一门课程。它补充了众多其他有助于使前端网页开发变得伟大的概念。继续努力，Mark！
谢谢 Onyema！
优秀的文章，Mark！
我基本上已经做了很多年了（减去做笔记，我在这方面很糟糕），你真的抓住了这个过程中需要用到的思考方式。
我做设计师已经超过十年了，做开发者也超过一半的时间了，今天让我感到震惊的是，网页设计师没有被教导要具有语义化思维——我们被训练成以“它看起来如何”而不是“它如何工作”的方式思考，不幸的是，大多数工具也是这样工作的。认识到元素分解几乎就是可访问性树，这确实意义深远——页面设计中的每个元素都有一个原因（例如，这个标题提供了上下文，这个图标有助于列表中的视觉区分），并且有一个最好的方法来实现它（例如，标题应该是
h*，图标在语义上可能应该是不可见的）。在设计学校，我们学习了所有关于印刷技术的知识，以及它们的怪癖如何影响海报的最终结果，但没有一个字提到语义或响应式（好吧，“响应式”在我的那个时代还没有出现，但仍然）。而且问题在于，设计师真的不喜欢需要进行更改，因为没有考虑到各种状态（直到我开始开发，我总是会忘记设计表单的“谢谢”状态）。如果表单首先是一个有状态元素的理念能够更好地植入人心，它将为每个人节省大量的时间和麻烦。
好吧，我不再抱怨了。感谢你的文章！
感谢你的评论……我现在实际上认为我完全忽略了这个流程中“寻找未设计的状态”的部分，可能需要添加进去。所有悬停、弹出动画、过渡时间——是的，更不用说感谢信息和错误状态了，这些都是开发人员最终需要处理的东西。有时，如果未设计，做一些合理的默认行为是正确的做法。然后还有一些被过度设计的东西，比如自定义下拉菜单，而它们实际上只是
select元素。是的，我认为值得添加一个关于此的部分。
哇，非常感谢你分享这些，Mark。这很有帮助，流程非常清晰。
这是一篇非常棒的文章。它回答了我一直以来很多的问题。
这篇文章令人惊叹地精彩。非常清晰、精准和详细。文章的信息流非常流畅，层层递进，优雅地堆叠。它立刻激发了你的思考过程——你可以看到自己使用这本“前端圣经”高效地完成下一个项目。
我回来看这篇文章有点晚了，但是嘿，Ellis，非常感谢你留下这个精彩的评论！
非常棒的文章！
我希望能再多一步（一个巨大的步骤），开始进行实现。
我想看到一些方法论应用在这个项目中（例如Cube、BEM或者像Tailwind这样的实用优先方法），以便我们都能看到这个五步过程如何影响我们的代码开发。
为什么它需要JS而不是简单的CSS？
使用纯CSS，大多数这样的菜单都无法以可访问的方式工作，无法为辅助技术提供正确的打开/关闭ARIA状态，也无法正确处理键盘交互。
“许多设计乍一看可能很简单，但一旦深入细节就会迅速变得复杂。”
是的，确实如此。作为一个新手（从新年开始学习），我正在尝试复制一个网站上的导航栏。我以为它很简单，但花了我几天时间才做出来。事实上，我还在继续完善它呢，哈哈。