1、UI設計網頁設計字體規范應該要注意什麼
可以參考常規字體的使用規范:
1、在每個項目設計中只使用1-2個字體樣式,而在品牌字有明確的規范的情況下,只需要一種字體貫穿全文,通過對字體放大來強調重點文案。字體用的太多,越顯得不夠專業。
2、不同的樣式的字體,形狀或系列最好相同,保證字體風格的一致性。
3、字體與背景的層次要分明,確保字體樣式與色調氣氛相匹配,等。
(1)ui網站設計規范擴展資料:
網頁設計
1、需要根據消費者的需求、市場的狀況、企業自身的情況等進行綜合分析,從而建立起營銷模型。
2、以業務目標為中心進行功能策劃,製作出欄目結構關系圖。
3、以滿足用戶體驗設計為目標,使用axure rp或同類軟體進行頁面策劃,製作出交互用例。
4、以頁面精美化設計為目標,使用PS、AI等軟體,調整,使用更合理的顏色、字體、圖片、樣式進行頁面設計美化。
5、根據用戶反饋,進行頁面設計調整,以達到最優效果。
2、UI設計和網頁設計的區別?
要想了解這兩者的區別,就先來看看他們的定義是什麼。UI設計是指軟體的人機交互、操作邏輯、界面美觀的整體設計,用自己的話來說就是設計軟體和用戶的互動方式。而網頁設計是根據企業希望向瀏覽者傳遞的信息,進行網站功能策劃,然後進行的頁面設計美化工作。現階段的UI設計,通常來說是一定程度上包含了網頁設計的內容的,目前的UI設計面向的方向很廣泛,除了UI設計,還包括了網站管理、網頁設計、交互平台設計、app移動界面設計、用戶體驗、產品設計、電商包裝設計等。而網頁設計通常來講是專門負責網站中各個頁面的設計。而網頁設計中,最先提到的就是網頁的布局。布局是否合理、美觀,將直接影響到用戶的閱讀體驗及訪問時間。
總之,UI設計包含有網頁設計的內容,但是網頁設計是一種更專業的網頁界面、布局等設計。
3、UI界面設計規范有哪些?
用戶界面設計包含為機器和軟體創建的所有界面設計,例如網站和移動應用程序的外觀,以及它們的方向和易用性。GUI設計在用戶與應用程序或網站的交互方式中起著至關重要的作用,這意味著唯一良好的UI設計是實現簡化和無縫體驗的設計。
用戶界面設計要遵循哪些原則?
1、明確。
對任何界面而言,「明確」是首要的也是最重要的一點。設計師們在設計的時候,要去關心人們為何會使用這個應用,去了解什麼樣的界面是能幫助他們與之互動的,去預測人們在使用時的行為並能夠成功地反饋給他們。
2、交互。
界面的存在是為了讓人和我們的世界產生互動。它的功用和效果是可以被測量的。但是它們不是功利性的。優秀的界面不但能夠讓我們做事有效率,還能夠激發、喚起和加強我們與這個世界的聯系。
3、直觀操作。
要抓住直觀操作這個最初的目標,界面設計要盡可能的簡潔,更多的可識別的慣用自然手勢。理想情況下,界面會變得非常細微,用戶在會有直觀操作的感覺。
4、讓用戶掌控一切。
人們會在自己能掌控的環境中感覺最舒心、最放鬆。通過定期的梳理系統狀態,描述因果關系,並且在每一步操作都給出提示,讓用戶感覺每一步操作都在他的掌控中。
5、遵循用戶行為。
人總是對符合期望的行為最感舒適。因此,設計出來的元素,看起來應該像它們本身特徵一樣。在具體操作中,這意味著用戶只要看到這個界面元素,就應該能猜測出這個元素是做什麼的。
6、前後一致。
為了保持一致性,新手設計師通常在會把相同的視覺處理(重用代碼)方式用在,應該用不同的視覺處理方式的元素上。
7、視覺層次。
強烈的視覺層次會讓畫面有清晰的瀏覽次序。如果要在畫面中添加一個視覺強烈的元素時,設計者應該要重新調整頁面上所有元素的重量分配,來達到強烈視覺層次的效果。
了解用戶界面設計原則是你做出優秀作品的必要條件,而掌握UI設計師必備的技能才是你決勝高薪的關鍵。
4、到底什麼是UI設計規范
UI設計不僅是讓某個APP或軟體有個性有品位,吸引用戶,還有一個是操作舒適、簡單、突出軟體的定位和特點,藍湖的設計規范雲可以嘗試一下。
5、ui設計規範文檔怎麼寫
ui設計規范;ui設計規范有哪些?這個問題對於ui設計師來說應該是比較關心的吧,因為作為ui設計師,ui整理設計規范也是設計能力的一種體現。所以,無論是自己設計創作還是推動產品開發,你的設計規范是否完善,對產品的質量起著決定性的關鍵作用。那麼我們今天就來聊聊這個問題吧!
ui設計規范有幾大分類組成:
1、Logo
品牌印象的直接感受,根據頁面不同背景所使用的Logo圖也不同。將產品中所使用到的Logo統一分類,以下引用Moby』s Petshop UI Style Guide的Logo資源例舉說明。
Moby』s Petshop UI 的Logo由圖形和文字組合而成,而品牌色為藍色,Logo的使用也需要考慮到Footer黑色背景下的Logo。所以用Logo的橫豎向排版和單個Logo圖形來分類更好。
分類裡面則展現品牌色的Logo、品牌色背景的Logo、Footer黑色背景的Logo。
2、標准色
顏色是設計最重要的部分,沒有之一。細節決定品質,所以對顏色的運用格外細致,顏色的搭配直接決定產品的品質感。顏色大致可分為品牌色、文本顏色、背景色、線框色等。給顏色添加關鍵詞,明確用於什麼界面。
以下引用real-pixels UI Style Guide的顏色規范,可以借鑒的是每個顏色不僅標注了顏色值,而且右側給出了顏色使用的場景,值得借鑒的是按鈕Normal狀態和Hover狀態的顏色值放在一起,這樣,對不同狀態顯示的顏色感受更直觀。
對顏色值統一規范命名變數,提高開發效率的同時更好的維護設計規范。
在前端開發中,對顏色值進行編號,這樣對代碼也有著極大的優化。定義一個設計規范的CSS樣式庫,開發過程中就不用重復修改CSS參數值,直接引用定義好的變數名就可以,這樣修改設計規范的成本大大降低。
3、字體
字體是設計中必不可少的考慮因素,不同的字體氣質不一樣,並且不同場景下帶給人的感受也不一樣。所以需要在設計的時候考慮到字體的設計效果,然後在設計規范中註明。
以下引用的是Retail Banking Service UI Style Guide中的字體規范,在定義字體名稱的同時也定義了字體的風格,並且添加了不同字體風格的預覽效果,常見的字體風格有:Light、Regular、Italic、Semibold、Bold。
4、段落設置
在實際的產品設計中,段落有很多種樣式,不同場景下的段落要求也不一樣。比如:閱讀內容的段落要求文本可閱讀性強,所以對字體、字型大小、顏色、行間距等要求簡單易讀。而帶有裝飾性的段落文本則不需要那麼嚴謹,裝飾性強就可以。
需要注意的是:在定義段落默認字體的時候還需要定義一個後備字體,即默認字體不能正常顯示情況下顯示的字體。設計的水平層次就在於對細節的打磨,這也就是段落規范在設計中存在的意義。
5、圖標
圖標是重要的軟體標識,在設計資源中是最重要的模塊之一。在軟體產品中甚至可能每個頁面都存在圖標,圖標除了美化的作用以外,還有著明確指代含義的計算機圖形。
具體分為以下三個作用:
圖標是與其它網站鏈接以及讓其它網站鏈接的標志和門戶。圖標是網站形象的重要體現。圖標能使受眾便於選擇。根據圖標大小和使用用途進行分類整理設計規范,這樣才更清晰明了。
6、圖片
圖片也是屬於設計規范最重要的部分之一,按照用途分類整理圖片資源,設計風格系統化。
7、度量
在設計的過程中,我們經常會使用一套規范的度量標准,來保持產品的一致性,分別為圓角值、間距、大小。
對度量解釋最好的是設計中經常使用到的柵格系統(Grid Systems),運用固定的格子設計版面布局,其風格工整簡潔。這就是我們在網頁和APP設計的過程中經常使用到柵格系統的原因。
8、陰影
陰影風格及參數也是設計規范中的一部分,在整理設計規范的時候,需要注意的是陰影的參數值是網頁中控制陰影的參數值,而不是設計軟體中的參數值。
舉個例子:網頁中陰影對應的參數值為:box-shadow: type:Outset offset X:0px offset Y:4px Blur:8px Spread:0px color:#000000 ,不透明度:10%,這才是程序員需要的陰影參數值,否則最終開發出來的陰影會出現不一致的情況,無法達到規范的目的。
9、組件
常用的UI組件(Component):Button控制項、下拉框、選擇框(單選復選框)、時間選擇器、輸入框、搜索框、進度條、分頁器、提示框、警告框、表格、彈出面板、數字步進器、選項卡等。
Button控制項
按鈕是最常見的組件之一,按鈕有5個狀態:Normal、Hover、Active、Disabled 、Loading。
需要在規范中分別羅列出這五個狀態,標註上對應的按鈕填充色、邊框色、圓角值、按鈕寬度和高度,按鈕文本大小、顏色值。如果是圖標按鈕的話,除了上述參數值以外還需要標注icon和按鈕文本之間的間距和icon圖標的大小。
10、下拉框
下拉框是為用戶提供多個選擇的單選組件,優點是用最簡單的界面布局方式收納了很多的選項,需要注意定義下拉選擇框彈出的時候,滑鼠移動上去的Normal、Hover、Active狀態。
11、選擇框(單選復選框)
顧名思義,單選框是眾多選擇裡面選一個,而復選框是眾多選擇裡面可以無限制選擇。單選框和復選框都需要三個狀態,即未選中狀態、選中狀態和不可點擊狀態。
時間選擇器:
時間選擇器是選擇年月日的組件,分別對應年月日星期的信息,在設計的時候需要考慮到4個狀態,分別是:Select、Not_Select、Hover和Disable,並且寫進設計規范。
輸入框:
輸入文本框是我們軟體產品設計必不可少的組件,文本輸入框有4個狀態:Normal、Active、Disable和Error。
搜索框:
和輸入框相同的地方是都需要聚焦然後輸入內容完成操作,應該有為Normal、Active、搜索下拉狀態、Error狀態。
進度條:
這個需要在規范中註明上傳進度條的整個交互操作流程,對Normal狀態、點擊上傳/拖拽上傳狀態、上傳中、上傳成功、上傳失敗,整個流程狀態的整理。在上傳過程中,任何用戶操作都應該有及時響應的動作,這樣用戶在使用的過程中才不會迷茫。
分頁器:
分頁器是用於切換內容頁面的復合組件,常規的分頁器有上下頁操作按鈕、分頁頁碼按鈕、輸入頁碼手動查找的搜索框,以及分頁器的4個狀態:Normal、Hover 、Active、Disabled。
提示框:
提示框是一個事件觸發彈出面板顯示的組件,經常使用提示框的地方是,刪除按鈕、疑難問題點、提示類彈出信息等。這個風格設計就比較多了,設計風格各不相同,定義底板樣式、文字樣式和陰影參數。
警告框:
頁面報錯時的顯示樣式,常用的警告類信息是:操作成功、提醒用戶注意、警告用戶注意等。
表格:
表格類信息居多,應重點整理表格樣式以及文本顏色大小。
彈出面板:
彈出面板主要由4個部分組成,分別是面板內的文本信息、按鈕、面板大小樣式、蒙版顏色和透明度。
數字步進器:
數字步進器屬於復合類型的組件,可以理解為按鈕和輸入框聯動的組件,所以輸入框和按鈕擁有的屬性狀態,步進器都有。
選項卡:
切換選項卡即切換內容,和下拉選擇框不同的是,選項卡是將多個選項都排列出來的單選組件,需要考慮4個狀態:Normal 、Hover 、Active 、Disabled 。
ui設計規范,ui設計規范有哪些?這個問題介紹到這里就介紹完了,現在你清楚ui設計了嗎?設計規范對整個項目的規范性推動很強大,但是需要花時間和耐心細心打磨,所以需要花費很多時間和精力去整理資料、編輯素材、分類整合,最後還要在設計軟體中將整個規范重新排列設計。如果你還有其他關於ui設計的問題歡迎持續關注易夏嵐或者與我進行交流~
6、ui/ux網站模型設計指南?
現在的網站模板,想要比較吸引人的首先要考慮到網站的獨立性,在網站模板要符合用戶的瀏覽習慣,在設計方面設計的比較新穎、簡潔、大氣,當我們去體驗,就因為這些停留下來,網站的麵包屑導航要西細化清楚,網站的內容要發質量比較高的信息比較可靠的,這樣的信息才可以幫助到別人,網站的訪問 量也會逐漸增加.
7、UI設計的規范
快速標注尺寸和PS切圖
快速換算單位
快速繪制不同需求參考線
多個矢量圖形圓角轉換
水平、垂直或按指定間隔復制圖層
可以使用藍湖
8、UI設計規范說明書
高質量的規範文檔是一個優秀設計系統的代表物。我們詳實地描述每個 UI 組件的設計與代碼規范,來幫助設計師高效地作出決策,推動開發速度。編寫高質量的文檔需要前期規劃和一系列合理的流程來輔助,付出的成本相當高。
這個系列由六篇文章組成,致力於描述編寫組件規範文檔的過程。本篇我會從目標讀者、文檔內容、文檔結構開始。然後會涉及案例,設計與代碼指南。這些內容來自於我自己這些年的實踐經驗以及社區里大家所分享的知識。
那麼我以一個問題開始今天的主題:文檔的目標讀者是誰,他們需要什麼樣的內容,作為編寫者我們該怎樣組織文檔結構來作出清晰的表達?
文檔的目標讀者
首先:你要弄清楚誰是你的文檔的主要讀者。
工程師,設計師,還有公司里的所有人!
當一個設計系統包含了代碼指南,工程師們顯然會是讀者。那麼一個只包含了代碼指南的設計系統應該服務於設計師嗎?如果文檔里只包含了設計規范而沒有代碼(如 Material Design),工程師還是讀者嗎?
在我看來,兩個問題的答案都是肯定的。規範文檔是從不同的角度來服務於多種角色的。
除了設計與工程,它還服務於其他人嗎?很有可能,特別是當文檔所在的設計系統已經成為產品的基石時。簡短有效的介紹對於 PM(產品經理) 很有價值,QA(測試) 則比較關注案例部分…等等。
規範文檔是從不同的角度來服務於多種角色的
很多設計系統團隊還會把自己的系統公開出來,在體現共享精神的同時也能起到吸引行業人才的作用。所以文檔應該能夠體現團隊的專業與嚴謹。
文檔的主要目標是:為設計師、工程師和團隊里的其他角色服務,讓他們能夠高效地做決策。
Takeaway:設計系統的效應和影響力不只覆蓋設計與工程,一個成長中的系統必將會服務於更多的角色。
工程師,接著是設計師,然後才是其他人
為所有角色服務並不意味著平等地服務所有角色。工程師每天會查閱 10 次或更多次文檔,他們甚至會把文檔與代碼編輯器窗口並排排列!設計師的訪問次數應該是少於工程師的,其他角色則會更少。
所以誰是最重要的?以我的經驗來看,設計系統最初就是為了工程與設計之便,由工程師和設計師建立的。即使其他角色也對其有所貢獻,但他們仍是偏次要的。因此我們首先需要確保工程師與設計師的需求能夠得到滿足。
設計師與工程師優先順序最高
那麼,工程師與設計師孰輕孰重呢?我最近參與設計的設計系統項目中都需要同時服務於兩者,為設計和代碼製作規范指南。我也在一些企業的文檔中看到了對其中一方的過多偏見,或者是有將他們的目標完全分離開的傾向(稍後我會解釋)。有很多維度需要考量:設計系統的目標,他們的使用頻率,內容深度、質量、生產成本,以及和他們日常工作的相關度。
設計師 vs 工程師
Takeaway:讀者的優先順序由很多因素決定。要有預期:工程師和設計師的需求會有沖突,並盡可能地優化和處理這些沖突。如果實在不行,就要偏向於距離最終產品最近的那一方,通常是工程師。這就意味著工程師優先,設計師其次。
文檔內容
規範文檔是連接讀者與內容的媒介。內容會有不同的格式或模塊,因此成本也各有差異,而你需要最終把它們編織在一起。
文檔內容模塊:簡介和案例文檔內容模塊:設計參考和代碼參考
抽象地來看,規範文檔的內容通常包含以下四種模塊:
介紹:組件的名稱,以及一段簡明扼要的介紹。(必要)
案例:這個組件的各種形式,狀態,尺寸等等其他要素,比較好的做法是用代碼直接把這些展示出來,而不是不可以交互的靜態圖片。(必要)
設計參考:比如什麼時候應該用這個組件,允許的做法與不允許的做法,以及視覺、交互、文案方面的指南。(推薦)
代碼參考:包含 API 和其他實施及部署方面的指南。(必要)
不同的模塊會有不同的製作成本
「介紹」寫起來當然非常的短平快。結構優秀的「案例」也是值得投入成本的,並且寫起來會越來越順手。工程師也需要一個合理清晰的「代碼參考」。但是,真正有效的「設計參考」可能會非常耗費成本。
橫軸:細節的豐富程度由淺到深。縱軸:製作成本由低到高
Takeaway:規範文檔可以包含很多內容模塊。所以需要團隊在前期就進行充分的討論,對每種內容模塊做出符合自己團隊和產品價值的判斷,再投入成本去製作。
文檔的信息結構
設計與代碼:分開還是合並?
在實踐中,設計師往往會自顧自的發布或更新和自己相關的內容,工程師也一樣。這樣的慣性行為會在無意中增加設計與工程的距離。所以大家需要在前期就對文檔的信息結構達成共識。
谷歌的 Material 文檔生態就是這種距離感的代表。 Material』s design foundation 優先服務於設計實踐, 而 Material Design Lite,Polymer Project,Android Developer』s,Material UI (built for React) 都是服務於代碼,和設計規范綁定的並不緊密。
這種分離的狀態其實是有意義和理由的。因為 Material 是一個操作系統的底層系統,跨越了許多框架,團隊,平台。它的復雜度在某種意義上超越了目前世界上所有的設計系統。但你要知道大多數的設計系統並不是服務於一個操作系統的,因此不會發展至如此復雜的形態。
對於像我們一樣的產品團隊來說,設計和代碼分開是符合共識的。這種做法能夠給分別為兩種角色設計符合他們需求的體驗。
組件設計規范與 API 和代碼規范分別放在兩個網站上。來自:Atlassian
這種做法也有風險。隨著時間推移,兩個網站可能出現不同步的現象:
設計與代碼的分類邏輯出現差異(最簡單的例子就是 Loader 和 Spinner 的命名:代碼里叫 Loader,而設計里則叫 Spinner)
功能差異:設計規范里出現了代碼不能實現的功能,或者代碼里加入了設計里沒有考慮的功能。
你可能會覺得這樣也挺好,畢竟設計和代碼本身就是兩個領域。至少對於文檔的寫作者來說這種分離還是挺方便的(只用考慮自己的需求,管理自己的進度)。
但真正的讀者需要的是一個「真相的唯一來源(Single source of truth)」。如果你是一個對設計和代碼都有需求的讀者,你會發現自己不停在兩個網站間切換,兩個地方都有對你有價值的內容,這感覺就像是在打網球時陷入了拉鋸戰。
Takeaway:要慎重地看待設計與代碼的分離。雖然一開始方便了內容作者和發布者,但之後會有風險。這種做法也可能會在潛移默化中造成設計與工程的距離擴大。
合並內容的兩種方案:堆疊還是切換?
例如 Morningstar Design System 是把設計和代碼放在一個頁面里,讀者就能找到完全統一的命名,指南,功能描述。
一個頁面之堆疊式:把設計和代碼放在一個頁面中,縱向滾動來查看。
堆疊式的布局方式會使得頁面變得冗長。當然還有一種方式是使用 Tab 來切換內容。
一個頁面之切換時:把設計和代碼放在一個頁面中,通過 Tab 來切換內容。
Takeaway:將設計和代碼混合在一起是有可能的,大家可以按自己的需求來選擇以上兩種布局方式。
按類型來為內容做排列和編組
不論選擇那種布局方式,文檔內容的模塊結構和順序應該是保持一致的:
簡介
案例
設計參考
代碼參考
其實只要把「案例」放到讀者一進來就能看到的地方,把設計和代碼參考放在一步點擊就能達到的地方,就是一個不錯的設計了。下面是幾種行業內比較有代表性的模式:
左:IBM Carbon 模式 中:Hudl's Uniform System 模式 右:Lightning Design System 模式
IBM Carbon 認為代碼更應該被優先展示,將交互用法和樣式分別放在其他的 Tab 中。Hudl』s Uniform system 把順序反了過來,設計優先於代碼。 Salesforce』s Lightning Design System 把代碼和組件案例放在 Tab 上方,默認選中開發者指南這個 Tab,而後兩個 Tab 則被奇怪地留空了。
Takeaway:把簡介和案例放在一開始最重要的位置,接下來的模塊則沒有唯一的方案,需要大家自己做出符合自己團隊情況的判斷。
若頁面很長,則為讀者提供定位導航
你的文檔頁面越長,越需要給讀者清晰的認知,要讓他們知道這個頁面里會包含哪些內容以及當前所處的位置。縱向的定位導航欄是個不錯的方案:一直固定存在於頁面右側,在滾動時同步追蹤位置,並且可以包含子標題。
Morningstar Design System 在文檔頁面右側設計了一個兩級的定位導航欄
Takeaway:不論選擇哪種形式,最重要的是在整個系統中保持邏輯一致,符合讀者的預期與心理模型。
展示設計?展示代碼?還是都展示?
把設計和代碼融合,就會有讀者只對其中一個方面感興趣,他們會提出自己的意見:
設計負責人可能會問到:我能把這些代碼案例和指南隱藏掉嘛?
工程師可能會問:我能把這些和設計規范有關的文字隱藏掉嘛?
可以考慮加一個選項或按鈕來允許隱藏設計/代碼內容。比如:
Design Only:把代碼指南、代碼片段和屬性表等等都隱藏起來
Code Only:把視覺樣式指南和文案指南都隱藏,但還是要把一部分交互用法指南保留著,這對工程師們也有用。