這次呈上 Beforweb 合作作者 SL 的譯文，《The Design Fidelity Conundrum》，原文來自 IBM 的設計師，探討如何選擇設計產出的保真度。

一、關于設計保真度的難題

在尋求用戶反饋時，怎樣的設計保真度最合適？

△ 一個 Dashboard 部件的低保真、中保真、高保真界面設計稿。

沒有任何一個產品的設計和完善是一步到位的。這樣的事就是不會發生。達成一項絕佳的設計，通常是一個想法經過不斷地嘗試、測試、改進并隨時間迭代的結果。這就是為什么在 IBM 設計中心我們將「Loop」作為我們的核心原則之一：

△ IBM 設計思維「Loop」——這一視覺形象充分體現了優秀的設計作品是非線性的。

我們嘗試將這種思維運用到我們所做的所有設計之中。因此，無論是項目研討會活動、團隊會議還是一個新的設計工作，我們都會：

• 觀察（了解所涉及的人群：他們的背景、目標、習慣等，并檢驗我們的想法）
• 反思（建立理解并形成意圖）
• 創造（探索想法和原型的可能性）

然后循環往復。

我們的設計師被鼓勵「在開放的環境中工作」——也就是說，要盡早、盡可能頻繁地尋求反饋，并且把任何產出都視作原型。本質上，我們希望甚至期待人們快速失敗，并從收到的反饋中學到東西，然后迭代他們的想法，直到越來越多的設計決策得到驗證。

因此，我們非常清楚，當評價設計優劣和獲取用戶反饋時，快速且盡可能早地獲得反饋遠勝于緩慢或拖延。畢竟，我們尋求反饋的原因，是可以利用獲得的信息，進一步改進我們的設計。（如果你一直等到一個東西被基本設計和建造好之后才去尋求反饋，那么在很大幾率上，針對這些反饋進行的修改或是為時已晚，或是必須付出高昂的代價。）

△ 一些非常前期的低保真線框圖，探索一種可能的任務流程。這種前期的低保真設計輸出有助于獲得快速而真實的反饋。

在尋求用戶反饋時使用低保真設計稿的另一個好處是：受訪者可以看到你仍然處于早期的想法階段，便傾向于更自由地提供他們真實的想法和感受。相比之下，如果你給受訪者展示高保真設計稿，他們很可能認為已經有很多的細節已經在之前的設計中被充分考慮，因此，他們很可能不愿意分享任何批評意見以免冒犯你。類似地，他們也可能會認為大的設計方向已經確鑿無疑，進而只會狹隘地針對一些特定的方面進行反饋，比如文字、顏色、圖標等等。

因此，使用低保真設計稿可以成為一種獲取早期、快速而真實用戶反饋的好方法。

到目前為止看起來還不錯。

△ IBM 的視覺設計師 @NatalieCaudell 的早期手繪設計探索

然而，你也可能聽到有人告訴你說：如果想測試某人在一個特定場景中的反應，「測試」或「模型」越接近它所模擬的真實情況，就越能確信他們在測試場景中的行為將真正代表他們在真實場景中的反應。

所以，設計師該怎么做？

盡管低保真設計稿與最終產品還相差甚遠，我們是否應該盡早向用戶展示低保真的設計構想？還是應該一直等到我們能展示更多的高保真設計或原型？

我的觀點是：

無論是使用低保真的構想探索，還是高保真原型，或是介于兩者之間的任何形式，都應該去積極尋求用戶反饋。

簡而言之，這不是二選一的情況。幾乎所有的案例中，在項目生命周期的多個階段積極尋求設計反饋是有意義的。隨著你從第一版設計到第二版、第三版、第九版、直到第十五版，越來越多的部分將被測試、精煉和完善。

二、一個范例

IBM Cloud Event Management 是 IBM Cloud 上的一項相對較新的服務，它幫助 DevOps 團隊監控事件，識別沖突，并為操作員的「操作手冊」收集知識和經測試后的步驟指導，以便能夠更快地避免或解決將來的沖突。

以下圖片展示了 Cloud Event Management 團隊在探索操作守則創建頁面時所繪制的不同保真度的設計稿。在每個階段，用戶和利益相關者都參與了評審，這為設計團隊提供了寶貴的反饋意見，用于指導他們的下一輪設計優化。

△ 來自 IBM Cloud Event Management 設計團隊的設計稿，圖片展示了它們是如何運用不同級別的保真度來推進設計的。

• 第一張圖片：設計團隊的早期手繪草圖之一，探討了操作守則編輯器的一些關鍵概念。
• 第二張圖片：一個中保真的線框稿，主要集中在編輯器本身。這里團隊開始探索使用不同的顏色來表示參數、命令和跳轉鏈接。
• 第三張圖片：最終的高保真設計，它不僅包括核心編輯器（每一個步驟在視覺上區分開），還包括標記、參數、命令等與特定操作守則相關的獨立區域。

三、選擇與你所尋求的反饋類型最匹配的設計保真度

每個項目都是不同的，但是作為一個大致的指南，下列每一個階段都可以提供一個很好的機會來接收有用的用戶反饋：

• 初始用戶和市場研究。
• 驗證項目核心想法、概念、隱喻等（例如，甚至在動筆寫之前，通過口頭上與他人討論、剖析和改善它們，你就可以開始「測試」你的想法了）。
• 早期的低保真度設計（例如顯示主要用戶界面的紙面草圖）。
• 中保真度設計（例如展示大致頁面布局、更有意義的文本和實際界面控件等的線框圖，用來測試設想的單用戶任務流程）。
• 高保真度設計（包括色彩、標識、精確的布局等等）。
• 用戶可以與之交互的原型（請注意，原型本身可以是低、中、高保真度的設計稿）。
• 產品某些部分的代碼原型（例如顯示用戶界面中的關鍵功能或微交互等等）。
• 早期演示版本（不需要等到所有預期功能都完成）。
• 測試版產品。
• 正式發布版產品。

△ 如何在產品生命周期的不同階段使用不同保真度的設計。(本圖最初由 Tracy Lepore 發表于這篇文章中，用于解釋「Design Continuum」 的草圖。)

關鍵在于要仔細考慮你需要驗證的設計工作具體是哪些方面，然后確保你分享的設計或原型具有與之匹配的保真度。例如，如果你想要驗證站點導航結構，使用顯示不同導航結構的非常低保真的界面模型可能就足夠了，但是如果您想驗證一個特定工作流的用戶體驗，一個中到高保真且可點擊的原型可能是最合適的。

總結

當要選擇一個合適的保真度來測試你的設計時，沒有一刀切的「正確」答案，它將始終取決于具體場景。仔細考慮你想要測試的內容，然后選擇最合適的保真度。

并且銘記以下幾點：

• 進行一些用戶研究總是比不研究要好。
• 在你之前原型基礎上，根據收到的反饋來評審和改進。記?。涸O計體現在在細節之中！
• 然而，最好不要完全依賴于用戶測試低保真的設計，因為它們?不可避免地包含著各種「偏差」，低保真設計實際上只是基于當時所知的最終產品的大概樣子。
• 但是同樣的，不要等到你有了一個完整編寫好的原型之后才尋求反饋，因為此時基于收到的反饋做出更改將比之前付出更多的代價。
• 記住，高保真度并不總是意味著大量的付出。你可以使用 Marvel 這樣的工具快速創建可點擊的交互原型，而無需編寫任何代碼。
• 說到代碼，想要獲得特定界面組件的一些初始用戶反饋，有時一個快速的 CodePen 演示可能就是所需的全部內容。

有關使用不同類型的原型（靜態的還是交互式的等）和不同保真度的更多信息，請參閱 Nielsen Norman Group 的這篇文章。

最后，如果你認為所有這些用戶測試似乎費時且昂貴，請牢記：

不管你的產品是什么，你設計的每個部分終究會被測試到（仔細想想看）。真正的問題是：你希望這些測試發生在何時，是在你有時間整合反饋意見之前還是之后呢？

原文鏈接：《The design fidelity conundrum》??Arin Bhowmick

歡迎關注譯者的微信公眾號：「Beforweb」

圖片素材作者：Shadhin Arafat

「從零開始設計App」

• 《設計師怎樣從零開始設計一款APP？》
• 《從零開始設計一款APP之如何做原型圖》
• 《基礎小課堂！從零開始教你做高保真原型圖+UI 設計規范》

================明星欄目推薦================

優優教程網： UiiiUiii.com 是優設旗下優質中文教程網站，分享了大量PS、AE、AI、C4D等中文教程，為零基礎設計愛好者也準備了貼心的知識樹專欄。開啟免費自學新篇章，按照我們的專欄一步步學習，一定可以迅速上手并制作出酷炫的視覺效果。

設計導航：國內人氣最高的設計網址導航，設計師必備： http://hao.uisdc.com