沒有哪個成功的 Web 專案是在設計師和開發無法流暢溝通的前提下搞定的，協作才是做好專案的基礎。

我曾看到經驗豐富的設計師和開發者因為溝通不暢和誤會導致專案失敗，也見過新手設計師和開發團隊一起透過高效協同，做出驚豔無比的設計專案。在專案之初充分的磨合，能讓專案在後續的快速迭代中更為流暢。足夠和諧的溝通不僅有利於工作，而且能讓整個團隊保持情緒的穩定性。

而在響應式網頁設計專案中，設計師和開發者之間的溝通流暢與否，就顯得更為重要。

設計響應式網站的時候，整個團隊必須為大量不同尺寸螢幕的裝置充分考慮，習慣於 “畫素精準” 的設計師和開發者需要對流動的介面和大量的不同比例的裝置有充分的準備。簡而言之，響應式設計使得整個專案交付面臨著大量的不確定因素，這也是響應式網站專案的難點。

希望接下來的 5 個小技巧，能幫各個團隊順利搞定這種專案中的溝通障礙和技術問題。
1 、優先專注 “極端” 尺寸
invisionpost_rwdrange

當您面對著手機螢幕和桌面端顯示器這兩種極端的螢幕尺寸之時，疑問會自然而然出現。有的設計師打一開始就從動態的視角開始他們的設計，但是絕大多數的設計師仍然是從靜態的頁面開始著手設計的：選擇一個固定的高度和寬度，繪製相應的草圖或者視覺稿。

這樣一來，就引出了幾個問題：您的開發團隊優先考慮什麼尺寸？設計團隊先交付的高保真視覺稿是哪個尺寸的？從技術限制的角度出發，您應該優先考慮什麼裝置？

我始終推薦從多使用者基本的 “極端” 尺寸開始考慮，推薦當前（2022 年）常用裝置中小和大的情況：

320 x 568 px（iPhone 5 ，由於它是視網膜螢幕，平時我們是按照 72dpi 來設計，但是 iPhone 5 的顯示實際是 144px，所以我們給出了這樣的一個設計尺寸。作為 UI 設計師的您應該很清楚 @2x 和 @3x 的問題）
    1600×1000 px（桌面顯示器的常見尺寸）

當然，您的多使用者的實際情況可能略有不同，稍加調查，確定 “極端情況” 。

“剛剛開始響應式網頁專案的時候，從多使用者常見的大和小尺寸設計著手。”

當您面對小的螢幕的時候，您需要在小螢幕上呈現出重要的內容，如何選取是一件頗為費神的事情。但是面對大螢幕的時候，您所思考的事情又是截然相反的：怎麼展示內容才算是過多？分欄是否因太寬降低了易讀性？如何選取元素才能避免這樣的問題？後，面對兩個不同尺寸的介面，您還要考慮它們所涉及的輸入方式，小的螢幕上通常是觸控式螢幕和虛擬鍵盤，大的螢幕上，絕大多數時候是傳統的鍵盤滑鼠。

這裡重要的事情可能是您需要一次挑選兩個介面尺寸來做，而不是傳統的針對一個螢幕設計，然後完成剩下的部分。設計師和開發者在這個問題上出現分歧，對後續的影響是非常大的。
2 、討論不同斷點之間內容佈局

在日常的網頁設計中，大家對於靜態的線框圖投注瞭如此之多的關注，但是在做響應式設計的時候，應該始終謹記頁面內的佈局是流動的。這也就意味著，您網頁的多使用者絕大多屬時候所體驗到的頁面其實是它的 “中間態” 。所以，您必須考慮隨著螢幕尺寸大小的轉變，佈局設計的每一個調整和改變。比如，當螢幕尺寸變小的時候，文字內容需要收縮，並且和混排的圖片會與文章縮到一欄中去。

這些適配能與不能、該與不該的問題上，儘量不要同您的開發團隊去 “假設” 或者 “推測” 。積極主動地去確定這些資訊，在您負責開發的同事還沒有做太多之前，和他們達成共識。對於複雜的佈局改變，事先繪製先框圖或者草圖來單獨說明，是非常明智的選擇。對於一些不那麼重要的特性，透過簡短的討論或者電子郵件通知就足夠了。
3 、對於圖片素材的處理策略早做準備
invisionpost_rwdimages

響應式網頁中的圖片，通常是由一組多個不同尺寸的圖片組成的。比如我的個人網站頁頂部的大圖，就是由一組 6 個圖片組成的，解析度和尺寸各不相同，確保不同的裝置都能匹配上對應的圖片。

圖片格式和尺寸通常會讓團隊內的設計師和開發者之間產生隔閡。您可以用 PNG，也可以用 JPG，圖示字型和 SVG 也會在網頁上很好的運用。也就是說，並沒有一個正確的答案：用什麼更多是取決於可用的內容和資源本身。但是重要的地方在於，大家要在使用格式上達成共識，並且堅持使用下去。另外，您可能也想鑽研出一套通用的圖片尺寸體系，運用在不同的專案中。

不過對於現代的響應式網頁設計，這僅僅只是一個起點。現在要做您至少需要兩套圖片素材，一種是給普通 PPI 的螢幕所設計，一種是給高 PPI 的視網膜屏所準備的。更完備的響應式網頁，對於圖集和素材的要求更高，細分更多，針對性更強。

儘量避免將響應式圖片格式的篩選決策留到專案後期。

起碼，您得針對不同畫素密度的螢幕作出基本的區分。仔細讀一下這篇關於 srcset 的文章，或者使用 Picturefill 這樣的工具來確保跨瀏覽器支援。如果您覺得整個方案不堪重負，那麼不妨從小的部分開始做起。逐步調整圖片元素的 srcset 屬性就是一個不錯的開始，在這個過程中，您會逐步看到網頁的響應越來越靠譜。
4 、從基礎元素開始思考，使用模組化設計

我的響應式網頁設計流程深深地受到了 Brad Frost 的 Atomic Web Design 和 Jonathan Snook 的 SMACSS 的影響。兩個框架都依靠小而可複用的基礎元件來實現強大的網路架構。

所以，在與開發者交接的過程中，我會優先專注小而可複用的元件，因為它們能給不同平臺不同裝置帶來相同的多使用者體驗和視覺效果。這種一致性會更容易為開發團隊所消化吸收。而且，小元件在不同頁面之間的複用性也非常強，所以，如果您設計出了一套高效的方案，今後還會有用武之地。

想象一下，您正在設計一個帶有大標題、高畫質大圖和表單的註冊頁面。由於網頁是響應式的，所以所有這些元素都會隨著裝置和螢幕的轉換而變化尺寸。那麼在專案研發早期，應該同開發團隊一起鑽研，敲定頁面所涉及的各個細節。它看起來應該是什麼樣子？用什麼樣的驗證機制？如果要輸入表單，如何配合觸控式螢幕和傳統的鍵鼠？
5 、讓開發者給視覺和體驗設計做反饋

有些設計師在產品設計會議、可用性設計環節和其他的溝通環節不讓開發者參與或提供反饋。這種放任和封閉是錯的。要知道，經驗豐富的開發者在產品、體驗和設計領域同樣有著極為豐富的知識。讓他們參與到這些環節中，能讓產品更加成熟。前端和設計師在技能上的重疊就更多了。

越來越多的設計師開始自己寫程式碼了，開發者也逐漸習慣於製作快速原型、先框圖，並且也會在私底下惡補美學和設計類的知識。響應式網頁設計的出現，使得兩個職業之間的交疊越來越多，加劇了這一趨勢。雖然沒有設計師的頭銜掛在開發者頭上，但是他們對於設計往往能說出驚人之語，發人深省。

當然，不同的角色和職責的劃分依然是極為重要的。但是稍微調整一些小步驟，確實能顯著提高終產品。所以，您做下一輪產品可用性測試的時候，不妨帶著開發者一起來討論。
結語

所有這五個技巧都需要實現計劃，並且不停補充。絕大多數團隊都將注意力放在產品的釋出和卡 Deadline 上，這個階段再來考慮這些問題，不利於產品，也不適合此刻團隊內的設計師和開發者。

專案開發之初，稍加計劃，後期的回報絕對是豐厚的。