的網頁設計已足夠設計師和開發(fā)人員在構建網站時需要考慮很多事情，從視覺外觀到功能設計。為簡化此過程，我們準備了本指南。由于篇幅限制，本指南分為三個部分，這是第三部分。
本文包含內容
第三，移動端適應
3.1響應式設計
3.2手勢操作
四，無障礙設計
4.1弱視用戶
4.2色盲用戶
4.3盲人用戶
4.4鍵盤自適應
V.測試
5.1連續(xù)測試
5.2頁面負載測試
5.3 A/B測試
6.發(fā)展移交
七，總結
第三，移動端適應
如今，大約50％的網站用戶通過移動設備訪問。這對網頁設計師意味著什么？這意味著我們必須為網站進行移動端適配設計。
3.1響應式設計
PC和移動設備具有不同的屏幕分辨率，適應性優(yōu)化尤為重要。
使用單列布局。單列布局在手機屏幕上的基本效果很好。單列不僅可以管理小屏幕上的有限空間，還可以輕松地在不同屏幕分辨率和寬高比之間進行縮放。
使用優(yōu)先級+導航模式。 Priority +由Michael Scharnagl提出，用于展示重要的導航選項，而不太重要的導航選項位于“更多”按鈕中。它充分利用了可用的屏幕空間。隨著屏幕的增加，顯示的導航選項也會增加，從而提高可視性和吸引力。此模式對于具有許多不同模塊和頁面的站點尤其有用，例如新聞站點或電子商務站點。
確保圖像適合PC和移動設備。網站必須適應所有不同的設備和分辨率，像素密度和方向。圖像適應是構建響應式網站的主要挑戰(zhàn)之一。要簡化此任務，您可以使用響應圖像斷點生成器等工具處理圖像。
響應式圖像斷點生成器可幫助您生成和管理不同大小的圖像。
3.2手勢操作
移動端的交互是通過手指完成的，而不是通過鼠標點擊完成的。這意味著在設計交互時應用不同的規(guī)則。
交互元素的大小應該是合適的。所有交互式元素（如鏈接，按鈕和菜單）都應具有手勢感知功能。 PC端站點適用于小而精確的交互區(qū)域（點擊），但移動網頁需要一個可以用拇指輕松完成的大觸發(fā)區(qū)域。當網站經常需要用戶操作時，請參閱MIT Touch Lab研究，為您的按鈕選擇合適的尺寸。研究發(fā)現，手指臉的平均大小在10到14毫米之間，指尖在8到10毫米之間，10倍和10倍; 10毫米是一個很好的尺寸。
按鈕越大，點擊就越容易。 （圖片來源: Apple）
交互需要更明顯的視覺表達。在PC端，用戶可以在懸停在元素上時提供額外的視覺反饋（例如顯示下拉菜單）;在移動端，沒有懸停狀態(tài)，移動用戶必須單擊才能查看響應。因此，您應該確保用戶可以正確預測界面元素的含義。
四，無障礙設計
該產品必須能夠被任何人使用。為身體不適的用戶進行設計是設計師實踐同理心和體驗世界的一種方式。
4.1弱視用戶
許多網站的文本使用低對比度模式。雖然低對比度可能更時尚，但很難識別。對于低視力和對比敏感的用戶，低對比度不是用戶友好的。
淺灰色背景上的灰色文字很難閱讀。經驗將非常糟糕，或者設計毫無意義。
低對比度文本在PC端難以閱讀，在移動設備上變得更加困難。想象一下，在明亮的陽光下行走時，在移動設備上閱讀低對比度文本。這提醒我們，設計是確保將信息傳遞給用戶。
永遠不要犧牲美學的可用性。關于網站上的文本和其他重要元素，最重要的是可讀性?？勺x性要求文本和背景之間有足夠的對比度。為了確保有視覺障礙的人能夠閱讀文本，W3C Web內容可訪問性設計指南（WCAG）有一個[對比建議]（https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-to-contrast.html ）。對于正文和圖像文本，建議使用以下對比度：
小文本的文本對比度必須至少為4.5：1。最佳對比度是7：1。
字體較大（第14個粗體，第18個字體或更高）的文本應至少具有3：1的對比度。
不好：這些文字行不符合對比度建議，很難閱讀。
好：這些文字符合對比建議，并且清晰可辨。
您可以使用WebAIM的[顏色對比度檢測器]（http://webaim.org/resources/contrastchecker/）來確定它是否在最佳范圍內。
4.2色盲用戶
據估計，全球人口中有4.5％患有色盲（12名男性中有1名，200名女性中有1名），4％患有低視力（30名中有1名），0.6％是失明者（該組中有188名患者） 。很容易忘記為這個用戶群設計，因為大多數設計師都沒有這個問題。
為了使用戶能夠正確訪問它，請避免僅使用顏色來表達意義。如W3C所述，顏色不應被用作唯一的視覺傳播方式，表示動作，提示響應或區(qū)分視覺元素。 “
通常僅使用顏色來表達表單中的提示信息。成功和錯誤消息分別以綠色和紅色顯示。但紅盲和綠盲是盲人群中最常見的。在大多數情況下，您可以收到錯誤消息，例如“l(fā)dquo;此文字標記為紅色”它似乎不是問題，但色盲用戶無法收到此表單中的錯誤消息。應使用已經可見的信息突出顯示或補充顏色。
錯誤：此表單僅依賴紅色和綠色表示該字段沒有錯誤。色盲用戶無法識別。
在上表中，設計人員應提供更具體的說明，例如“您輸入的電子郵件地址無效”或顯示您需要注意的圖標。
好：圖標和標簽顯示哪些字段無效，更好地將信息傳遞給色盲用戶。
4.3盲人用戶
圖片和插圖是網頁的重要組成部分。但盲人需要輔助技術，如屏幕閱讀器來翻譯網站。屏幕閱讀器依賴圖像的替代文本來“閱讀”。圖片。如果文本不存在或描述不清楚，他們將無法獲得預期的信息。
考慮兩個例子–首先，Threadless，一個受歡迎的T恤商店。此頁面沒有太多關于所售產品的信息。唯一可用的文字信息是價格和尺寸的組合。
第二個例子來自ASOS。銷售T恤的同一頁面提供了該項目的準確替代品。這有助于使用屏幕閱讀器的人想象項目的外觀。
為圖像創(chuàng)建替代文本時，請遵循以下準則：
所有“有意義的”圖像需要描述性的替代文字。 （“Makeful””照片指的是提供上下文補充信息）
如果圖像純粹是裝飾性的，并且沒有提供有用的信息來幫助用戶理解頁面的內容，則無需替換文本。
4.4鍵盤自適應
有些用戶使用鍵盤而不是鼠標來瀏覽網站。例如，患有運動障礙的人難以使用諸如鼠標之類的精細動作。通過使交互式元素適應Tab鍵并顯示鍵盤指示符，這些用戶可以容易地訪問交互式和導航元素。
鍵盤導航的基本規(guī)則：
檢查鍵盤指示燈是否可見且明顯。一些網頁設計師會刪除鍵盤指示器，因為他們認為它不漂亮。但是這會阻止鍵盤用戶與網站正確交互。如果您不喜歡瀏覽器提供的默認指示器，請不要全部刪除;相反，設計它適合你。
所有交互式元素都應該可以通過鍵盤訪問，而不僅僅是主導航選項或主CTA。
您可以在“設計模式和小工具”部分的W3C“WAI-ARIA創(chuàng)作實踐”文件中找到鍵盤交互的詳細要求。
V.測試
5.1連續(xù)測試
測試是用戶體驗設計過程的重要部分。與設計周期的其余部分一樣，這是一個持續(xù)的過程。它從早期的信息收集開始，需要在整個過程中進行測試。
（圖片來源:極端不確定性）
5.2頁面負載測試
用戶討厭加載慢速網站。這就是為什么響應時間是網站的一個重要因素。根據尼爾森諾曼集團的說法，有三個響應時間限制：
0.1秒對用戶來說是瞬時的。
1秒可以平穩(wěn)地保存用戶的想法，但會感覺有點延遲。
10秒是用戶關注操作的限制。 10秒的延遲通常會讓用戶立即離開現場。
顯然，我們不應該讓用戶在網站上等待10秒。但是幾秒鐘的延遲常常讓人感到不愉快。用戶必須等待操作完成。
什么通常導致緩慢加載？
大量內容（如嵌入式視頻和幻燈片小部件），
后端代碼未優(yōu)化
硬件問題（基礎架構性能有限）。
[PageSpeed Insights]（https://developers.google.com/speed/pagespeed/insights/）等工具可以幫助您找出加載速度緩慢的原因。
5.3 A/B測試
當您在兩個版本之間進行選擇時，A/B測試是理想的，例如現有和重新設計的頁面。該測試方法涉及將兩個版本中的一個隨機顯示給相同數量的用戶，然后分析用戶更有效地完成目標的版本。
（圖片來源: VWO）
6.發(fā)展移交
[UX設計流程]（https://blogs.adobe.com/creativecloud/ux-process-what-it-is-what-it-looks-like-and-why-its-important/）有兩個重要步驟：設計原型和發(fā)展。一旦設計完成并準備進入開發(fā)階段，設計人員需要開發(fā)一個規(guī)范來描述設計應該如何實現的設計。規(guī)范確保開發(fā)不偏離初衷。
規(guī)范中的準確性至關重要，因為在規(guī)范不準確的情況下，開發(fā)人員必須在開發(fā)過程中依賴猜測或讓設計人員回答他們的問題。但手動編寫規(guī)范很麻煩，通常需要很長時間。
借助Adobe XD的設計規(guī)范功能（測試版），設計人員可以向開發(fā)人員發(fā)布公共鏈接。通過鏈接，開發(fā)人員可以檢查，測量和復制樣式。設計人員不再需要花時間編寫規(guī)范來向開發(fā)人員解釋位置，文本樣式或字體。
Adobe XD設計規(guī)范功能（測試版）
七，結論
這里分享的技能只是一個開始。將這些想法與您自己的想法相結合，以獲得最佳結果。將您的網站視為一個不斷發(fā)展的項目，并分析用戶反饋，以不斷改善體驗。請記住，設計不僅僅適用于設計師–但對于用戶。
原始鏈接：https://www.smashingmagazine.com/2017/11/comprehensive-guide-web-design/
在這篇文章中，每個人都是產品經理翻譯團隊@吉諾是比利翻譯發(fā)布，未經本網站許可，禁止轉載。
該地圖來自unsplash，基于CC0協(xié)議