高效的響應式設計流程

你的響應式設計過程是什麼樣的？ 你覺得效率高嗎？ 以下文章摘自 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 產品。 這個女人非常聰明； 她每天都在網上工作——這就是她謀生的方式。 不久前，我正在和她討論她的產品下一步是什麼，她對我說：“我認為我們需要對我們網站上的標籤進行一些更改。” 我停了下來，因為我拼命想記住我們在她的網站上實現標籤的位置。 感覺到我的困惑，她繼續解釋了更多關於她所希望的事情。 過了一會兒，我意識到她在談論導航。 這位精明的網絡企業家將她的導航稱為“標籤”，這令人大開眼界。

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

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

That's 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. Who are we building for?
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，我們談論學習文化。 這（希望）意味著我的團隊的技能不斷提高。 因此，為了快樂，我們需要找到不斷增加的挑戰來匹配我們不斷提高的技能。 我們有責任在客戶的預算中平衡創新需求和財務責任。

這很棘手。 對我們來說，這意味著我們需要停止重新發明輪子； 它使我們考慮了經過良好測試的界面元素庫，而不是在每個項目中重複解決相同的問題。 這意味著我們需要了解每個客戶應該在哪里花錢進行創新。 它要求這些客戶和我們的團隊之間有相當多的透明度，以便我們都在同一個頁面上。

最後，它會造就一個更滿足的團隊——一個熱愛他們所做的工作的團隊，因為它以正確的方式挑戰他們。 它使客戶更加內容——尊重你關於他們應該在哪里和為什麼投資的建議。 這對所有相關人員來說都是極好的。

向前

這部分我深深地啟發了你，並鼓勵你勇敢面對一個大膽的網頁設計新世界。 但是，老實說，我一直在努力總結本章的結束語。

經過一番思考，我相信這是因為編寫過程從未真正完成。

我希望當您閱讀這些文字時，您會發現自己更有動力去投資於自己對網絡工作原理的理解，也更願意投資於隊友的理解。 我希望你對嘗試一種新方法感到興奮，但我也希望你有能力在這些頁面不適合你的情況下撕掉它們。 只有您、您的團隊和您的客戶才能找出處理項目的最佳方式。 這就是我們所做的事情的本質。

現在是時候了——所以，開始吧！