設(shè)計線框圖也需要考慮很多的原則，保證其美觀規(guī)范，能使項目運轉(zhuǎn)更為流暢。

人們往往低估低保真線框圖（wireframe）的審美價值，如果說這一組組灰盒子僅僅是我們工作交付成果的話，那么外觀也無關(guān)痛癢，對吧？錯，大錯特錯。

視覺表達過度的線框圖的確會破壞人們對其想法的理解，就像是一個人穿著Stormtrooper服裝去參加重要的大使館會議一樣。盡管Stormtrooper是星球大戰(zhàn)粉絲聚會上非常耀眼的服裝，但它絕不可能幫助您在大使館做任何事情；反之，如果你遞交給項目經(jīng)理一個丑陋的線框圖，并沒有附帶任何描述，你覺得你的同事能按你的設(shè)想采取行動嗎？他們會怎么想？最后依此做出來的產(chǎn)品是否能滿足用戶的需求？我想并不會，交流不暢的設(shè)計只會給項目帶來混亂和誤解，如果用戶體驗設(shè)計未被PM和團隊重視，最終想要獲得高質(zhì)量的產(chǎn)品也將會是非常艱難的。

這就是我強調(diào)線框圖美學的原因，閱讀你設(shè)計文檔的人在某種意義上也是用戶，你需要謹慎地對待他們。但這是否意味著我們將被迫花更多的時間在項目的構(gòu)思階段？我想并沒有：設(shè)計線框圖就像其他工藝一樣，需要許多規(guī)則的實踐，一旦你熟悉了這些技巧，它仍能保證項目進度不受影響。在這里我歸納了幾條線框圖美學原則作為參考：

1. 消除所有干擾物

只有當消除干擾物后我們才能有效溝通，那么什么是線框圖中的干擾物呢？略舉幾例：

• 不適當?shù)呐渖?/li>
• 不合適的保真度
• 丑陋的圖片和icon
• 無意義漫畫/詭異的字體
• 其他只有你才看得懂的代碼

這些都屬于讓讀者遠離你設(shè)計理念的東西。說來有趣，我認識的一個UX設(shè)計師有一種特殊的習慣，他在每個占位符（交叉矩形）上都使用了縮寫來標記他期待什么類型的圖像，我想這對他而言當然有一定的意義，但外人卻無法理解。所以如果你將和你的團隊分享這個文檔，千萬別讓這些縮寫擾亂他們對設(shè)計意圖的感知。

2. 小心使用顏色

線框圖必須是一系列非黑即白的長方形，還是說允許五顏六色設(shè)計的出現(xiàn)？Neither，實際上想清楚地傳達設(shè)計僅需遵循一下簡單的原則：

• 使用灰色陰影作為界面的線框結(jié)構(gòu)和內(nèi)容
• 使用不同灰度的區(qū)塊來表達層次
• 將所有圖片和icon保留成灰色以防視覺上的突出，在不同元素間適當使用對比保證可讀性
• 可以適當考慮使用顏色高亮，表達特殊意義：例如藍色代表鏈接，紅色代表警告，綠色代表確認等
• 避免黑色，黑色的邊框會讓線框凌亂，在許多情況下“真正的boxy”反倒會成為干擾物

3. 避免過度設(shè)計

過度設(shè)計是新手用戶體驗設(shè)計師的常見錯誤，嘗試以簡化、清晰和快速的方式傳達設(shè)計理念，不要太花哨。僅僅因為線框圖不要看就花費大量時間制作界面元素會很浪費時間，因此每當思考一個特定元素是否準備好時，請問你自己如下問題：

• 它是否能幫助（讀者）對該產(chǎn)品用戶情境上下文流程的理解？
• 它能清楚地傳達其意義和價值嗎？
• 你的同事能理解它嗎？

不要自問設(shè)計是否好看，請自問是否合理。

4. 使用真實（近似）尺寸

務(wù)必建立一塊真實尺寸的畫布。例如Web應用程序的寬度為980px，則也應在980px畫布上進行wireframe的設(shè)計。為什么非得這樣做？的確在1200px的畫布上進行元件布局要比980px的畫布上容易太多了，但我們最終還是得將內(nèi)容壓縮到指定規(guī)格的空間中去。在引起產(chǎn)品開發(fā)的混亂前，還是乖乖遵守這種約束吧。

5. 記得功能可見性！

用戶體驗設(shè)計之父唐·諾曼曾借詹姆斯·吉布森提出的“功能可見性”（affordances）的概念來描述用戶根據(jù)感知到的某些事物獲取暗示，從而產(chǎn)生行為的現(xiàn)象。例如界面設(shè)計中的按鈕往往看起來像是能被按下的；標簽欄似乎能提醒用戶在內(nèi)容區(qū)塊間進行切換的行為等。因此為了清楚表達你的idea，你的按鈕就必須要像按鈕、標簽欄就必須要像標簽欄。對于最終產(chǎn)品，功能可見性的意義在于指示某種特定行為，而在線框圖繪制階段，它能讓你的表達更容易被直觀地理解。

綜上，我們已經(jīng)遍歷了所有wireframes的設(shè)計原則，如果你的確遵守了，我相信你能做出一份很好的交付成果。但在這里我還想說的是，如果脫離了整個故事（story）的上下文（context），即便是極具美感的wireframes也不能幫你傳達設(shè)計思考。我特地在這里故意使用了“故事”一詞，因為就像是你喜歡的故事書一樣，在設(shè)計中你也會遇到：

• 一個主角（也就是你的用戶）
• 一段情節(jié)（也就是用例）
• 一個問題（也就是用戶面對的問題）

如果你精心制作的線框圖僅僅講述了故事的一部分，片面地呈現(xiàn)了一個用例和問題且并未交代與主角有關(guān)的信息，那么你的讀者可能很難把控整個畫面。想象一下沒有任何英雄的一部指環(huán)王，如果它僅僅簡短地提到了戒指，索倫之戰(zhàn)以及大量對中土世界的大量描述，你仍然會摸不著頭腦，沒有繼續(xù)讀下去的意愿，畢竟太難理解了。

如今一提到用戶體驗設(shè)計（UED），人們就往往想到Wireframing、畫線框圖啥的。但與其說UED就是設(shè)計Wireframing，不如按照字面意思將它理解為對“體驗”本身的設(shè)計——我們希望能通過一些方法對目標群體與產(chǎn)品交互的行為方式產(chǎn)生影響。為了做到這一點，我們就要寫下完整故事，以具有說服力的方式告訴團隊和利益相關(guān)者，從而鼓舞他們采取行動。你有一大堆工具和方法在幫助你完成這項任務(wù)：

• 用戶畫像（Personas）
• 用戶故事和用例（User stories and use cases）
• 用戶流程圖（user flows）
• 概念圖（Conceptual diagrams）
• 商業(yè)模式畫布（Business Model Canvas）以及其他

牢記你的目的永遠是描述清楚用戶是誰，問題是什么，以及解決方法是什么，所以務(wù)必選擇最有利于你連貫且吸引你的聽眾的敘事手段。

想象一下某天一個鉛筆供應商突然闖進我們的辦公室，要求我們在明天前做出一個大量售賣鉛筆的網(wǎng)站（也就是說我們并沒有時間進行初步的調(diào)研和項目啟動），我們還是不是應該立即打開線框圖編輯器開始畫概念圖呢？

當然不是，一個更好的解決方法應該是這樣：我們首先需要確定用戶是誰，并召集整個團隊來采訪你的客戶來挖掘業(yè)務(wù)主要的目標群體；之后再通過創(chuàng)建用戶畫像對用戶的共同行為模式、態(tài)度、動機以及基本人口統(tǒng)計特征進行歸類，將關(guān)注點放在他們的問題，而非具體的特征上。在此之后你需要繼續(xù)詳細描述這些你所需要解決的問題，并對整個項目進行配置。你的委托人可能對此不以為然：“我需要賣更多的鉛筆！”他尖叫著，但你無需理會，因為這并非一個待解決的問題，而是項目的結(jié)果。畢竟真正問題總是待在用戶那兒。

闡述一下，為什么是用戶畫像上的這些人想要買鉛筆？他們遇到了什么問題？他們的動機、目標和態(tài)度又分別是什么？和你的委托人談?wù)剺I(yè)務(wù)方面的事，確保自己了解了合同上的需求。這些討論和思考的過程可能花費較多的時間，但我相信它確實有助于更好地了解項目并創(chuàng)建故事，直至你們真正令用戶滿意。

本文譯自designmodo上的博文《The Aesthetics of Wireframes and the Importance of Context》，若翻譯有誤歡迎指正。

作者：Marcin Treder

譯者：ARILIANO

原文鏈接 https://designmodo.com/aesthetics-wireframes-context/

本文由 @ARILIANO 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。