高效的响应式设计流程

你的响应式设计过程是什么样的？ 你觉得效率高吗？ 以下文章摘自 Ben Callahan 的“响应过程”一章，该章节首次发表在 Smashing Book 5 的电子书版本（目录）中。 ——埃德。

“此 RFP 的成功响应者将为我们的团队评估提供三个静态设计选项。” 我从来都不是采用多选项设计方法的超级粉丝，但我明白了——有时客户需要这个。

“这些选项中的每一个都将为三种独特的布局提供设计：主页、列表页面、详细信息页面。” 好的。 现在，我们最多有九个静态设计文件。 这有点失控了。

“这些独特的页面设计中的每一个都应该考虑到移动设备、平板电脑和桌面设备的尺寸。” 我从来都不擅长数学，但我可以做这个计算。 二十七个静态设计文件？！ 不会发生。

这是我不久前收到的一份真实的提案请求。 事实证明，客户非常愿意采用更有效的方法。 但这次经历真的让我思考......做这些事情最困难的事情并不是真的做这些事情。 当你做这些事情时，它正在与人合作。

你看，几乎每个潜在客户都已经有了一个网站。 对我们来说，这意味着大多数客户都带着一系列期望，以及他们自己过去网络项目的包袱。 这种包袱会对您的客户如何处理项目以及您产生巨大影响。 为了帮助减少这些期望的负面影响，我发现管理它们的最佳方法是成为设定它们的人。

本章的目标是帮助您从头开始，在您的 Web 项目中取得更大的成功； 从第一天开始就帮助设定客户对将要发生的事情的期望，并在项目的整个生命周期中都这样做。

响应式网页设计流程的主要区别

在你打开你最喜欢的文本编辑器之前，在你打开 Macaw 之前，在你拿出你的画板或开始用文本雕刻之前，你需要帮助你的客户理解这个过程。 有很多方法可以做到这一点，我最不喜欢的是尝试在新工艺上销售它们。 根据我的经验，尽早展示你的思维方式的价值——甚至在合同签订之前——是最好的方法。 这让您的客户相信您知道自己在说什么，但这也意味着您需要赢得他们的信任才能尝试新的方式。

为了鼓励这一点，我和我的团队在彼此互动时尽量牢记四个理想：协作、迭代、适应和优先考虑。 让我简要解释一下为什么这些具体的想法会让你保持直截了当。

合作

我知道我知道。 世界各地的每个人都在谈论协作以及如何需要协作才能完成出色的工作。 嗯，你知道吗？ 这是真的。 当然，您需要在团队内部进行协作，但如今还需要另一种协作方式——与您的客户协作。 我有一个重要的提醒：客户也是人。 在网页设计和开发方面，他们可能不具备您的专业知识，但他们比您更了解他们的业务。

同样，它从头开始。 在 Sparkbox，我一直在寻找一种更加协作的方式来吸引新客户。 作为其中的一部分，我们一直在采用一种新的方法来编写估算值。 我们没有让客户来找我们解释他们的项目，这样我们就可以消失一周，然后带着完美的解决方案回来，我们一直在邀请他们帮助我们进行估算。 这非常简单——我们称之为协作估计，客户喜欢它。

我们从一个基本的谷歌电子表格开始，它有一些可调整的字段，并计算我们认为完成这项工作的成本。 我们从广泛的范围开始，因为我们在这个过程的早期就这样做了——通常在 30 分钟的电话之后。 然后我们与客户分享它，我们一起努力。

这就是为什么这很重要：我们首先与客户合作。 我们希望他们知道，当我们与他们合作而不是为他们工作时，我们会增加更多价值。 这只是我们把钱放在嘴边的一种方式。

我们还邀请我们的客户加入我们与我们的团队沟通渠道。 我们是 Slack 和 Basecamp 的忠实粉丝。 这些工具提供了正式文档和非正式对话的完美组合，这两者都是促进高质量协作所必需的。

在 Daniel Mall 对 Reading Is Fundamental 网站的公开重新设计中，我们都看到了 Dan 如何将他的客户带入他的项目中。 Brad Frost 在 GitHub 项目中更进一步，名为“Project Hub”，这是一个跟踪项目进度的工具。

请记住，这些都只是工具。 工具可以提供帮助，但真正需要的是改变我们的思维方式。 我的朋友 Kevin Sharon 曾经对我说过一些非常尖锐的话。 他说，“如果你不能说‘不’，那就不是合作。” 我不了解你，但我与客户有过很多关系，我无权拒绝——即使我从经验中知道他们的要求是行不通的。 这些客户向您提供解决方案，而不是需要解决的问题。

我很惭愧地承认这一点，但我也有过相反的客户关系。 有时我的挫败感会变得更好，我忘记了我需要我的客户成为项目的一部分。 当我们从客户那里听到一个想法并立即不同意时，我们就和他们否认协作过程一样内疚。 许多网络工作室不愿意在他们的过程中允许这种协作，通常是因为他们不相信他们的客户有足够的创造力或技术来以有意义的方式做出贡献。

合作是一条两条路。 将您对客户的看法转变为让他们成为您工作中真正的贡献者，这将导致各种新的方式来包括他们并帮助您创建更好的产品。

迭代

我们定期寻找机会以极快的速度交付一小部分高质量的功能子集。 采用这样的方法可以尽早展示进步，并提供真正的机会，让您所学的知识为您完成项目创造动力。

如果您觉得改变客户的工作方式可能存在政治挑战，这里有一个专业提示（我在我们所做的每个项目中都感觉到这一点）：迭代工作可以帮助将怀疑者变成拥护者。 大多数人更有可能让你在一个小阶段尝试一种新的工作方式，而不是整个项目。 同样，这里的重点是尽早展示您的价值以赢得客户的信任。

迭代表现出来的一种方式是原型设计。 我们一直在寻找机会来识别重大挑战，提出可能的解决方案，通过原型设计、修改和重复来证明或反驳其有效性。

我们通常会在开始大型项目之前寻找机会从付费发现阶段开始； 把它想象成结婚前的约会。 这使您有机会更多地了解该项目以及与该客户合作的感觉。 双方都能够确定工作关系是否合适。

初步接触可以采取多种形式，但主要目标是：

1. 更好地了解项目的范围
2. 确定并证明最大挑战的可能解决方案
3. 弄清楚客户/供应商是否合适
4. 证明你有能力
5. 获得上述报酬

您的客户会喜欢这种方法，您将为未来的工作打下良好的基础。 如果你学到的东西会极大地改变你对项目的理解，你只会致力于一个小阶段。 这种学习将极大地通知该过程的下一步，并推动您找到更好的解决方案。

我们有一个合作多年的客户； 事实上，我们最近与他们开始了第三十个项目。 对我来说，这表明我们找到了一种互惠互利的合作方式——他们看到了我们提供的价值，我们对与他们的合作在创造性和技术上都感到满意。 在试图确定是什么使这种关系成功时，我不断地回到我们的迭代方法。 有很多次，他们向我们提出问题和解决问题的想法。 我们不只是放弃可能需要 12 周的项目，而是定期建议较小的迭代阶段，以测试可能的解决方案并且初始投资要低得多。 采用这种方法使我们赢得了他们的信任。 这种信任对于建立可持续的关系是必不可少的，而迭代是这一切的核心。

适应

当响应式网页设计出现时，我记得当时被我们正在构建的产品中固有的灵活性正在融入我们的流程的想法所震惊。 Samantha Warren 说得最好：“您的流程应该与您设计的产品一样具有响应性。”

事实上，这种工作没有完美的流程。 你和我需要接受我们所面临的限制。 每个项目、客户、范围、时间表、预算、团队、技术堆栈、支持矩阵都是不同的。 在这项业务中取得成功的组织是那些可以在项目限制内工作并且仍然可以完成永恒工作的组织。

我对流程的看法显然很难向客户解释。 如果有机会，我可能会将参与该项目的几个关键人物（包括客户）锁在一个房间里几个星期，并授权他们解决这个问题。 听我说，客户不喜欢一次被锁在一个房间里几个星期。

相反，我们必须在非常严格的流程（每个步骤都被布置和记录）和即兴的流程（我们相信团队会在他们进行时找到最佳方法）之间找到平衡。 要找到这种平衡，需要考虑许多因素。 这里有三个开始：团队的规模； 团队的经验； 以及项目的重要性。

团队规模

当您拥有一个非常小的团队时，在流程中允许很大的灵活性要容易得多。 坐在同一个房间里的两三个人将能够在没有大量结构的情况下跟踪正在发生的事情。 将团队规模扩大到六七人，就开始难以理解每个参与者对整个项目进度的影响。 将您的团队增加到十个、十五个或更多，这几乎是不可能的。

这对我来说非常个人化。 当我第一次和我的合作伙伴一起创办 Sparkbox 时，我们只有四个人。 我们每个人都有一个相当明确的角色，我们能够在没有太多流程的情况下相当有效地运作。 因为我们都坐在一个大房间里，所以就我们业务的各个方面进行了不断的交流。

现在，我们有 23 名全职员工，外加 3 名学徒。 我们当然没有像某些地方那样快速成长——我们对我们的成长非常谨慎——但“成长的痛苦”这句话仍然是正确的。 我们不得不不断试验何时、何地以及如何沟通。 只有通过这个实验，我们才能找到适合我们的平衡点。

这里的教训是，您的团队规模会影响您可以为给定项目采用的流程类型。 一般来说，一个项目的人越多，你需要的刚性就越大。 随着团队规模的缩小，您可以采用不那么正式的流程。 您的项目经理有责任监控团队的脉搏并调整流程以使事情顺利进行。

团队经验

当您与经验不足的团队合作时，更严格的流程将有助于让每个人都保持一致。 事实上，我相信一个缺乏经验的团队需要一个具体的过程作为获得经验的背景。 只有在更严格的环境中展示成功后，您才能开始剥离流程层，让团队在工作方式上拥有更多自由。

这对我来说也是一个相当个人化的概念，主要是因为我们如何为项目组织团队。 我们为每个项目组建了一个独特的团队； 即使在项目过程中，我们也有可能将人员轮换进出团队。 这可能会带来挑战，尤其是当这些人的经历截然不同时。 大多数情况下，这意味着我们需要意识到不同的人需要不同级别的过程才能成功。 我们的项目经理密切监控并根据需要进行调整。

我们有很多经验丰富的设计师和开发人员，所以这种平衡主要是为了分散经验不足的人。 将一两个新开发人员添加到一个高技能团队将提高每个人的标准。 新开发者将向更有经验的人学习，而更有经验的人将通过教导新开发者来学习。 这样才能双赢！

项目的关键性

该项目的重要性的想法来自一位名叫 Alistair Cockburn 的绅士，他是敏捷宣言的原始签署人之一。 在他关于“水晶方法”的著作中，科伯恩通过完成这一陈述来描述临界范围。

缺陷会导致以下损失：

1. 舒适度（非关键）
2. 可自由支配的钱（有点关键）
3. 基本货币（关键）
4. 生活（非常关键）

我们的产品越关键，我们的流程就应该越严格。 如果您曾为小型和大型企业工作过，您可能会经历过这种情况。 小型本地公司倾向于让您在工作方式上拥有更多自由，因为它们的风险较小（关键性较低）； 如果您的流程没有产生良好的结果，大公司将失去更多（更高的关键性）。

当我刚开始从事这个行业时，我几乎只与当地的小型企业合作。 我每隔一周用便笺、电子邮件和电话管理项目。 现在，我参与了更大的组织。 管理这些项目需要我们参加日常站立会议、回顾会议和 sprint 计划会议。 我们发现自己在构建燃尽图，在 JIRA（问题跟踪软件）中工作，计算我们的速度比我愿意承认的要多。 所有这一切都是因为工作的重要性——足够大的数字中的一小部分仍然是一个巨大的数字。 这些大公司明白这一点，并且他们有适当的流程来保护他们免受那些巨大的损失。

优先

随着我们设计的屏幕尺寸减小，我们的沟通优先级选项也随之减小。 想一想：我们通常使用大小、位置、顺序和对比度之类的东西来帮助用户了解他们应该关注的地方。 在小屏幕上，您可以对对象的大小或标题的位置做很多事情。 当我们专注于大屏幕体验时，我们根本没有同样的自由。

因此，了解整个系统中内容和功能的优先级至关重要。 Luke Wroblewski 出色地鼓励我们首先考虑移动设备，以帮助我们的客户了解真正重要的事情。 事实是，如果没有对优先级的深刻理解，响应式网页设计只是猜测。

我们通过让客户在流程的早期进行线性思考来鼓励他们这样做。 （在下面的“完成它”部分，我将分享我们用来执行此操作的各种工具。）线性思考的好处是要求人们选择最重要的事情，而您需要就这一优先事项达成一致。 在您的项目中直接建立这一点将奠定一个公认的基础，并为您在项目后期会发现的许多问题提供答案。

我们最近有一个项目，我们的客户带着已经组装好的宽屏线框来找我们。 他们这样做是为了节省一些钱，我们很高兴尝试以这种方式与他们合作。 当我们开始设计时，客户对我们的工作并不满意。 直到项目进行到一半，我们才意识到宽屏线框无法充分识别内容和功能的优先级。 这是我们遇到的问题的症结所在。 我们最终回去进行一些内容分析和优先排序，以重新获得项目的动力。 如果我们早点这样做，我们可以在整个项目中更有效地工作。 不幸的是，为了帮助他们省钱，我们不得不进行一些返工，如果我们先打好基础，这些返工是可以避免的！ 经验教训——尽早确定优先级。

四个理想

当您进入下一个项目时，请记住您需要将您的客户包括在项目中。 寻找与他们合作的机会，而不仅仅是为他们工作。 请记住，您越早展示价值，您将获得越多的信任。 迭代可以帮助您做到这一点——不要害怕从小处着手！ 此外，请记住，您肯定必须调整自己的工作方式，以更好地适应特定项目或客户的需求。 最后，努力在项目早期确定内容和功能的优先级。 当出现有关某些内容的重要性的问题时，这将在项目后期产生红利。

除了这四个理想之外，我想为您提供一些框架，让您考虑什么样的流程将在您的日常工作中发挥作用。

考虑过程的框架

我们的流程总是在为它的生命而战

对于大多数演示文稿或有关过程的写作，让我感到惊讶的一件事是，分享的人似乎有多么自信。 也许我们是异类，但我们的过程总是在为它的生命而战。 如果出现新的工作方式，我们会尝试。 如果我们认为甚至有更好的方法来做某事，我们将四处挖掘试图发现它。 这就是我们的接线方式。 我感觉你们中的很多人也有这种联系。

让我们同意我们的过程永远不会完成。

远离线性交接

业内大多数人都同意我们必须停止将可交付成果扔到墙上。 取而代之的是，许多人正在考虑如何重组他们的团队，希望在项目期间让合适的人参与进来，这将增加队友的同理心并提高每个人的标准。 特伦特沃尔顿在他名为“重组”的帖子中雄辩地描述了这一点。 在其中，他提到您的团队结构通常会限制您可以使用的流程类型，并鼓励我们考虑较小的跨学科团队。 我们已经看到这是真的，并采取了非常相似的方法。 说实话，我们过去的线性过程可能总是有点低效。 我相信响应式网页设计只会让这种低效率变得更加明显。 处理响应式工作使我与我们的客户围绕他们的组织结构进行了对话——更多的证据表明 RWD 确实是组织变革的催化剂。

我们需要为更多的项目涉及更多的学科。 我喜欢把这看作是一个项目的螺旋式发展，我们的眼睛坚定地专注于最终产品，一个可交付成果。 随着每一次螺旋式发展，我们涉及所有学科，并且我们在所有决策点都变得更加清晰。 这个概念很简单：让整个团队在整个项目期间发挥作用。 换句话说，承认并接受在项目的一个领域进行更改对其他领域的影响。

由于我们与我的一位商业导师的互动，我和我的团队达成了这个想法（通过一个项目螺旋上升）。 他的名字是杰夫，他是一个非常敏锐的人。 他曾担任一些相当大的组织的首席财务官，并以帮助有远见的领导者掌握公司财务状况为职业。

当我们第一次见到杰夫时，我们正处于危机模式。 我们面临着一个重大挑战，我的合作伙伴和我都不知道如何应对。 杰夫让我们都坐下来，要求我们“以终为始”。 他希望我们解释在我们度过未来的困难时期之后会是什么样子。 他希望我们为公司生命中的这段时间定义成功。 当我们继续与杰夫见面时，我开始感到沮丧。 每次我们坐下来，我都希望他能给我们一些建议，让我们开始解决我们面临的问题。 相反，他不断地提出越来越多的问题。 这种情况持续了几个星期，这对我来说是一段艰难的时期。

我永远不会忘记我与 Geoff 和我的合作伙伴的会面，这一切都开始变得有意义。 我们的会议像其他人一样开始了。 我们回顾了当前对摆在我们面前的问题的理解，并花了一些时间分享我们获得的任何新见解。 只是这一次，我们每个人都开始看到解决方案的出现。 它不是很清楚，但它开始成为焦点。 在我们考虑的三个选项中，一个开始看起来比其他的更有吸引力。 我们在过去几个月中学到的知识明确无误地引导我们找到了解决我们面临的问题的最佳选择。

这一课对我来说是无价的。 它告诉我的是，线性过程要求我们在获得所有信息之前做出决定。 如果不考虑视觉设计，我们怎么可能知道创建一组线框所需的一切？ 我们如何在不尝试一些前端代码的情况下完善界面设计？ 当我们表现得好像可以从内容开始，然后做一些用户体验设计，然后做一些用户界面设计，等等，我们忽略了这些交付物对其他交付物的影响。 相反，我们需要让他们互相通知。 我们需要给他们空间来呼吸、调整，并利用从项目中学到的东西来推动他们前进。

这正是 Geoff 推动我们经历的螺旋式过程。 那几周的提问让我们了解了这个问题。 Geoff 没有做出决定（批准 UI 设计）并继续前进，就好像它永远不会改变（好的，前端开发人员，去编码这个设计），Geoff 迫使我们认识到我们没有我们需要的所有信息做出最好的决定。 杰夫希望我们等到“最后一个负责任的时刻”再做决定。

我试图将这种螺旋式上升的想法转化为我们每天所做的事情，并且我已经实现了这样的可视化：

请把你自己的学科放在上面的饼图中——图像被简化以说明方法。 需要注意的是，这些点并不是传统意义上的可交付成果。 它们代表了您与客户坐下来审查您在“一个可交付成果”方面的进展的机会。 这意味着：停止完善可交付成果，以免让您的客户失望。 当白板上的草图可以做到时，让您的线框在 Illustrator 中看起来很漂亮是非常低效的。 我们甚至不再称它们为可交付成果，而是开始称它们为更新。

这种工作流程足够灵活，可以用于任何类型的项目，因为您可以简单地更换项目所需的学科类型。 根据相关人员的经验，围绕该过程的仪式可以变得更严格或更即兴。 关键是要确保所有人都参与其中。

这种方法会延迟决策，直到您获得正确的信息。 它承认一个学科做出的决定无疑会影响其他学科。 它开启了与团队的对话，并需要所有相关人员的支持。 它不那么正式，但更有效。 它不太可预测，但我相信它有可能提供更好的产品。

让我们同意我们需要寻求多学科的贡献。

效率是关键

如果我们有足够的时间在世界上，我们就不必担心我们的过程——我们可以尝试一些东西，直到我们偶然发现一个好主意。 你和我都知道事实并非如此。

我们在 Sparkbox 对流程所做的许多调整都是因为我们正在寻找一种更快的方式来完成某件事。 提高速度的承诺也是我们如何获得机会与更大客户的一些非常有才华的内部团队合作。 每个人都在寻求效率提升。

让我们同意一个好的过程也是一个有效的过程。

不断发展。 多学科。 高效的。 当我们深入了解这些东西的具体细节时，我希望我们牢记这三件事。 我们可以将这些想法用作我们考虑新方法的过滤器。

足够的理论

理论就够了。 让我们深入了解这项工作的具体细节。 我发现自己在我们的网络项目中不断地问三个问题：

1. 我们为谁建造？
2. 我们希望他们从经验中获得什么？
3. 我们应该如何呈现体验？

目标是找到一种方法，以正确的方式（如何）向正确的人（谁）说正确的事情（什么）。 任何形式的良好沟通的秘诀就是回答这些问题。 当然，您会在整个项目中提出许多其他问题。 我应该在这个网站上使用什么样的导航模式，或者我们真的需要在每个页面的顶部放置广告？ 我的建议是，当你回答所有其他出现的问题时，回答谁、什么以及如何引导你朝着正确的方向前进。

希望您已经阅读了 Dan Mall 的章节（就在这一章之前）。 在其中，他做得很好，提供了一些关于了解您正在与谁交流的背景信息。 他对面试和启动会议的解释将使您坚定地朝着正确的方向前进。

同样，Eileen Webb 的下一章是关于响应式项目的内容策略。 这是一个详尽的章节，她回答了关于我们正在努力沟通的问题，比我以往任何时候都更好。

因此，本章的其余部分致力于回答第三个问题，“如何？” 我将与您分享对我和我的 Sparkbox 团队最有帮助的各种工具，并相信它们也会对您有所帮助！

完成它

正如我之前提到的，了解我们呈现的内容和功能的优先级对于有效沟通至关重要。 以下是这一真理在我们所做的工作中体现出来的几种方式。

内容优先级指南

内容优先级指南是“部分内容建模，部分精简线框”（参见 Emily Gray 的“内容优先级指南”。）； 像一个迷你内容模型，按优先顺序排列，并与客户协作。 （有关内容优先级指南的工作示例，请参阅 https://bit.ly/content-priority-guide。）

内容优先级指南告诉您每个页面上应该存在哪些类型的内容。 这些可以是简单的东西，例如博客文章的标题、主要图片和正文，也可以更复杂：考虑电子商务网站的产品详细信息页面上可能需要的所有内容类型。

它还允许解释每种内容类型。 如果您对产品有简短的描述，优先级指南可能会说：“用一句话描述产品以及它的独特之处。” 对于像英雄图像这样的项目，如果与特定案例相关，您可以提供有关照片艺术方向的一些详细信息。

内容优先级指南还可以帮助您快速识别可重用组件。 当您计划管理该内容时，这非常有帮助 - 识别可重用模式意味着您可以构建一个更有效的系统来管理内容。

最重要的是，优先指南是按优先顺序排列的。 它引发了关于任何特定页面上真正重要的讨论。 当您考虑网站将如何响应视口宽度时，这将大有帮助。 而且因为它不包含实际内容，它有助于就内容类型的内容和原因进行很好的对话，如果您立即开始编写副本，很容易被忽略。

如果您的客户难以确定优先级（他们可能会），您可以将这些决定围绕最重要的事项放入电子表格中，并为他们提供检查选项 - 主要、次要、第三等。结果是相同的：您有一个每个页面的内容类型的优先列表，但是如果给客户一些选项，到达那里的过程可能对客户更友好一些。

信息架构

一旦您对系统中需要存在的内容的类型和优先级有了很好的理解，就必须考虑如何对内容进行分组以及您希望用户采用的内容路径。 这种想法对于创建可用站点至关重要。

我最近看到 Aaron Quinn 谈到信息架构，他说了一些让我印象深刻的话。 他建议，在对信息进行分组时，我们可能过于依赖常识。 相反，他让我们在规划我们的用户将如何与我们构建的内容交互时考虑共识而不是常识。 让我用一个简短的故事来解释原因。

我们有一个合作了一年多的客户。 她引导了我们帮助她构建的非常成功的 SAAS 产品。 这个女人非常聪明； 她每天都在网上工作——这就是她谋生的方式。 不久前，我正在和她讨论她的产品下一步是什么，她对我说：“我认为我们需要对我们网站上的标签进行一些更改。” 我停了下来，因为我拼命想记住我们在她的网站上实现标签的位置。 感觉到我的困惑，她继续解释了更多关于她所希望的事情。 过了一会儿，我意识到她在谈论导航。 这位精明的网络企业家将她的导航称为“标签”，这令人大开眼界。

我告诉你这个是因为我想让你记住当我们让我们的直觉驱动我们做出的决定时，我们生活在多大的泡沫中。 What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

Let's agree that a good process is also an efficient process.

Ever-Evolving. 多学科。 高效的。 As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.

Enough Theory

理论就够了。 Let's get into the nuts and bolts of this work. I find myself constantly asking three questions throughout our web projects:

1. 我们为谁建造？
2. What do we want them to gain from the experience?
3. How should we present the experience?

The goal is to find a way to say the right things (what) in the right way (how) to the right people (who). The secret to great communication of any kind is answering these questions. You will, of course, ask many other questions throughout your project. Questions like what kind of navigation patterns should I use on this site, or do we really need an ad at the top of every page? I'm suggesting that having the answers to who, what and how will lead you in the right direction as you answer all the other questions that come up.

Hopefully, you have already read Dan Mall's chapter (just before this one). In it, he does a great job providing some context around understanding who you're communicating with. His explanations of interviewing and kick-off meetings will move you solidly in the right direction.

Similarly, the next chapter by Eileen Webb is all about content strategy for your responsive project. It's a thorough chapter, and she answers the questions around what it is we're trying to communicate better than I ever could.

So, the rest of this chapter is dedicated to answering that third question, “How?” I'll share with you the kinds of tools that have been the most helpful for me and my team at Sparkbox and trust that they will also help you!

完成它

As I mentioned earlier, understanding the priority of the content and functionality we're presenting is critical to communicating effectively. Here are a few ways this truth manifests itself in the work we do.

Content Priority Guide

A content priority guide is “part content modeling, part stripped-down wireframe” (see “Content Priority Guide” by Emily Gray.); like a mini content model, in priority order, and with client collaboration. (See https://bit.ly/content-priority-guide for a working example of a content priority guide.)

The content priority guide tells you what types of content should exist on each page. These could be simple things like the title, primary image and body copy on a blog post, or they could be much more complex: consider all the content types you might need on the product detail page of an e-commerce site.

It also allows for explanation of each content type. If you have a short description of a product, the priority guide may say, “One sentence describing the product and what makes it unique.” For an item like a hero image, you could provide some details about the art direction of the photo if that was relevant for a specific case.

Content priority guides also help you quickly identify reusable components. This is very helpful as you plan out the management of that content — recognizing reusable patterns means you can build a more efficient system to manage the content.

Most importantly, a priority guide is in priority order . It provokes a discussion about what's truly important on any specific page. This helps tremendously as you consider how a site will respond across viewport widths. And because it doesn't contain actual content it facilitates great conversation about the what and why of types of content, which can easily be overlooked if you start writing the copy immediately.

If your clients have difficulty prioritizing (and they probably will), you could place these decisions around what is most important into a spreadsheet and give them options to check — primary, secondary, tertiary, etc. The result is the same: you have a prioritized list of content types for each page, but the process to get there may feel a bit more friendly to the client if they're given some options.

信息架构

Once you have a good understanding of the types and priority of content that needs to exist in the system, it's critical to consider how that content should be grouped and the paths through the content you want your users to take. This kind of thinking is crucial to the creation of a usable site.

I recently saw Aaron Quinn speak about information architecture and he said something that really stuck with me. He suggested that we might be relying too much on our common sense when it comes to grouping information. Instead, he made the case for us to consider consensus over common sense when planning how our users will interact with what we build. Let me explain why with a quick story.

We have a client we've been working with for over a year now. She has bootstrapped a very successful SAAS product which we helped her build. This woman is incredibly smart; she works on the web every day — it's how she makes a living. Not too long ago, I was having a conversation with her about what was next for her product and she said this to me: “I think we need to make some changes to the tabs on our site.” I paused because I was desperately trying to remember where we had implemented tabs on her site. Sensing my confusion, she went on to explain more about what she was hoping for. After a few moments, I realized she was talking about the navigation. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

During some recent usability tests, I noticed that on small screens many users never attempted to locate or use navigation. These days, most of our small-screen navigation experiences are hidden behind obscure icons (hamburger, anyone?). I believe our expectation that users will properly identify, trigger and use our navigation is unfounded.

In an effort to combat this, we've begun considering a simple question — can someone use this site without the navigation?

Literally, remove the navigation from your site and see if your users can reach the content they want. In other words, plan out the content in such a way that your users can feel their way through the experience. Chances are, a good number of them will browse this way. We'd better be ready for them.

Style Comparisons

I learned about style comparisons when I had the opportunity to present with Dan Mall and Yesenia Perez-Cruz at Artifact Conference in Austin, Texas. Dan shared a story about how he was working to build a new office. Here's the relevant excerpt from his blog post:

“I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn't take advantage of his [the contractor's] great ideas. It's dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials, and we can have a conversation. I revise my ideas through his expertise, and vice versa. This is how building a website should go.”

Not only is this a brilliant approach to building a new space, it can be applied directly to what we do each day. Our creative director, Jeremy Loyd, has been creating super-simple PDFs for our clients that ask them whether they think their brand would best be represented online with:

• A dark or a light site
• A flat or a textured site
• An illustrated or photographic site
• Whatever other style comparisons are relevant

你明白了。 The point is that it only takes a few minutes to put this together, because it doesn't really require any design. You can use screenshots of existing sites that embody the qualities you have questions about.

An approach like this is very useful when there isn't much clarity about the design direction up front. It helps us make sure we're in agreement about the direction we're headed. Truthfully, this is really just a simple tool to facilitate a conversation, to get people thinking and conversing about design.

One other trick from my friend Dan Mall which you can use to really drive this home is to quickly edit your client's logo into a screen capture of someone else's site. There is something about seeing their brand associated with a specific style which provokes a reaction. This makes for very fruitful conversations.

用户体验设计

No title in our industry is more overloaded and misunderstood than “user experience designer.” It means so many different things to so many different people. Recently, I've even noticed a trend toward expecting all designers and developers to do this work. And while I believe the best organizations have teams full of people who care about user experience, I also believe it has a deeper role to play.

I think about user experience as the glue that binds our design and our development together. It's what separates web design from other kinds of design — that our work is intended not only to be observed, but also to be interacted with. That interaction is so important. In my mind, a great user experience designer has an instinct for what will be easy for a user to understand. However, this must be balanced with the idea that design without testing is guesswork . For this reason, a great user experience designer knows how to research their users, how to collaborate with UI designers, how to prototype possible solutions, and how to select and execute usability studies to capture and analyze data which properly informs design and development.

好多啊。 And since I'm not formally trained in user experience or human factors, I'm probably not qualified to write about each of those things. Instead, I want to focus on one lesson I've learned (see “Test the Aggregate”) and then share the kinds of updates we do with our customers to help us all agree on usability decisions across screen sizes and input methods.

Test The Aggregate

I work with internal user experience teams at larger clients, and one challenge I'm continually presented with is the desire to test the experience they are building at individual breakpoints. In other words, I've seen teams create three (or more) separate prototypes — for mobile, tablet and desktop — and then proceed to test each one independently. When this happens, each of these separate experiences will evolve on its own, usually resulting in three unique experiences which will be very difficult (if not impossible) to build in a responsive way.

To combat this, lately I've shared how critical it is to test the aggregate experience. Instead of building three separate prototypes for usability studies, build a single prototype with HTML and CSS that actually responds. We usually do this statically with an evolving set of front-end build tools (you can learn more about our front-end stack in the article “We Heart Good Tools: An Update on Our Build Process”) which means we can work quickly with fake data.

This concept is about letting go of the control you think you have. It's about making decisions which benefit the whole (the aggregate) even though they may require compromises in certain contexts. It recognizes that changes made at one of the breakpoints in your system will inevitably affect the experience at other breakpoints. It's about embracing the benefits you get with a single code line and adjusting our usability studies to account for this.

如果我们正在构建响应式，我们需要专注于测试跨视口宽度的单站点解决方案。 我们需要衡量整体的可用性，而不仅仅是断点。 这将帮助我们为大多数人创造最有用的体验。

现在，我们与客户一起使用一些更新来帮助实现这些目标。

内容原型

你听说过网页设计师应该学习一些 CSS，对吧？ 好吧，我同意，我认为内容策略师应该学习一些 HTML。 出于这个原因，以及许多其他原因，我们在 Web 开发过程的早期就一直在构建内容原型。 一旦我们开始清楚地了解实际内容，我们就开始用超文本标记该内容。 这就是我们对 HTML 所做的，对吧？ 谁能比最了解内容的人更好地将内容包装在语义标签中？ 虽然像 Markdown 这样的工具也可以工作，但我认为最好在直接跳到 Markdown 之前学习一些基本的 HTML。 理解为什么要以这种方式编写内容与实际编写 HTML 一样重要。 像 Markdown 这样的工具在你的动作和这些动作的输出之间添加了一层抽象——一旦你理解了它给你的东西，这个抽象就很好。

当我们创建内容原型时，我们有意省略了几乎所有样式。 我们把它们留得很丑，所以很明显我们没有设计任何东西。 这使对话集中在内容和该内容的优先级上。 要知道，当您将其展示给客户时，他们会立即了解事情的顺序——这正是您希望他们做的：正确地获得优先权！ 此外，我们通常只包含足够的 CSS 来显示分组，如下所示：

我告诉过你这很丑。

我们还用链接填充我们的内容原型。 我们创建这些的原因之一是允许人们从一个页面导航到另一个页面，以查看内容的流程是否有效。

请记住，您必须让您的客户为看到这种丑陋的更新做好准备。 否则，他们肯定会重新考虑让您参与他们的项目。 但是，在浏览器中查看标记的原始内容具有强大的功能。

一个重要的注意事项：我们认识到纯粹的语义标记可能不会用于生产。 虽然这将是理想的，但今天在网络上工作的现实是，它需要由具有广泛不同技能的个人和团队维护和扩展。 然而，从这个纯粹的标记版本开始是一种提醒我们理想的绝妙方式。 然后，当我们调整标记以考虑样式、可重用性、可扩展性等时，我们非常清楚我们所做的每一次更改都会使我们偏离理想。 每一次改变都是一种妥协，在做出改变之前应该深思熟虑。

静态线框

在过去的几年里，人们对更传统的静态线框颇有反感。 我相信他们仍然可以增加很多价值。 我也相信并非每个项目都需要它们。 当我们使用它们时，我们通常以较窄的宽度来使用它们——尽管这样很不方便——以帮助我们专注于优先级。 限制我们的视觉空间迫使我们关注这一点。 我们使用了很多工具来做到这一点，从 Keynote 到 Balsamiq。 老实说，这些工具中的任何一个都可以完成这项工作。 找一个你觉得舒服的，然后开始工作。

我们也做了很多素描。 白板，铅笔和纸，各种素描应用程序。 我们拍下这些东西的照片并与我们的客户分享，故意保持它们非常原始。 原始是我们所做工作的重要组成部分。 它可以帮助我们的客户知道我们不会浪费时间润色不会从润色中受益的文档，并且可以使反馈保持集中。 我们想要的最后一件事是有人评论我们线框的颜色。

交互式线框

远离更传统的线框的部分原因是支持更具交互性的方法。 就像敏捷宣言提倡工作软件优于文档一样，我们行业中的许多人认为，通过原型展示你的交互意图比试图静态地描述它要强大得多。 如今，可用于快速原型制作的工具非常强大：Bootstrap 和 Foundation 等框架； CSS（或 Sass 和 LESS）工具包，例如 Bourbon 和 Pure CSS； InVision 和 Marvel 等视觉原型制作工具。 甚至像 Macaw 这样的视觉网页设计和开发工具或像 Keynote 这样的演示工具也可以用来创建非常互动的线框。

这种方法的好处是你可以向人们展示这个想法，而不是试图向他们解释。 如果一张图片值一千字，那么一个原型就值一千张图片。

我们现在正在与一个了解这一点的组织合作。 他们的目标之一是在他们的流程中更早地引入快速原型设计，以便他们可以将原型用于可用性研究以及生产代码。 我们与他们合作的重点是创建一个组件系统，该系统可以在他们的所有网络资产中使用。 该系统最终也将用于允许他们的团队非常快速地构建交互式线框。 因为我们将根据他们的品牌构建它，所以交互式线框看起来非常像他们的生产版本，这将极大地有助于他们的 UX 测试。

这种方法侧重于网络资产的长期成功。 它体现了我们之前谈到的“一个可交付”的工作流程，让所有学科都参与到原型的创建中，并允许在设计和开发过程中学到的知识为进一步的决策提供信息。 我相信我们正在看到组织转向构建成熟的前端系统，而不是事后才将 CSS 组合在一起。 让组织能够与真实用户一起测试其 Web 工作的静态版本是朝着在不久的将来巩固这一标准的重要一步。

用户界面设计与开发

“好的设计就是解决问题。”

— 网页设计的艺术与科学，Jeffrey Veen (2000) 。

对于你们这些设计师来说，这句话听起来很真实。 许多人将我们所做的视为装饰，但它远不止于此。 在过去的几年里，我发现自己完全同意 Jeff 的观点，但也强烈地意识到设计师倾向于过度完善他们的解决方案。 这将我引向我所说的“切换点”。

如果你把设计活动分成三个阶段——建立审美、解决问题和完善解决方案（如上所示）——从解决问题到完善解决方案的转变就是转换点。 这是进入网络媒体的最后一个负责任的时刻。 如果您不这样做，您最终将多次执行该细化阶段——这是非常低效的。

如果您曾经花费数小时调整 PSD，将其交给开发人员进行构建，然后在一两周内检查回来，您就会经历过这种痛苦。 您通过推动静态像素来改进和完善的所有努力都被浪费了。 一旦设计改变媒体（从 Photoshop 或其他工具中的静态设计到浏览器中的 HTML 和 CSS），就需要进行另一次细化。 切换点背后的想法是认识到这是多么低效。 与其使用静态工具进行改进，不如尽快对基本设计进行编码，并在最终媒体（网络）中处理改进。

这通常需要设计配对，实际上是坐在一起以使这些改进变得栩栩如生。 尽管有时会感到缓慢和痛苦，但实际上对所有相关人员都非常有益。 当设计师与前端开发人员分享他们希望看到的各种样式调整时，前端开发人员会了解在精致设计中什么是重要的。 当前端开发人员进行请求的更改时，设计师会看到这些更改是如何进行的，也许会学习一点 CSS。 这个过程让每个人都变得更聪明。 这也意味着下次这两对时，它会走得更快。

如今，我们必须熟悉许多工具才能开始 UI 对话，并且我们需要在流程的早期转移这些设计的编码。 让我们看一下执行此操作的几种方法。

风格瓷砖

萨曼莎·沃伦 (Samantha Warren) 开创了新的天地，她将样式图块作为一种为网络“定义视觉语言”的方式。 我们这些有品牌背景的人立即看到了风格瓷砖的价值。

样式瓷砖非常简单。 它们通常包括调色板、排版选择、纹理和图像或插图样式。 它们故意不是整页的组合。 相反，它们代表了足够的设计来确定我们是否朝着正确的方向前进。 出于这个原因，当你的客户表达了他们想要的东西时，它们的效果最好，但你并不完全相信你在同一页上。

我开始欣赏风格瓷砖，主要是因为它们的速度。 我们过去需要花一周时间在 Photoshop 中设计主页和子页面，现在我们可以在几个小时内创建一个简单的样式图块。 这可以节省时间和金钱，并让您确信自己正朝着正确的方向前进。

Samantha 在风格瓷砖网站上有一些示例，下面列出了一些很好的资源，涵盖了它们在实际过程中的使用：

• “开启你的（视觉）风格”：Yesenia Perez-Cruz、Dan Mall 和我在德克萨斯州奥斯汀的 Artifact Conference 上的演讲（2013 年 5 月 13 日）。
• “使用风格瓷砖更快地做出设计决策”：萨曼莎沃伦在德克萨斯州奥斯汀的一个活动中（2015 年 2 月）。
• Samantha Warren 的风格指南播客

由于它们的静态特性，我们不会经常使用它们。 我们最初的设计方向通常是通过元素拼贴或样式原型来建立的，这两者都将在下面介绍。

元素拼贴

Dan Mall 向我们介绍了元素拼贴画，它是“没有特定逻辑或顺序的不同部分的集合”。 它们多样化的性质很明显，您所看到的并不是最终的设计。 相反，元素拼贴为客户提供了可能一起存在于系统中的各种组件的上下文。 它们帮助我们在线框的骨骼上添加一些肉； 它们帮助我们描绘出我们前进的方向； 它们允许我们开始可视化我们网站的构建块，但鼓励我们不要忽视整体。

元素拼贴的一个好处是您可以选择要显示的组件。 您的客户是否真的关心如何将搜索呈现给他们的用户？ 伟大的！ 也许你应该花一些时间来解决这个问题——把它放在元素拼贴中。 您的客户是否对号召性用语按钮着迷？ 将它们放入元素拼贴中。 这种选择和选择的心态使您可以轻松地根据项目中最重要的内容来定制每个拼贴画。 您的客户会非常欣赏这一点。

在最近的一个项目中，我们需要确定重新设计我们客户的一个网络资产的设计方向。 Katie Kovalcin（我们的设计师之一）领导我们团队的设计工作，她选择创建两个元素的拼贴画，而不是做主页组合。

我们在创建这两个设计概念上投入的总时间约为 16 小时。 当我问凯蒂，如果她被要求做两次主页排版，这需要多长时间，她回答说：

“在这一步中，试图找出他们的新审美，在试图布置页面的层次结构并弄清楚交互的同时，很难找到这种审美。 因此，将整个主页布置为一种了解美学的方式有时可能需要长达一周的时间，这取决于我们必须工作多少。 我会说每个可能接近 25-30 小时。

但是从元素拼贴开始，页面布局和所有其他东西很容易向前推进，因为没有太多争先恐后的事情来确定我们要使用的按钮样式、字体或颜色。”

这意味着，通过使用元素拼贴，我们将用于建立美学的时间分成四等分。

上面凯蒂的引述中还有另一个非常有趣的表达； 她说：“在尝试布置页面的层次结构并弄清楚交互的同时，很难兼顾找到这种美学。” 换句话说，从主页组合开始尝试完成太多、太快。 当我们先迈出较小的一步（通过使用元素拼贴或样式图块），我们就能够分而治之，克服摆在我们面前的设计挑战。 这使我们的客户更频繁地参与对话，并让我们能够边走边学，所有这些都会带来更好的工作。

样式原型

您可以将样式原型视为交互式样式图块。 样式图块中可能包含的相同类型的东西——品牌标记、标题、段落样式、按钮样式、链接处理、颜色推荐——都包含在样式原型中。 唯一的区别是我们更进一步并对其进行编码。

这些的美妙之处在于我们可以展示真实的网页类型、真实的颜色、真实的悬停状态、带有网络矢量的插图风格，以及类型和基本布局可能如何响应。 我们要求我们的客户在他们选择的浏览器中查看它们。 这开启了关于支持浏览器意味着什么的对话。 例如，如果他们使用不支持border-radius的浏览器，他们将看不到圆角。

我们还可以在一天左右的时间内构建样式原型，这为我们带来了与样式图块相同的效率优势。 客户喜欢他们，因为他们可以与他们互动。 他们可以在手机和平​​板电脑上看到它们。 他们可以开始和他们一起玩。

最后，在我们大多数人认为网页设计师应该学习编码的世界里，样式原型是编写 HTML 和 CSS 的绝佳介绍。 由于它们的简单性，即使是非编码设计师也可以弄清楚如何构建它们。 在他们知道之前，他们将有信心改进生产 CSS，而不是静态地模拟他们希望看到的更改。

当我们设计最初的 Sparkbox 网站时，以及最近重新设计时，我们使用样式原型来建立设计方向。

原子设计

Jeremy Keith 在他题为“没有移动 Web”的突破性开发主题演讲中首次向我介绍了从“网站的原子”开始设计的想法。 早在 2013 年 6 月，Brad Frost 就将这个术语正式化了，当时他概述了一个用于设计网络“组件系统”的心智模型。

基本前提是我们应该在工作中考虑五个级别的粒度来构建可重用的组件系统。 最小的层次称为原子； 考虑一个简单的 HTML 输入或输入的标签。 这些原子可以结合成分子； 也许搜索分子由按钮、标签和输入组成。 这些分子可以结合形成有机体； 也许网站的标题会包含搜索、品牌和导航分子。 这些有机体被放在一起形成模板和页面。 模板充满了通用数据； 页面是注入真实数据的模板。 所有这些理论都可以帮助我们创建更模块化、可重用和可扩展的代码。

当我们沿着这种思路处理我们的项目时，我学到的一件事是，当您允许原子设计从重构中演化出来时，它会容易得多。 我们工作的一种常见方式是在 HTML 和 CSS 中构建一个小组件，而不用过多担心原子、分子或有机体。 然后，一旦我们用界面解决了 UX 和 UI 问题，我们就可以将该代码重构为原子结构。 这种反向方法意味着我们不会浪费时间试图过度思考分子与有机体的区别。 相反，我们允许各个级别随着系统本身的发展而发展。

原子方法的结果是可以集成到系统中的模式库。

模式库

模式库就是它听起来的样子——系统中存在的模式库。 现在有很多人致力于模式库解决方案。 Brad Frost、Anna Debenham、Jina Bolton 和 Bermon Painter 等人就这个话题发表了演讲并撰写了文章。 事实上，Brad 和 Dave Olson 创造了当今最知名的工具之一，Pattern Lab。 Pattern Lab 很棒，因为它允许您将特定内容从 HTML 模块中分离出来，并且它提供了一个原子框架，可以很容易地构建一个模式系统。 他们还添加了一些很棒的功能，供您在开发时进行测试。 整个事情很容易在本地运行，并且有一个简单的界面，可以很容易地向客户展示。 如果你想进入模式驱动设计，这是一个很棒的起点。

现在这个领域正在发生很多事情，对于我们这些有兴趣了解更多信息的人来说，还有许多其他资源。 Brad 与 Anna Debenham 和 Brendan Falkowski（以及其他一些人）一起创建了网站样式指南资源。 这是涵盖模式驱动设计和开发的许多示例、文章、演讲、播客等的巨大集合。

到目前为止，最大的挑战是在模式与后端系统集成后找到一种方法来保持模式库的最新状态。 我还没有看到完美的解决方案，但是有很多聪明的人正在研究它。 看看 Lonely Planet 的 Rizzo，这是一个努力解决这个问题的组织的一个很好的例子。 即使我们没有完美的长期解决方案，我也看到了以这种方式设计的巨大好处。 它让您以模块化方式思考，这使得我们所做的前端工作更容易集成和维护。

断点呢？

每当我谈到或写下流程时，我总是被问及如何选择断点。 奇怪的是，这种对话几乎从未出现在我们日常的响应式工作中。 当然，一些客户来找我们，他们已经完成了大量的工作来审查分析和确定设备的优先级——所有这些都是以记录系统断点的名义。 这种思路对我来说从来没有多大意义。

我相信是斯蒂芬·海第一个说的：“从小处着手，在网站崩溃时添加断点。” 我们的站点通常有几十个断点——其中大多数与常见的设备尺寸不一致。 当您发现您的内容和您的设计不再协调工作时，请修复它。

现在，Stephanie Rieger 所说的主要断点和次要断点是有区别的。 （我也听说过它们被称为断点和调整点。）让我解释一下。

主要断点

当布局发生变化，需要单独的模块在其设计更改中协同工作时，我们使用公共断点（主要断点）。 也许您有一个布局调整，将小视口宽度的堆叠产品列表移动到较大视口宽度的两列布局。 在这种情况下，您需要跟踪这种布局变化发生的位置，因为很可能在相同的视口宽度上需要发生许多其他变化。

我们所做的大部分工作都有三到六个主要断点。 这些通常在我们的工作流程中设置为 Sass 变量，以便我们稍后可以在一个地方对它们进行更改。 对网站的主要部分设置一组主要断点也很常见。 例如，我们网站的页眉中可能有三个主要断点，而页脚中可能有三个完全不同的主要断点。 这使我们的工作保持模块化，并允许这些部分独立发展，同时仍保持与整个系统的凝聚力。

小断点

当需要对类型或间距进行更细微的更改时，我们仍然可以使用媒体查询来进行这些调整（一个小断点）。 这些通常是一次性的样式修改，例如字体大小（以检查行长）或随着视口宽度的增加而增加间距。 这些细微的调整表明了对细节的深刻关注，可以真正让您的工作与众不同。

我们通常只使用硬编码的数字，而不是为这些使用预处理器变量。 有时，我们还使用预处理器计算来保持这些相对于主要断点。 例如，如果我们在 30em 处有一个名为$bp_header-show-nav的主要断点，我可能想在$bp_header-show-nav断点上方调整 5em 处标题的字体大小。 在这种情况下，这将发生在 35em。 如果我们在未来某个时间点将主要断点移动到 32em，那么次要更改将发生在 37em。 如果您怀疑主要断点可能会更改，则相对考虑次要断点会有所帮助。 您必须根据具体情况使用您的判断来做出最佳决策。

延伸阅读

有关断点的更多信息，请查看以下文章：

• “没有断点”
• 马克博尔顿的“中间”
• Stephanie Rieger 的“实用响应式设计”

过渡出去

这些天来，仅仅建立伟大的网站是不够的。 我们还必须考虑我们建造的东西的寿命。 虽然像原子设计这样的方法可以提供帮助，但我们需要做更多的事情。 目前，我们的大多数项目都包含某种培训组件——我并不是在谈论教客户使用 CMS。 随着组织开始真正了解网络为他们提供的价值，他们决定建立自己的团队来拥有和维护他们的网络资产。 如果我们想构建持久的东西，我们需要确保承担我们工作的团队能够妥善维护它。 出于这个原因，我们正在围绕我们用于构建网络的技术进行更深入的培训。

幸运的是，现在有许多常见的方法来实现过渡。 我们在源代码管理中创建的每个 repo 都有一个有用的自述文件； 我们提供支持我们代码的自动化测试； 我们正在研究一些方法来转换项目的性能预算，以便我们的客户继续保持其网站的速度。 除了原子思维，我们还提供了我们构建的子系统的工作示例。 例如，我们通常会考虑在客户品牌的背景下如何在所有 Web 属性中使用排版，因此我们可能还会提供有关此排版系统的详细文档，以及展示如何使用它的示例页面。 当我们将代码从我们的团队传递给客户的团队时，这些对我们工作的补充使我们的工作更加轻松。

这一切也会产生更深层次的影响。 了解谁将维护您正在构建的系统也应该影响您围绕技术选择和开发技术做出的决策。 换句话说，如果您客户的 Web 团队还没有准备好从命令行使用 Grunt 和 Assemble 和本地服务器，那么您需要找到一种更符合他们能力的工作方式。 请记住，您正在为他们构建这个。

邀请我们客户的网页设计和开发团队与我们一起参与该项目也非常有益。 使用该项目作为培训客户团队的机会展示了令人难以置信的价值，并使您在竞争中轻松选择。

人超过过程

我在不断发展我们的工作流程中学到的最后一件事是，您选择使用的流程远没有使用它的人重要。 如果您想构建更好的网络产品，请从培养您的人员开始。 这将比对您的流程或工作流程进行任何调整更进一步。

让你的团队快乐

同样，我建议阅读 Mihaly Csikszentmihalyi 的Flow 。 在这本书中，他解释了他为更好地理解个人幸福所做的研究。 他描述了他所谓的“流动通道”，沿x轴绘制技能水平，沿y轴绘制挑战水平。 流动通道是您的技能遇到足够挑战的区域。 对你的技能有太多的挑战会导致焦虑，对你的技能的挑战太少会导致无聊。

这可以通过考虑我们在日常工作中挑战自己的地方来转化为我们所做的事情。 在 Sparkbox，我们谈论学习文化。 这（希望）意味着我的团队的技能不断提高。 因此，为了快乐，我们需要找到不断增加的挑战来匹配我们不断提高的技能。 我们有责任在客户的预算中平衡创新需求和财务责任。

这很棘手。 对我们来说，这意味着我们需要停止重新发明轮子； 它使我们考虑了经过良好测试的界面元素库，而不是在每个项目中重复解决相同的问题。 这意味着我们需要了解每个客户应该在哪里花钱进行创新。 它要求这些客户和我们的团队之间有相当多的透明度，以便我们都在同一个页面上。

最后，它会造就一个更满足的团队——一个热爱他们所做的工作的团队，因为它以正确的方式挑战他们。 它使客户更加内容——尊重你关于他们应该在哪里和为什么投资的建议。 这对所有相关人员来说都是极好的。

向前

这部分我深深地启发了你，并鼓励你勇敢面对一个大胆的网页设计新世界。 但是，老实说，我一直在努力总结本章的结束语。

经过一番思考，我相信这是因为编写过程从未真正完成。

我希望当您阅读这些文字时，您会发现自己更有动力去投资于自己对网络工作原理的理解，也更愿意投资于队友的理解。 我希望你对尝试一种新方法感到兴奋，但我也希望你有能力在这些页面不适合你的情况下撕掉它们。 只有您、您的团队和您的客户才能找出处理项目的最佳方式。 这就是我们所做的事情的本质。

现在是时候了——所以，开始吧！