Brad Frost：TechCrunch響應式設計之路

Brad Frost在2013年使用響應式設計技術對著名的技術創業網站TechCrunch進行了重新設計，以適應多螢幕尺寸移動閱讀的需要，

Team Dev通過該項目得以重新審視新型網頁設計流程，本文是他的精彩自述。

（註：原文發表在技術創業微門戶：踏得網（Techbrood.com））

設定項目預期（Set Expectations）

很多使用後PSD時代設計流程（Post-PSD Era）效果不佳的原因在於在項目開始的時候，沒有能夠跟客戶和同事一起設定合理的項目預期。 

我們盡了最大的努力來讓客戶理解網頁介面面臨的現實挑戰（不用多說什麼，給客戶看一下下面的圖），

那麼由於我們的網站需要是流動的（Fluid），我們的設計流程也要與之相匹配。

我們協助大家理解開發是設計過程的一個重要組成部分。在Techcrunch項目開始之前的幾個月裡，我正在深入思考什麼才是終極的原子設計（Atomic Design），

我甚至已經開始著手建立一個強大的模式庫，配合介面模式來組裝頁面，這個工具最終形成了Pattern Lab項目，

我給項目組所有人介紹原子設計並示範了Pattern Lab。我們討論了建立一個設計系統和臨時收集的頁面模板相比的好處，似乎每個人都接受了，並未對我的看法咬牙切齒。

開工和計劃（Kickoff and Planning）

我們在Techcrunch的辦公室啟動這個項目，在那裡和利益相關者（Stakeholders）進行了交談，做了一個20秒的直覺測試（Gut test），以及設計工作室練習，以便於讓大家達成一些共識。關於這些練習你可以多瞭解點，因為我們在娛樂周刊（Entertainment Weekly）項目中也重複了這些有效練習，我還把這些用在當前的Pittsburgh Food Bank網站重構中。

草圖（Sketching）

1.建立全網站範圍的資訊結構模式

Jennifer（資訊架構師）從整個網站的視角提取出共用的資訊結構，比如”rivers”,”islands”，river是資訊列表比如新聞報道，而islands是被推薦的內容。

建立這些提示模式的好處在於，我馬上就可以在Pattern Lab中建立對應的原子設計系統（Atomic Design System）裡面的組織（Organisms），根據Jennifer的灰色背景的區塊草圖，我很快使用一個.fpo類構建了HTML原型，一旦建立好了，後面改動線框圖（wireframes）就如同拷貝粘貼一個include那麼簡單。

除了把Jennifer的草圖轉化為Pattern Lab中的FPO區塊外，我還能夠馬上開始編寫一系列的原子（molecules）和組織（organisms：文本元素（粗體，重點，區塊引述，突出引用等），圖片類型（logo，文章圖片，頭像等），表單（搜尋、訂閱、提交內容、聯絡表單等），廣告位元素以及更多。

 

2.建立視覺方向(Establishing Visual Direction)

與此同時，Dan（視覺設計師）開始構建視覺方向，由於Techcrunch的主要功能是提供使用者閱讀資訊，Dan認為使用者第一視覺感受會是字型類型（Type）。因此使用Typecast工具http://typecast.com/，Dan迅速構建了一系列類型方案和使用者溝通，使用者得以反饋一些意見：比如文字塊太擠了，太細長了等等。

 

動手開發（Rolling Up Our Sleeves）

一旦我們對資訊架構、視覺效果、HTML腳手架原型有了具體的感受，我們就可以開始全面的設計和開發整個網站了。

1. 首先是Jennifer構建出所有用例下的HTML線框圖，而我則根據線框圖開發出每個頁面的模板（一開始只是原子、組織這些元素的集合，樣式後面再添加）；

2. 然後Dan進行元素拼貼（Element Collages），元素拼貼比樣式底板（Style Tile）http://styletil.es/要具體得多，不過仍然不是一個全面的設計對象。下面是一個例子說明在各個螢幕尺寸下，介面如何進行適配：

 

這裡很好的是，使用元素拼貼，Dan不需要擔心使用者會像對待整個頁面設計那樣分散注意力，從而可以集中對比如頁面頭部Header提交反饋意見，一旦客戶滿意於Header的設計，我就可以開始遵循那樣的視覺方向，開始補充樣式。我實際是從Header和Footer開始這樣做的。

現在可能看起來有點怪了，從客戶的角度而言，部分頁面已經從線框圖轉變為了最終的設計，而部分仍然保留為灰色區塊，不過由於我們和客戶保持積極的溝通，他們理解並實際上參與了整個過程，因此我們可以得到正確的反饋。

 

3.完整的設計對象（comps）

不管信或不信，我們最終還是產生了部分頁面的完整設計圖。糟了!可惡!

不過和以往項目不同的是，我們並沒有跟著完整設計圖走，實際上comps是整個過程的結果，在Dan最終做出部分comps的時候，我們已經構建了大部分的網站原子和組織，並深入理解了我們的設計的系統狀態。

我們把comps提交給客戶，客戶回函意見，這時我可以直接在HTML上修改，因此我們並不依賴於完整的設計圖(comps)。

這樣，我們給網頁組織（Organisms）建立了視覺效果，並在的確需要完整圖紙的地方給出了設計稿。我還將適當的為每個organism添加樣式，慢慢的但確切的把所有剩餘的灰色區塊全部實現。

在此過程中，有些HTML看起來效果不佳，我會和Dan直接通過HTML頁面溝通並進行小的調整修改，最終，我們意識到有些Photoshop文檔是不必要給客戶看的。事實上，這些文檔是給我們自己看協助完善一些細節的。

所有的頁面模板都出來後，我們進行了跨瀏覽器，跨裝置以及全部用例的測試（在開發過程中已經進行了部分核心功能的測試），最終提交給了10up團隊在Wordpress後台上進行了實現。很好的地方是，我們不只是提交了一些頁面模板，我們還構建了可靠的設計系統，可以被複用和進行後續版本功能演化。

 

我們學到的（Lessons Learned）

1.不是Agile也不是Waterfall，我不知道該怎麼稱呼我們的整個流程，我只知道我們積極溝通協作（遠端），保持對客戶的真誠和對自己工作的認真。

2.並行工作（Work in parallel）

在可能的情況下，並行開展工作。把事情分解開來，統籌交叉進行。

3.緩慢但確保品質（Slowly build fidelity）

感覺就像在雕塑，先取一小塊石材，體驗材質和培養感覺，然後塑造頭部，肩膀，身體，腳...直到完工。

和雕塑不同的是，我們擁有Ctrl+Z(Cmd+Z) ：）

by iefreer