起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識為什么看再多的設計原則，也做不好B端交互？
編輯導語：大家有沒有思考過一個問題，為什么B端產品的頁面交互設計師看了很多設計原則也還是做不好B端交互？本文就這就這件事提出了自己的看法，以及給出了一些解決方案，希望能給大家帶來一些幫助。推薦對B端交互感興趣的用戶閱讀。
長久以來，我們一直強調 B 端設計，最重要的輸出產物不在于樣式，而是交互。優秀的交互設計可以顯著的提升操作效率，更快完成工作任務，從而提升經濟效益。
但是要怎么講清楚它是很痛苦的一件事，理論上的交互原則，和真實工作場景遇到的困難很難匹配。大家會有這種感覺：看再多的分享和原則，也做不好交互。
所以，我們要來探討一些 B 端交互的基本要求和特點，下面用一些近期的案例做簡單的剖析。
一、業務優先的全局思維
在 B 端項目中，所有的工作目標，都是圍繞在更好的解決業務問題展開的。一個完整的業務需求，必然是包含大量的組件、流程的共同參與。
我們在設計內容的過程中，往往會掉進過度關注某個單元的細節，而忽略整體對整體業務目標、重點的認知，出現本末導致的問題。
所以，針對每個局部的組件，我們一定要思考它在流程中的重要性，使用頻率，使用場景。
比如前陣子分享的學員案例篩選組件，我們將左側露出的篩選項進行折疊合并，修改成了右圖的結果。
光盯著組件看，可以明確的說案例 1 必然是更好操作的，因為篩選內容可見，操作步驟較少。如果你只想到這里，那么必然是沒法處理好交互的。
我拿到這個案例的第一件事，實際上就是搞懂這個頁面是干嘛用的，處理什么業務，以及了解目前用戶的一些基本訴求。
最后得到的結果，就是操作員來到這個頁面，主要查看異常的狀態和它們的詳情。因為列表本身是根據時間排序的，異常狀態沒有處理的也通常都在前面。
所以，操作員直接查看列表是最高頻的操作，并且表頭因為支持排序切換，也是高頻操作的內容之一。反而頂部的篩選，只有遇到一些特殊情況，需要將歷史中的某些條目篩選出來，才會用得到。在正常使用過程中是會被自動忽略的。
而且目前用戶的主要反饋也出現，頂部的篩選過高，每次進頁面都要下拉才能看見列表，操作極為不便。
基于這樣的前提條件，我就一定會壓縮頂部篩選區域的高度，確保下方列表的大多數內容在一屏內可以顯示完。
那為什么還要改里面的篩選方法而不是簡單做個折疊和展示？
還有一個全局化的考慮，就在對一個篩選組件的設計，就是其它所有頁面篩選組件樣式的基礎。這個頁面我們只放了七行，其它頁面最多的篩選項最高多達一倍。即使做成折疊的，展開后甚至一屏都放不完篩選內容，比如下面這樣的示例。
并且，篩選完之后，這個面板折疊還是不折疊，折疊了的話看結果列表就看不到前面選了哪些。不折疊同樣也基本看不見，因為列表需要下拉，把上半部分內容隱藏。
所以，最終進行多列排序的設計，就是舍棄最“初步”的便利性，為業務目標讓步。同時基于全局的可用性做預判，對一個低頻操作的模塊減少過度信息的露出，讓用戶可以高效完成 1 級信息索引（找到選項標題），然后再去做 2 級篩選。
在長期以來的 B 端項目實踐中，我都始終踐行業務優先的原則，檢查處理的方案能不能滿足我上面分析的特征，只有滿足不了業務需要，我才會去修改它。
而不是虛空樹靶，光靠各自的 “覺得” 來討論，這樣的討論不僅沒有質量，而且不會獲得有效的結果。
二、同理心和角色目標帶入
做產品和交互，對用戶的理解優先建立在共情和同理心上。
了解用戶，最好的方法不是你做了科學的實驗，應用完善的理論，而是你自己成為用戶！可惜很多設計師都想不明白這個道理，過度追求數據或者調研方式。
在上一個案例中，也有同理心應用的部分，自己作為用戶知道這個頁面操作的重點，在權衡利弊的過程中你自然知道應該選擇什么，放棄什么。
下面再看另外一個學員案例，也是表單，但是是需要用戶完整填寫的大量表單內容。
在右側的改版里，我把單從橫排改成了豎排，從原本省空間的方案改成了不省空間的方案，和上一個案例截然不同。
為什么？看看下面的細節先。
如果真當自己是用戶，看一遍自己做的設計，給自己定個操作的目的，并嘗試在這些內容做選擇，那么你選擇到這種模塊，就必然開始混亂起來。
上下的內容離得太近了，比左右同行同級元素還近，這樣會極大損害信息識別的效率和操作順暢度。尤其當我核對前面單選項是否選對的情況，閱讀起來更是痛苦。
而我們把內容進行上下排序，將親密性表現得更合理，那么操作的舒適度就會顯著的上升。至于多出來的高度，作為用戶你沉浸在表單輸入過程中，為什么會關注多出來的那點高度？
好吧！如果一定要用理論方法來分析，那可以堆砌一堆的理論解釋：
- 親密/對齊性：上下排序的親密性可以完美符合左對齊視覺引導，以及不同模塊跨度的劃分
- 菲茲定律：左對齊的選框位置距離極短，除了滾動外鼠標就負責上下移動，而不用全屏幕流浪
- 心流理論：用戶視線不要輕易被打亂，就容易沉浸到完成當前目標，而不是關注怎么設計美觀
- ……
理論可以拿來在 PPT 里強化自己方案的說服力，但前提是別自己繞進去，純粹通過理論的堆積來認為自己設計的是合理的。
再看看下面這種表單頁的案例，多列設計來讓畫布被填滿的設計，思考下到底是為了設計而設計，還是為 “用戶” 設計？
三、字段信息整理的必要性
第三點，就是有效的整理需要的設計模塊的字段信息。從產品層面去理解該模塊的訴求，信息層級，狀態類型。
有很多復雜的組件，如果我們直接動手畫，是行不通的。主要問題源自需求層面的復雜性，不僅字段非常多，而且它們是有層級關系，集聯性質。
比如再看下圖的學員案例，一個在公司平臺上傳公共文件時，進行素材權限編輯和信息管理的組件。
在這個模塊中，包含的功能和可操控的元素非常多。從整個面板的標題開始，作為最頂層的信息，向下可以延伸出不同的子模塊和對應的二級標題。
每個二級標題下，還有不同的下級元素。我們不僅要有效處理這些關系，同時還要分析權限的字段內容，它們包含了：權限類型標題、對象、對象權限、選擇、刪除、添加。
這時候，我就會用文字的方法把這些信息整理出來：
然后，重新梳理不同層級結構，再完成不同狀態的兼顧，縮減無效的按鈕，盡可能降低信息的復雜程度。下面是改動后的案例（只做了原型）。
交互的很多工作并不在設計軟件上，而是要跳出軟件和設計稿，去理解實際的產品需求、信息、字段。除了一些樹狀圖外，必要的交互流程圖是無法省略的。
多種工具導圖和原型的共同作用，才能幫助我們在復雜的需求環境下 “試” 出足夠多的方案找到最滿意的那一個。
四、檢驗是說服力的最優途徑
最后，就是自己也拿不定主意，或者你的方案就是說服不了產品、開發的常見情況，怎么辦？
那就是真實的做測試和投票！
B 端比 C 端最大的優勢之一，就是如果真要做用戶調研和測試，容易了無數倍。不管是給客戶做方案還是做公司內部項目，你的目標用戶群體是非常固定而且容易聯系的。
當我們在交互方案上僵持不下的時候，就不用糾結或者通過開會的撕逼來做決策。而是把這交互方案的高保真原型做出來，給對應的目標用戶做測試。
比如上面表單的案例中，新老兩個案例，你都可以快速用 Axrure 或者 Protopie 等軟件實現高保真的交互原型，1:1 還原真實操作場景。
你可以從下面制作的初步案例中查看操作結果：
請在電腦端打開，才能還原真實操作：
原案例：https://cloud.protopie.io/p/f20dc7a0eb
改后案例：https://cloud.protopie.io/p/42c51829cd
這時候，方案哪個有效不就根本不用爭論，交給目標用戶去使用和投票不就明了了嘛？B 端交互方案的決策權，可以由目標用戶來主導，而我們要做的就是去建立這樣的決策機制，如何快速的來生成不同交互方案，并讓目標用戶決斷。
不要再在無窮無盡的 “你覺得”、“我覺得” 中損耗項目進度了……
五、結語
以上，就是一些 B 端交互設計中的思路實際解決流程。這些也是我最真實的工作狀態下解決問題的方案，所以并不想寫一大堆理論來欺騙自己了（狗頭保命）。
希望大家能從中獲得收獲！
本文由 @酸梅干超人 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
自己測了一下，修改前的這個橫排填起來要耗時更多，要左右轉動頭，修改后的只需要從上往下動眼睛就行了，省事很多
寫得真好、速速更新
這兩個方案最大區別是啥呀
寫的真好！！
寫的很好！下次還要再寫，介紹的很詳細，詳細的思路實際解決流程