[譯]線框圖變得不那麼重要了 — 好事啊！

摘要： 隨著時間的推移，我發現線框圖越來越沒用，而且不止我一個人如此認為，因為關於該術語的定義太過鬆散，所以具體的定義可能很重要，雖然有許多原型可以檢測不同維度的逼真度，但我想重點介紹在聽到“線框”一詞時最能想到的特定變化，它不是一個草圖或一個實成的原型，而是一個典型的中間狀態（...

隨著時間的推移，我發現線框圖越來越沒用，而且不止我一個人如此認為，因為關於該術語的定義太過鬆散，所以具體的定義可能很重要，雖然有許多原型可以檢測不同維度的逼真度，但我想重點介紹在聽到“線框”一詞時最能想到的特定變化，它不是一個草圖或一個實成的原型，而是一個典型的中間狀態（數字藝術設計中故意不加樣式，並用黑白表示整個頁面的“骨架”）。原型線框圖試圖準確的表示佈局和資訊框架，並 有意的 避免高逼真的視覺呈現，但有時候這也避免了內容的高保真度。

在我參與的線下或線上討論中，我驚訝的發現線框圖依然被定義為設計環節中的 基本 步驟，雖然這種態度似乎處於下降趨勢，但我仍然能聽到每個人 — 從早期的職業設計師到業界領先的機構，都在堅持“線框階段”的必要性，這些爭論通常有如下幾點：

• 線框圖關注於實用性而不是藝術性，它能阻止利益相關者在一些無關緊要的細節（如：按鈕顏色）討論上帶偏會議，並允許使用者在測試時集中於互動而不是視覺呈現。

• 線框圖的建立更快，它能保持設計理念，並避免了過多的開銷或過於依賴某一特定方向。

• 線框圖作為一種沒有額外視覺設計開銷的詳細互動文件工具，也存在這一些分歧（更多面向企業）。

實際上，並不是說每個人都在製作線框圖，但當有人承認不做線框圖時，他通常會躲閃你的目光，並保持沉默。雖然他們想讓更多的人加入他們。過他們往往受限於他們所處的組織、利益相關者或專案本身。但他們的心態是必要的，關於它們優勢的信念被誤導了，雖然我不否認線框圖的價值，但現在它只在有限情況下才有價值，行業思維和實踐的大量變動正促成這種改變，這是值得深思的。

不斷變換的產品開發方法正改變著設計的完成方式

敏捷產品的開發鼓勵更少的線性過程。不是從整個產品的基礎元素開始，然後在基礎元素上構建層，而是將重點轉移到更小，更頻繁地交付完全實現的“垂直”切片。

這也包括完全實現的設計，這使得同時考慮視覺化、資訊架構和互動性變得非常重要。在敏捷開發團隊中，你的下一次迭代將在幾天或幾周內進行，而不是幾月或幾年，這對會產生廣泛的前期繪圖階段的線框設計來說，很難有一席之位。

精益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 、 前端 、 後端 、 區塊鏈 、 產品 、 設計 、 人工智慧 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃 、官方微博、 知乎專欄 。