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

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

Step1：信息架構(gòu)，確立內(nèi)容戰(zhàn)略。

按照產(chǎn)品定調(diào)和客戶解析，交互設(shè)計師確立站點信息架構(gòu)。(信息架構(gòu)體現(xiàn)方式有許多種，這不是本文難點，不詳述)。

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

Step2：移動框架

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

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

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

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

從移動著手做設(shè)計對習(xí)慣了PC環(huán)境的設(shè)計師可能是一種挑戰(zhàn)，考慮方式工作習(xí)慣都被迫做出改變。但這種改變必須去適應(yīng)，由于客戶習(xí)慣在改變。

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

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

Step3：響應(yīng)式框架

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

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

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

Step4：模塊設(shè)計

根據(jù)移動優(yōu)先的原則應(yīng)當(dāng)先實行手機端的模塊小節(jié)設(shè)計，不過我們選取了從PC端著手設(shè)計小節(jié)。由于PC端開發(fā)可以充分暴露業(yè)務(wù)復(fù)雜度，項目團隊的設(shè)計、開發(fā)、檢測在PC環(huán)境下?lián)碛谐墒斓墓ぞ吆铜h(huán)節(jié)，從PC著手讓開發(fā)進程更順暢。所以個人認為移動優(yōu)先是確立內(nèi)容戰(zhàn)略時應(yīng)當(dāng)遵循的理念，小節(jié)設(shè)計和開發(fā)進程是否要移動優(yōu)先，取決于產(chǎn)品定調(diào)和項目團隊情形。

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

交互確立頁面模塊小節(jié)后能夠抽取出產(chǎn)品用到的控件、組件和公共模塊，當(dāng)前視覺和前端著手做一件有別于傳統(tǒng)環(huán)節(jié)的事宜。視覺按照初期定義的風(fēng)格設(shè)計控組件和公共模塊的視覺效益，把它們拼成一個模擬的頁面，我們稱之為風(fēng)格拼貼稿。前端再把風(fēng)格拼貼稿里的控組件和公共模塊實現(xiàn)出來，一致維護一套組件規(guī)范代碼。

傳統(tǒng)的做法往往是頁面視覺定稿后設(shè)計師著手整理視覺規(guī)范標(biāo)注給前端。風(fēng)格拼貼稿是將這個工作盡可能提前，并變成一個設(shè)計協(xié)作利器。它的益處是：

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

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

Step5：響應(yīng)式模塊設(shè)計

PC端頁面模塊小節(jié)和風(fēng)格拼貼稿完成后，剩下工作是拓展出平板和移動端的完整設(shè)計稿，前端產(chǎn)出全部響應(yīng)式頁面代碼。實行響應(yīng)式模塊設(shè)計時最需要關(guān)注的仍然是讓使用適宜設(shè)備習(xí)慣，充分借助設(shè)備特質(zhì)。

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

Step6：檢測&探討&優(yōu)化，提交開發(fā)

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

在提交開發(fā)以前需要盡早明晰服務(wù)端響應(yīng)(RESS)的戰(zhàn)略。服務(wù)端與 用戶端結(jié)合是目前修復(fù)響應(yīng)式頁面性能問題的最合理計劃。哪些大圖片在移動設(shè)備下只需輸出小尺寸圖片?哪些內(nèi)容在什么設(shè)備下是不需要開發(fā)輸出的?哪些能夠減輕輸出的數(shù)據(jù)數(shù)量?與開發(fā)團隊協(xié)作的響應(yīng)式能夠靈驗控制頁面文件大小，防止頁面成為移動設(shè)備上燒客戶流量的罪魁禍?zhǔn)住?o:p>