前言

“前臺重體驗，后臺重邏輯”，B端談 UX 有沒有價值？

一切電子化的今天，運營、審核、電銷、賬務……無數崗位依賴中后臺系統來完成他們的日常工作，好的 UX 確實可以直接為這些產能提效

當中后臺的工程師們花費了巨大精力沉淀出的一些技術產品，最終落地到業務上的時候，得到的是終端用戶“XX系統簡直就是狗屎”的抱怨，這就是一種極大的資源浪費

前端工程師的產出是直接對接終端用戶的，前端工程師應該是人機交互的專家

UX是User experience的縮寫，即用戶體驗，其核心是用戶，體驗指用戶在使用產品以及與產品發生交互時出現的主觀感受和需求滿足。其中最重要的概念就是以用戶為中心去思考人機交互

一些設計思路

實用先于視覺

通常情況下好看與實用并不會產生沖突，但有一些情況下也需要取舍

上圖在視覺上看起來沒有任何問題，符合對齊原則。但如果這個篩選器的寬度是自適應的，實際應用中就會存在一些問題。

當用戶使用較大分辨率的顯示器時，篩選器的寬度會被撐開，此時候項目名稱和日期的左右對齊布局就會出現距離過遠的問題。當用戶需要在若干候選項中篩選數據時，視覺焦點需要頻繁的左右橫移，造成視覺疲勞。

倘若是使用看起來“不那么和諧”的跟隨布局，就不會有這樣的尷尬

以業務邏輯為準

交互邏輯的設計需要契合業務邏輯，在某些不能確定的交互場景下，不妨從業務角度去思考

一個典型的場景是表單默認值，比如一些必填項或單選項，是否需要給默認值？給哪個默認值？需要考慮終端用戶的實際使用場景：

• 如果某個默認值是絕大多數場景下的最佳選擇，默認選擇該選項可以減少用戶的重復操作，提升表單效率
• 如果是是長串文本如備注，而用戶的大多數文本類似只有少數關鍵字不同，就可以考慮填充用戶上一次的備注內容，甚至保存用戶的常用文本作為模板
• 而如果是不可逆的操作，則寧可不設默認值，每次都讓用戶手動選擇確認以避免出錯。

源自網絡，侵刪

可視化優先

相比數字和文本，人的大腦更容易接受圖像，除了常見的圖表之外，對于一些有邏輯相關性的數據我們也可以使用可視化的方式來表達

比如中后臺系統的頁面上往往充斥大量的table頁面，在某些字段有業務邏輯關聯的情況下，就可以使用可視化的方式來表達，既節省了字段空間，又增加了數據的易讀性

費茨定律

費茨定律指的是：使用指點設備到達一個目標的時間同以下兩個因素有關：

設備當前位置和目標位置的距離越長，所用時間越長

目標的大小，目標越大，所用時間越短

將列表的操作區域收束在盡可能靠近的地方，且給每個獨立的操作區域劃分合理的間隔，有效減少鼠標的來回移動，提升閱讀信息與操作的效率，對比以下圖片：

順流而行

用戶在執行一些需要集中注意力的任務時會進入心流狀態，在此狀態時不愿被打擾，我們給用戶提供交互時應該思考一個問題，什么情況下應該順應用戶的心流，什么情況下有必要打斷？

比如一些不那么重要或不那么復雜的擴展操作，應盡量避免使用遮罩彈窗，遮罩彈窗不但會打斷用戶的心流，而且增加用戶的移動成本

一些行內編輯的場景，也應盡可能避免進入編輯狀態時出現行、列寬高的抖動，打擾用戶心流

一些彈出式的輸入，可以直接幫助用戶提前獲取好控件的焦點，并提供快捷鍵方式的確認，減少用戶的低效操作

而一些重要的、影響較大的、不可逆的操作，則需要有意打斷用戶當前心流，將用戶的注意力轉移到重要的確認事項上

明確、及時反饋

反饋的重要性不用多說，現在的UI庫基本也自帶各種反饋機制，在什么時候使用哪種程度的反饋是我們需要學習的

一種典型的反饋場景是長時等待，通常是某些后端接口需要響應較長的時間，需要用戶等待一段時間，根據需要等待的時長，反饋的設計也不一樣

4s內的反饋，一般是一個簡單的loading就可以了；而超過4s的反饋，就需要有更加明確的反饋機制了，目的是讓用戶確信不是程序出了問題，也要讓用戶知道自己還需要等待多久

一般可以使用進度條，也可以是文本

如果是較長時間的等待，可以考慮讓用戶可以去做其他事，無需在界面上等待，在后臺完成處理后再給用戶一個延遲的反饋

好的反饋機制可以減少用戶的迷惑，在下圖的流程編輯器里，當連線被拉出后，會將可連入的節點高亮，并給出連入點，即使第一次使用的用戶也能知道下一步該做什么

除了長時等待之外，一些獨立的小編輯項可以使用弱反饋，不打擾

常見的痛點場景

條件緩存

在帶有條件查詢的頁面上將查詢條件通過url的get參數保存下來，以便將當前的查詢條件保存在瀏覽器書簽或進行分享，在頁面意外關閉或刷新后也可以第一時間回復，在服務端渲染的時代這是常規操作，但在普遍使用SPA的當下經常被忽略。

寬表

如果是表格的字段太多，可以參考《交互設計四策略》中的“組織”、“隱藏”和“轉移”策略，可以是固定部分字段，剩余字段收起，通過滾動展示

缺點是windows客戶端下使用鼠標的用戶體驗很差，需要鼠標拖動橫向滾動條的操作很反人類，尤其是小屏下查看超過一屏的數據簡直令人崩潰，可以提供快捷鍵來改善，但需要讓用戶知道有快捷鍵，會提升用戶培訓成本。

另一種方式是讓用戶自定義列頭

或是將部分字段收納起來作為二級信息展示

也可以通過合理的組織整理，提升cell的利用空間

通常越是龐大的數據表格，留白越少，也越需要border來加以區分，參考Excel；以上幾種方案各有利弊，也可以結合使用，需要權衡業務場景來定奪

查詢字段

查詢表單是中后臺系統最常見的頁面，前面說的字段太多引申出另一個問題是搜索選項與字段數量成正比，導致隨著功能的增加搜索選項也不斷增加，喪失易用性

通常的做法是收起一些不常用的搜索項，需要時再展開

另一種更為討巧的方法是將搜索條件直接放置于對應的表頭上，可以節省很大一部分字段

不管使用哪種查詢設計方式，都建議將當前的搜索條件直接平鋪給用戶，并提供清除功能

詳情頁

不同的業務對詳情頁的需求天差地別，無法一概而論，單從展示層面來說，詳情頁本質上需要解決的也是有限空間下的復雜信息展示

首先是需要對功能區域進行合理劃分

其次是對多個大塊信息的處理，通常會選擇使用tabs來處理，但個人建議使用平鋪+錨點的方式來代替tabs，主要是以下幾點

• tab數量過多時tabs本身就需要翻頁，增加無用操作
• 查看相鄰數據時滾輪查看比移動+點擊效率更高
• 當用戶需要搜索某個關鍵字時，平鋪的內容可以通過瀏覽器的搜索直接定位到，而tabs無法做到

從交互層面來說，一般詳情頁都有返回上級頁面的需要，而由于詳情頁本身的復雜性（可能內部還存在路由跳轉、錨點跳轉等情況）無法依賴瀏覽器的回退來返回

可以將詳情頁以抽屜組件的形式直接在列表頁上滑出

也可以將上級頁面數據、返回入口以快捷方式的形式帶入詳情頁，方便直接在詳情頁內做切換

長表單

過長的表單，可以讓用戶分步填寫，如果要在一屏內展示，則最好控制住容器的max-height，這是為了讓確認按鈕組在頁面上隨時可見，且不會距離表單項太遠。

讓用戶通過滾輪查看和填寫表單，將視覺熱區縮小在一片固定的區域內可以減少用戶的閱讀疲勞感。

有限空間下的復雜信息展示

如上圖所示，在保證布局合理性的前提下，盡可能減少不必要的空間占用，這點是細節，在業務迭代任務較重的情況下最容易被忽略。

狹窄的場景需要放一些較大文本內容表單的，需要給用于顯而易見的提示

確認按鈕到底放在左邊還是右邊？

一個有趣的實驗是無論確認按鈕放在哪邊，用戶的出錯率都相差無幾，但如果一個系統中確認按鈕的位置前后不統一，就會大大提升用戶的操作失誤率。所以我們要確保的是系統內的設計規范的統一，這一點在多人協作項目時最容易被忽略。

總結

UX 設計有很多法則，但在實際應用中我們不應該盲目遵循，很多時候我們需要從技術、業務、終端多個角度去做權衡，將自己代入到實際的用戶中去審視。當然在知道系統的構造之后很難再去模擬一個小白用戶，所以如果有機會還是應該盡量觀察終端用戶的實際使用場景。

除此之外也要對UX設計的結果進行追蹤和驗證，可以借助埋點，也可以對終端用戶進行抽樣調查。

碎碎念

一個應用和一堆功能頁面的區別在于，功能頁只關心你的數據查出來沒有，而應用會關心你查數據快不快，看數據爽不爽，數據查出來之后要干嘛

使用中后臺完成日常工作的用戶，工作中通常會伴隨著大量重復性的操作，并且通常沒得選。由此即使是一丁點體驗上的不便，在無數次的重復下也可能會使用戶崩潰，得出這系統不行的結論。前端工程師向業務方負責的同時（能用），也有義務向系統的終端用戶負責（好用）。

總結

以上是生活随笔為你收集整理的elementui中tabs切换item中的内容会变_中后台UX优化之道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。