相信不少設計師朋友們面臨過這樣的困境：滿懷成就感地交稿，精心制作的高保真原型卻遭到老板或者客戶的一票否決，只好按照大家的意見，花費大量時間去做修改。實際上經驗豐富的設計師在初期往往先使用低保真原型來表達產品概念，在后續與用戶的溝通交流中收集反饋，確認了功能需求之后再輸出高保真原型圖。
在研發流程比較完善成熟的大公司，團隊中不同角色的成員會按工作流程，逐級輸出原型：PM 出【低保真線框圖】，UI 設計師出靜態的【中保真頁面】，交互設計師出【可操作、有動效的高保真原型】。大家互相合作，將自己的產出物和整體產品有機融為一體。
但在研發流程不太完善成熟的企業里，尤其是對于一些人手緊缺的創業公司，往往一人兼著數職，比如產品經理可能同時兼著用戶研究員、交互設計師的角色，有的UI設計師還兼著前端工程師的角色。所以業界比較成熟的研發流程在這些團隊的項目實施過程中總會產生出各種變形。導致文章開篇問題的最大禍端并非那個直接出稿高保真原型的設計師，而是在于客戶和老板本身就期望能夠直接看到高保真原型。
實際上，很多客戶對軟件研發流程尤其是互聯網產品的研發流程不甚了解，有些老板和創始人對于產品也只是停留在概念、想法階段。如果提交給他們一份低保真原型圖，缺少項目/產品研發經驗、對設計師工作流程不甚了解的他們很可能會質疑設計師的工作能力。比如，要做一款APP，他們期望看到的乃是在應用商店里下載到的、自己手機上安裝的那些已經實施完成的成品，這些成品當然高保真地不能再高保真了。如果設計師提交一份低保真地線框圖出來，黑白灰的單調顏色和線條大概會把他們嚇到，難道這就是未來要做的產品么？他會本能地抗拒和排斥，而缺少充分的耐心去看產品的真正精髓所在，那些核心功能點的設計、用戶使用流程的精心模擬、每個界面擔負重任的反復推敲，設計師在低保真原型中傾注的這些心血，老板/客戶因為不夠內行可能無法洞察到其精髓所在。而容易更多地從視覺感受上去評判一件作品的好壞。
在產品研發過程中，最大的災難就是——老大只要看高保真的、成型的、漂亮的產出物，然后對著高保真原型發表一大通關于產品整體規劃、架構設計、主題功能等一些原則上的問題和錯誤。如果說產品設計像是修建一座建筑物，那早期的概念設計、草圖和低保真相當于打地基，當這個建筑物不僅打完了地基，而且一層層蓋起了所有的樓層，拔地而起，并且裝修好了所有的門窗之后，從未露過面的老大前來視察，忽然說，你這個樓啊，地基打錯了，應該打在左邊的位置上。好吧，一切推倒重來。這種決策方式是對企業各種資源和人力勞動成果的不尊重，一旦早期的、基礎的、原則上的東西被否則，后面的功夫就白費了。
如果已經預見到可能面臨雙敗雙失的局面，產品經理、項目經理或者某個負責人有責任和義務和客戶、老板溝通，闡述業界軟件開發的標準過程，敏捷流程和精益流程對于項目/產品的好處，可以規避掉的風險。同時闡明在這種更高效、風險更低的產品流程中，每個階段的產出物有何特點。尤其是要和他講清楚什么是高保真原型和低保真原型。這樣在提交低保真原型的時候，就可以讓老板/客戶清晰的看到目前所處的階段，也請他參與進來，明確該階段要解決的核心問題是什么，而他又能為這個階段的工作順利進行提供什么樣的幫助。
那到底什么是高保真原型和低保真原型呢？業界通常用視覺、交互的細節來衡量原型的保真程度。顧名思義，高保真原型具有高度逼真、接近產品最終真實形態的特征，包含產品細節、真實交互、UI視覺等；而低保真原型就是保真度相對較低的原型，它更關注產品功能、結構、流程，低保真原型圖上只提供簡單的框架和元素，來表達出產品大致的輪廓，但距離產品最終的真實形態還有著相當大的差距。如果要更加簡潔明了地表達高保真原型和低保真原型，可以用如下的計算公式。
低保真原型 = 線框圖+無交互/簡單交互效果
高保真原型 = UI效果圖+完整/細致的交互效果
關于高保真原型和低保真原型的區別，下面一張圖可以非常直觀地顯現出兩者的異同。這是一個鐘表，左半邊代表中/低保真原型，而右半邊代表高保真原型。大家可以看到，左半邊僅是用一些線條來勾勒出一個鐘表的形狀，并沒有繪制真實的顏色；而右半邊看起來幾乎和真實的鐘表一模一樣。左半部分雖然沒有繪制到如同實物般逼真，但是能夠讓人一眼望去知道這是一個鐘表，而且其大小、形狀也一目了然。右半部分則從材質、工藝、紋理等等細節上展示出了一個鐘表的最終成品形態。
為什么常用到的原型是低保真？
制作低保真原型相對快速，成本較低，省時高效，便于在初期就進行產品方案的討論、驗證，盡快獲得反饋，盡快發現問題和修復問題，能夠讓人把精力專注在產品最核心的結構層和框架層。而制作高保真原型地時間較長，成本較高，在未能驗證方案是否可行地情況下就花費大量地時間和資源來設計高保真原型是不可取的。所以，更多的設計師喜歡從低保真原型入手做起。
但是由于低保真原型比較粗糙，距真實原型差距較大，不夠真實形象，所以和不了解研發過程的終端用戶溝通解釋起來會比較復雜。它更加適合內部討論使用，而不太適合終端用戶的使用體驗，尤其是對于C端產品用戶對于低保真原型會非常陌生。
何時需要用到高保真？
在完成低保真原型并且對需求和功能進行反復討論、驗證后，下面就可以進一步做出高保真地動態交互原型來測試我們的方案，讓用戶的試用體驗更順暢，讓開發對產品的理解更加準確無誤，顯著降低開發人員和產品人員的溝通成本。
值得注意的一點是，所謂的“高”保真并不一定就是從外觀上看和真實產品非常接近，保真度也可以說是交互邏輯的高保真，或者是代碼性能、流量消耗的高保真。高保真原型的交付物也不僅僅是一個原型文件，還可能需要包括：原型的概念或想法說明； 詳細交互動作與流程；各類后臺判定；詳細界面；界面切換動態；異常流處理等。
如果是面向終端用戶或者是投資人等人群進行原型講解和展示，高保真原型就能發揮出較大的魅力，逼真的交互，漂亮的畫面會令人印象深刻。
中保真——低保真和高保真之間的折中方案
我們已經分析了高保真原型和低保真原型的特點和適用場景，在實施過程中，難道一定要在高保真原型和低保真原型之間做出非此即彼的抉擇么？實際上，我感覺很多產品界面存在一定的類似性。
比如，我們要做一個網站，除了登陸、注冊和首頁之外，其他的頁面大多可以歸于兩大類，列表頁和內容詳情頁，列表頁可能會有文章標題排版格式，也可能會有圖文排版格式，可能會有每個圖文單排，也可能會有多個圖文并排的狀況。而內容詳情頁又包括了以文字、文章為主體展示形式的頁面，也可能有需要專門定制的展示介紹頁面。
我們可以把這些網站內容歸為幾個主要的類別，在完成低保真原型并且經過需求討論之后，可以先針對每個類別做一些示例頁面，或者挑選個別核心的關鍵頁面，比如對于網站來說，首頁面是最為關鍵核心的頁面。用高保真的方式先把這幾幀關鍵界面完成，然后盡快和團隊成員和相關人員進行交流討論。大家對這幾類或者幾個關鍵頁面商議出一種比較精細地設計方案，比如，主色調的選擇，整體風格的設定、色彩的搭配，布局、格式等等。先把這少數主要界面敲定以后，剩下的界面可以遵從類似的設計風格。這樣就不至于說設計師從頭到尾一頁不少地把高保真原型做完以后，大家建議所有按鈕的顏色都要改變，或者主題色調從橙色變成綠色，或者是所有的返回功能都由文字改為圖標，諸如此類，如果設計師要逐一修改，幾乎會涉及到每個頁面的修訂，從頭到尾要檢查過一遍。但是，如果在少數關鍵頁面敲定以后，再來做其他頁面的設計，返工迭代的時間成本就會低很多，工作效率會提升不少。
到這里，我們已經把高保真、低保真的那些事兒前前后后、里里外外地叨叨了一遍，如果有人再毫無道理地讓你一下拿出一份高保真原型，你就有足夠的理由說服他。是的，高保真很好，但要考慮清楚成本和風險代價，低保真雖然粗糙，但是能夠幫你更快更好地完成項目。反正這兩個版本早晚都會出的，只是選擇不同的方式，會帶來不同的實施效率。當然，如果有需要，在合適的階段先出一份中保真也是不錯的選擇噢。
