低保真原型是模擬產品特定功能和界面的設計作品，而不是實際的最終產品。低逼真度的原型往往主要通過線框或草圖來實現，壹個或多個場景任務下的界面設計內容往往體現在企業軟件中。當然很多也是通過ppt或者其他工具實現的。有些工具視覺上很好看，看起來和真實界面壹樣，但是不能交互。因為開發者認為夠用了，所以壹般認為低收入的原型就夠用了，不需要交付更多的文檔。
UI設計規範實際上是為了更好的交付給軟件開發者的產品設計規範文檔，主要定義了產品在實現人機交互時應該滿足的設計點。文檔內容可以分為以下幾個部分:
總結。主要解釋壹下這個規範主要包含了什麽，低保真原型和這個UI規範的關系。比如下面對關系的描述可以清晰明了地寫“xx低保真原型所體現的界面設計和明顯的交互在本規範中不再重復”。
系統交互框架:主要描述軟件界面的框架組成以及界面中典型模塊和關系的描述。同時建議說明適合設計此框架的用戶、業務場景、任務、頁面之間的關系，讓開發者對設計背景和人機交互的框架有壹個基本的了解，能夠找到與自己業務相關的關鍵場景和任務信息。
設計元素:主要說明視覺上可以看到的設計元素，如屏幕分辨率、文字的字體和大小、排版風格和顏色、標點符號和編碼，以及後面需要滿足的視覺對象規格的明確描述。
交互設計:壹般至少需要說明鍵盤交互和鼠標交互的設計需求，因為電腦輸入基本就是這兩種。但是，也有新的交互技術應用，如語音和動作輸入，如果在商業使用中體驗非常關鍵，需要清楚地解釋這些應用。同時，在界面操作中，瀏覽類視圖控件，如菜單、選項卡、樹形視圖、表格和隱藏區域，編輯類控件，如按鈕、文本框、下拉列表、列表框、單選框、復選框和彈出窗口，有時在低保真原型中難以表達清楚，在UI規範中可以解釋清楚。例如，壹個按鈕至少可以有三種狀態:無效、有效和已單擊。如果經驗要求高，狀態可能更多。例如，鼠標懸停在按鈕上，並專門設計了不同的顏色或紋理，以便用戶可以明確地點擊按鈕。在Web界面上，鏈接是壹種非常特殊的按鈕，它的狀態可以多達五種或更多。在線幫助的交互需求也可以寫，但這部分往往與信息架構和數據開發有關，往往單獨放在數據的設計需求中。
最後建議附上產品設計所依賴的設計原則，讓開發者了解相關的設計理念，同時培養開發者盡可能掌握更高的經驗設計技巧，要求開發者遵守基本的設計原則。
嗯，如果沒有設計規範，只有樣機可以嗎？其實現在很多產品都不重視UI設計規範，包括交互設計師，也覺得寫這個文檔要花很多時間。平時很多問題都溝通過了，沒有寫的動力。因此，開發人員對更好的產品感覺更好，重用更多的代碼，有時會減少風格不壹致的現象。但是由於規範的缺失，很多開發者由於開發時間和效率的問題，不會有那麽多的考慮和溝通，最終的產品界面也有很多小問題。只是企業用戶的包容度更高而已。畢竟他們是為了工作，不在乎那些小問題。這項任務必須完成。
但實際上，從工作效率的角度來看，成功完成項目並高質量交付的工程師都可以理解，這個文檔在提高效率方面可以起到很多作用。比如同壹個設計問題，如果壹個人問，或者UE問跟蹤，就解決了，使用文檔的意義就沒了。但是在企業中，往往開發人員很多，要開發的頁面有幾百個甚至上千個。這個時候很多問題重復率很高。把這些問題寫清楚在文檔裏，讓開發者準確理解，比每次重復回答要有效和高效得多。而且，當壹份文件被書寫時，它的語義和語法往往比口語嚴格得多，這可以防止口頭傳遞的信息質量下降。俗話說，“好的大腦比壞的書面大腦更糟糕”。很多時候，人們的口頭交流是非常高效的，但是很多因素，比如默認的設計風格、圖標等，都被忽略了，但是每個開發者往往由於自身的經歷而有不同的理解。所以即使對於很多聰明人來說，形成壹些好的想法並口頭表達出來也不是什麽難事。但是，對於壹個復雜的軟件，幾十個人即使通過口頭交流，也很難檢查出各種漏洞和需要解決的問題。
但是妳寫下規格就不壹樣了。可以壹遍壹遍的復習文檔，壹遍壹遍的補充和完善表述中的不完善和不嚴謹。文檔可以隨時用來思考，理解，慢慢優化。這些關鍵文檔對於大團隊的溝通是絕對必要的，無論是對自己還是對開發者，否則會出現很多問題。
另外，在文檔編寫的時候，新的UE或者其他工程師可以在未來對新產品開發版本或者舊版本進行優化，這比重新理解系統，重新整理規範的難度要小得多。而且，如果企業不重視框架文檔的描述，很可能以後會有新人去新的框架，因為人總是喜歡做自己擅長的、能理解的事情。而且企業往往存在人員流動和流失的問題。雖然幾年後R&D部門仍然存在於壹個誇張的企業中，但它可能會覺得事情不同了。對於這樣的生存環境，企業產品研發沒有相應的設計文檔傳遞，企業的設計風格會非常混亂。企業形象也會受損。
同時，在復雜產品中，往往需要在企業自有產品的基線版本開發完成後，根據現場環境進行定制開發。這時候如果沒有UI規範文檔指導，很可能設計出來的其他頁面和原來的頁面差別很大，用戶會覺得很不習慣。為了保證良好的定制化產品開發體驗，企業還可以相應地將UI規範改為體驗設計指南，引導本地或合作外包或其他R&D企業盡可能使用自己提供的組件和壹致的風格，保證企業品牌形象的傳遞和延伸。在這壹點上，我非常佩服蘋果的經驗指南和做法。細節和原理寫得很好，不按照規範要求使用相應圖標，就通不過。
當然，在實際的企業軟件開發中，很多軟件不壹定需要考慮那麽多。應該更加註意效率。第壹，應根據客戶的需求開發，首先爭取內部和外部客戶認可和生存的機會。這樣就不需要按照上面的要求輸出死板的文檔，在相應的原型或者可視化效果圖中明確標註出來也是壹個很好的方法。只要向所需的R&D人員清楚地解釋了必要的UI設計元素，以後組織它們就很容易了。
軟件積累深厚的企業還可以通過高保真原型和組件化來降低產品UI設計規範的復雜度，因為高保真原型和組件直接列在文檔的相應描述中，開發者會直接下載或復制相關代碼，這樣編程中很多需要在組件內部實現的交互就不需要重新編程，開發者通過繼承樣本代碼就可以快速實現高質量的界面交互。但這需要產品或企業先做平臺積累或高保真的樣機和組件，開發或經驗管理者需要遠見卓識和良好的配合才能享受精神。
所以這個道理壹定要對產品講清楚，讓產品業務開發者真正理解並配合UI設計規範的編寫，做好產品的設計和實現。否則，壹些開發者只看到了低保真的原型，卻仍然不知道交互設計師或者可用性工程師的作用，所以他們會說交互設計只是壹幅畫。那我們不解釋不好，但是有點被動。比如交互設計師不僅僅是畫師(交互設計的輸出不僅僅是線框和單頁設計)，他的交付還可以包括視覺元素設計、特殊交互描述、高保真原型、用戶場景、風格指南等等。這樣解釋有點弄巧成拙。
如果妳或者產品有這個文檔，那些只看原型不看UI設計規範的人會說交互設計只是個拆圖的。妳可以說，不會，我們也會輸出UI設計規範。為什麽？就解釋壹下我上面寫的。如果他說，我怎麽沒看到這個規範，妳就說“那是因為妳太差了，妳那裏都看不到！”" .