- 原文地址：Wireframes are becoming less relevant — and that’s a good thing
- 原文作者：Sean Dexter
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：hanxiansen
- 校對者：Fengziyin1234, xiantang
隨著時間的推移，我發現線框圖越來越沒用，而且這麼想的還不止我一個。因為“線框圖”一詞並沒有很精準的定義，所以這裡或許還得說清楚本文講的是什麼。雖然有許多種原型可以檢測不同維度的逼真度，但我想重點介紹的，是人們在聽到“線框”一詞時最先想到的那一種。這裡說的線框圖，既不是草圖，也不是一個全面呈現細節的原型，而是一個典型的“中間”狀態（一種以數字形態存在、故意不加樣式的人造物，其用途是以黑白色調呈現整個頁面的“骨架”）。原型線框圖試圖準確地展現佈局和資訊框架，同時故意不追求大量重現外觀層面的每個細節，有時候連內容上的細節也不會大量保留。
在我參與的線下或線上討論中，我驚訝地發現，人們還是將線框圖定位為設計環節中的基本步驟，雖然這種態度似乎處於下降趨勢，但我仍然能聽到每個人 — 從初出茅廬的職業設計師到業界領先的機構，都在堅持“線框階段”的必要性，這些論點通常包含以下幾個方面：
線框圖關注於實用性而不是美觀程度，可以避免利益相關者因拘泥於無關緊要的細節（如：按鈕顏色）而把會議方向帶偏，還允許使用者在測試時集中於互動而不是視覺呈現。
畫線框圖耗時較短，它能把問題控制在概念層面，還可以防止我們在某一方向上緊抓不放，或者花費過多精力。
還有一種（更貼近企業視角的）觀點，它和前兩種有點不同，是說線框圖這種工具可以用來對互動進行詳細記錄，同時又不需要我們在外觀設計方面下額外工夫。
並不是說所有人都真的有畫線框圖，但是要承認沒畫線框圖的時候，人們通常就會壓低聲線，目光遊離。他們不是不想畫；他們只不過是因為受制於所處的組織、利益相關者或專案本身，所以不能每次都畫。但是，這種認為線框圖不畫不行的心態，以及各種關於畫線框有哪些好處的想法，或許是被誤導了。雖然我不否認，總有些時候線框圖是有用的，但現在這些場合已經不多了，而且還日益減少。推動這種變化的，是行業思維和實踐的多項轉變，這些轉變值得我們考究一番。
不斷變換的產品開發方法正改變著人們從事設計的方式
敏捷產品的開發鼓勵我們使用線性程度較低的過程。這種開發方式不是先從全面覆蓋整個產品的基礎元素著手，然後在其基礎上搭建層，而是將重點轉移到更小，更頻繁地交付完全實現的“縱向”切片。
這也包括完全實現的設計，這使得同時考慮視覺化、資訊架構和互動性變得非常重要。在敏捷開發團隊中，每次迭代的發生時間都以天或星期為單位計算，而不是幾個月或幾年；在這種開發場景裡，比較難有空間容納那種在早期進行、常常讓人畫出一堆線框圖的大規模mapping phase。
精益UX（Lean UX）是一種隨之誕生的改進流程（似乎在不斷被關注），在 Lean 設計中，繁重類的設計工作被忽略或完全省略，這有利於在產品本身上進行協作，Lean 設計還反駁了將線框圖作為文件工具的想法，它建議實際產品的螢幕佈局可以作為它們的文件，你自己建立的設計元件將成為臨時項 —— 只要它們包含的資訊在實際產品中以可訪問的方式存在，就可以把他們放到一邊去。其它相關情況仍可記錄在案，但僅在設計時或之後。
可用性和資訊框架並不是孤立存在的
雖然這道理大家都懂，我還是要在這說一遍：介面中元素的視覺表現形式會影響使用者對它們的感知。如果下拉選單長得像表單區域，就可能會讓人誤解其功能；如果選單標題的外觀很難讓人把它和選單條目區別開，使用者就可能看漏眼。顏色和對比度在引導視覺注意方面起著巨大的作用。如果你在一個線框上做可用性測試，等到最終大幅修改外觀時，做好的測試就派不上什麼用場了。而且到了那個時候，你可能還要為了更好地適應視覺效果，而對佈局進行更多修改。使用者可能只會專注於視覺元素，他們這樣做無可厚非，而且將所有內容設定為灰色並不一定會降低這種風險。問理解方面的問題，以及用完成任務的方式做測試，比口頭評論更能暴露可用性或者資訊框架方面的問題。只要你能很好的設定預期並注意反饋的徵求，就可以用任何保真度來實現概念的輸入。
讓利益相關者看線框圖的做法很少奏效
開會的時候，要是有個利益相關者對某個按鈕或副本的顏色揪住不放，就會讓人很心塞；這我懂。但是，難道存心不用高逼真度的影像，然後處處用 lorem ipsum（譯者注: 排版時的專用測試文字）填充，你就真的能解決問題嗎？還是說，你只是把解決問題的時間推遲？你喜歡低保真度，是因為它能讓人理解起來更容易，然後發表意見嗎？還是說，實際情況是：它讓別人更難理解了，而我們喜歡這樣，因為這樣一來我們就夠將自己的專業知識凌駕於他人之上，免受批評？如果利益相關者不熱衷於評價資訊架構，而是更在意與他們專業知識相關的其它事情，那你為什麼還要擺出一副對抗態度呢？你才是資訊架構方面的專家，他們不是；任何需要對佈局進行的更改都應通過對使用者的測試而變得清晰。
它變得更快捷，也更容易接近高保真的視覺呈現
幾年前，Photoshop是 UI 設計之王，每個人都在爭先恐後地看，比拼誰能在給定的頁面上新增最詳細、最逼真的紋理。在那個時候說線框具有節省時間的優勢，是站得住腳的。但今天，我們的設計工具專為 UI 設計（想想 Sketch，Adobe XD，或 Figma）而打造，它們大大加快且簡化了在全域性層面對設計進行管理和更新的操作。在設定好視覺風格之後再更改佈局，沒理由比在之前更改難。對於那些成熟的設計組織來說，設計系統和支援這些系統的元件庫的結合幾乎消除了任何藉口。而即使你所在的組織還不成熟，你大概也還是能取得與身邊的開發人員所使用的 UI 框架相匹配的 UI 工具包。這也有助於：今天，即使是最複雜的視覺美學，仍然是相對簡單的。如果你的按鈕只是個帶有圓角的藍色長方形，那麼就算你故意把它變成灰色，又真能省掉多少時間？
線框圖還有意義嗎？
它在合適的情況下是有意義的。比方說，你畫線框圖可能是出於以下原因：
-
你確實擁有一個視覺上很複雜的產品（如移動遊戲），它的藝術創作過程必定耗時頗長，而你要在不牽涉藝術創作的情況下訂出產品的互動方式。即使如此，你仍然可以盡力實現風格的相似度。
-
你將它們用作練習，以幫助人們獨立的瞭解資訊框架（希望是產品開發的一次性而非反覆性的部分）。
-
你想繪製或測試資訊框架，但又依賴於他人的視覺設計（這並不理想！），或者，你在某些方面受制於你可用工具的視覺功能抑或者是被你個人的技能水平拉了後腿。
-
你處於過時的瀑布流或代理環境中，並且你對流程沒有太多的自主權，這不是很好，你沒有辦法。
我確信還有很多其它的可能場景和例外情況，但我認為對於今天的大多數設計師來說可能並不常見，如果你認為傳統的線框設計只是在真正適合問題的情況下才使用的方案，那麼你會發現它們經常可以避免 — and that’s OK.
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。