響應式網頁不像傳統網頁只需思考一種狀態，不是交付一套設計稿就完事兒了，它給設計、前端和開發團隊之間的協作形式帶來新的挑戰。在一個復雜產品全面響應式的項目里，交互每個階段該產出什么?交互與視覺怎樣協作?前端什么時候介入?哪些事宜讓后端開發來做更合理?履歷“玩客”第一版后，我們得到了有些結論。

響應式設計之所以叫響應式“設計”而不叫響應式“技術”，是由于它是一項設計先行的工作。需要設計先明晰好響應方式再實現出來，不能出一套設計稿后等著前端看情形把它變成響應式網頁。所以整個環節最初從交互階段著手，分成6個緊要流程，視覺、前端、開發等角色按照情形盡早介入。

Step1：信息架構，確立內容戰略。

按照產品定調和客戶解析，交互設計師確立站點信息架構。(信息架構體現方式有許多種，這不是本文難點，不詳述)。

這時候能夠明晰這個產品有多少頁面，每個頁面包括多少內容，內容優先級是什么。許多產品包括N多頁面，每個頁面一一思考響應式設計容易導致混亂且成本巨大。所以下一步緊要工作是解析頁面類別把頁面分類。以玩客為例，能夠把10多個頁面分成三類：列表類頁面、詳情類頁面、使用類頁面。

Step2：移動框架

先說下為何第二步要先設計移動框架。移動優先是移動互聯網浪潮下應運而生的理念，由Luke Wroblewski最早提出。移動優先并不是指移動更緊要，響應式設計理念里設備是同等緊要的。它是指優先設計移動端的體驗，有三個因素：

手機讓設計專注，強迫你想清楚什么信息是最關鍵的。由于手機屏幕小，每屏體現的內容少;觸屏手機操作手指使用而非鼠標這樣的精密設備來使用，對使用有更高要求;手機操作場景更加豐富，許多場景客戶是缺乏耐心的，比如當你排隊看電影正在找手機上的電子票，立刻排到你了翻半天卻很久找不到那張票這是多么令人崩潰的事宜。

手機眾多特質讓設計更強大。手機上的語音輸入、地理位置定調、豐富的手勢使用、越來越多傳感器，手機交互比PC擁有更多可能性。從手機著手設計，讓你更早地考慮怎樣發揮這些特質。

手機正在迅猛增長。手機即將超越PC，成為最主流的上網方式，這個趨向是不可逆的。

從移動著手做設計對習慣了PC環境的設計師可能是一種挑戰，考慮方式工作習慣都被迫做出改變。但這種改變必須去適應，由于客戶習慣在改變。

回正題，上一步已經把頁面分類并確立每個頁面內容優先級，當前接著解析每種類別頁面的導航、主體內容等框架構架，最終得出一份框架構架表。從玩客框架構架看出，全局導航是所有頁面公共的，局部導航只有列表類頁面才有，詳情類頁面都有一個“頁面主人”信息，而關系導航不是每個頁面都有。

接著著手設計移動端“超細長頁面”的框架(由于手機上普通是單列部署，所以頁面又細又長)。這一步著手把信息構架設計成最粗放的框架，能夠在白板或紙面上完成。要實現的關鍵目標是：把這個頁面最需要體現給客戶的內容放在最關鍵的位置，要適宜手機上的閱讀和使用習慣，盡量借助手機設備的特質。

Step3：響應式框架

按照移動端的框架拓展出平板和PC端框架。這是復雜產品實現響應式設計的關鍵流程，它是讓許多頁面有條理地響應起來的基本。第一件事宜是確立響應式形式，即從手機到平板到PC，導航怎樣變動，頁面部署用哪種響應方式，按照內容優先級怎樣調整模塊順序，等等。玩客在PC端以三欄部署為主，左邊欄作為局部導航或者主人信息區，中間欄始終是頁面主體信息，當頁面需要關系導航時一致放在右邊欄。

到當前這個階段所有頁面的響應式著手有規則可循，下一步工作就是繼續細化規則，把框架正確到詳盡尺寸。詳盡說來就是制定流體柵格系統。流體柵格系統是基于百分比的柵格部署工具，詳盡的制定手法會在另外一個篇章知識篇中詳細說明。

響應式是一種設計理念與前端技術親密結合的新興形態，鼓勵盡早實行跨職能洽談協作。交互確立響應式框架和柵格系統后，其他角色就能夠同步開展工作了。前端著手介入完成柵格和框架創建，產出頁面基本框架。視覺同步著手探索和定義視覺風格探索，制定視覺框架，產出風格關鍵詞、產品配色計劃。整個進程需要幾個角色不斷探討確立。

Step4：模塊設計

根據移動優先的原則應當先實行手機端的模塊小節設計，不過我們選取了從PC端著手設計小節。由于PC端開發可以充分暴露業務復雜度，項目團隊的設計、開發、檢測在PC環境下擁有成熟的工具和環節，從PC著手讓開發進程更順暢。所以個人認為移動優先是確立內容戰略時應當遵循的理念，小節設計和開發進程是否要移動優先，取決于產品定調和項目團隊情形。

響應式框架確立了頁面構架和響應形式，模塊設計這個進程著手完竣所有信息排版和交互模式，這是交互設計師最熟練也是最耗時的工作。這個進程與傳統環節沒太大差別，只是心里要不斷提示自己，這個模塊不是只為這個設備設計，它在其它設備下會出問題嗎?

交互確立頁面模塊小節后能夠抽取出產品用到的控件、組件和公共模塊，當前視覺和前端著手做一件有別于傳統環節的事宜。視覺按照初期定義的風格設計控組件和公共模塊的視覺效益，把它們拼成一個模擬的頁面，我們稱之為風格拼貼稿。前端再把風格拼貼稿里的控組件和公共模塊實現出來，一致維護一套組件規范代碼。

傳統的做法往往是頁面視覺定稿后設計師著手整理視覺規范標注給前端。風格拼貼稿是將這個工作盡可能提前，并變成一個設計協作利器。它的益處是：

1、一個頁面的視覺效益實際上是由一堆控組件和公共模塊組成，用真實的控組件和公共模塊拼貼的模擬頁面已經能夠體現出產品的視覺風格。把一個產品10多個頁面的視覺稿全部完成定稿是極其費時費力的事宜，產出一份風格拼貼稿則輕易得多。所以它是一個高效的設計工具。

2、復雜產品一直涉及多個設計師和前端并行工作，盡早地把控組件和公共模塊抽取出來一致管理，是保證視覺風格統一性的靈驗手法。防止不同設計師同時設計同一個控組件或公共模塊，減輕重復開發導致的浪費。也大大降低后期更新和維護頁面的成本，比如當需要修改“關注”按鈕時只需改一個就能全站生效。

Step5：響應式模塊設計

PC端頁面模塊小節和風格拼貼稿完成后，剩下工作是拓展出平板和移動端的完整設計稿，前端產出全部響應式頁面代碼。實行響應式模塊設計時最需要關注的仍然是讓使用適宜設備習慣，充分借助設備特質。

至此，一個全站響應式產品的頁面就陸續出來了。許多人認為響應式設計維護成本高的原因是一個頁面要同時設計多套設計稿。玩客這次經驗告訴我們，確立一套設計稿和柵格系統后再拓展出其它設備下的設計計劃，工作量遠比想象中的低。

Step6：檢測&探討&優化，提交開發

離大功告成還差最后一步，在真實設備下檢測頁面效益，項目團隊探討并持續優化。

在提交開發以前需要盡早明晰服務端響應(RESS)的戰略。服務端與 用戶端結合是目前修復響應式頁面性能問題的最合理計劃。哪些大圖片在移動設備下只需輸出小尺寸圖片?哪些內容在什么設備下是不需要開發輸出的?哪些能夠減輕輸出的數據數量?與開發團隊協作的響應式能夠靈驗控制頁面文件大小，防止頁面成為移動設備上燒客戶流量的罪魁禍首。