本文歸納總結了5個B端設計的思考，你可以看到高手如何分析工作中遇到的問題。

從垃圾桶到“多入口”，談談 B 端設計思考

最近在一次大掃除當中，不小心把廚房里的垃圾桶給摔壞了，于是乎想在網上選購一個合適的垃圾桶，而回顧了垃圾桶的選購經歷，或許它是一個很好的例子，讓大家了解多入口的設計思考。

首先，究竟廚房需要是什么樣的垃圾桶?我陷入了嘀咕，因為我自己也不太明白，于是我在淘寶上看到了許多不同類型的垃圾桶。

把它們總結了一下，基本上可以分為兩類：直筒式、腳踏式

直筒式：采取頂部開放的結構，使用者可以直接將垃圾扔到桶里。如果不夠有趣?你還可以將垃圾桶看作“籃筐”進行投籃。

直筒式頂部開放的結構，確實能夠給我們扔垃圾帶來不少便利，但同時也會暴露一些問題，就是蚊蟲。因為廚房里的垃圾桶會有很多餐廚垃圾，也因此會滋生很多蚊蟲，特別是在一些剩下的水果核上，會留下很多蚊蟲。

腳踏式：頂部為蓋板，當需要扔垃圾時，使用者需要用腳踏住蓋板，并將其抬起。這種方式就能夠避免廚房餐廚垃圾所滋生出來的蚊蟲

但問題又來了，在做菜時，扔垃圾通常十分頻繁，每一次都需要腳踏顯然效率太低。那能否既能腳踏又能隨手就扔呢?

面對這一問題，我發現了一個新式垃圾桶：

它在為用戶設計時，考慮到了兩種不同的模式，因而將兩種入口進行巧妙的融合。通過頂部面板的開關，可以將垃圾桶設定為開啟或者關閉，能夠讓垃圾桶在你想要的時候保持開啟的狀態，這樣就能滿足在一小段時間內的頻繁扔垃圾的需求。同時又能提供腳踏的形式，將垃圾桶蓋完整抬起，這樣的垃圾桶既可以腳踏也可以直接扔。

而在我們設計 B 端產品時，同樣會有 “多入口”的情況。

比如在紛享銷客的設計當中，新建客戶有著兩個不同的入口：

入口一：首頁 – 客戶及商機管理 – 客戶 – 新建

這是新建客戶最為常規的入口，它就類似垃圾桶的直筒式。通過表格頁操作的新建，讓用戶進行表單的填寫，進而新增客戶。

入口二：首頁 – 新建 – 客戶

這是紛享銷客的一個特別設計，它在導航菜單處設置一個全局的新建入口，當用戶在系統的任意頁面，都可以進行新建。

大家可以跟我一起思考一下，我們如果是一個銷售人員，在我的工作當中，會去經常新建客戶、跟進記錄等，那通過一個全局的新建入口，能幫助我們更快的進行操作。這便是紛享銷客的第二個新建入口。

我再給大家舉一個簡單例子，同樣我們在紛享銷客當中，表格當中的篩選同樣也是有著兩個不同的入口：常規篩選與表頭篩選。

• 常規篩選：用于表格當中一般和許多操作并排放置，算是一個較為基礎的入口
• 表頭篩選：點擊過后同樣也是進入到篩選彈窗，但不同的是，表頭篩選點擊過后，會將表格的值帶入到篩選當中，來實現篩選+選值這樣的兩步操作。

而為什么會有兩種不同的入口，我們回過頭來想想，就像我文章開頭說到的垃圾桶一樣，兩種不同的入口，其實是為了方便我在某一個場景下進行使用(比如垃圾桶的持續丟垃圾與開關垃圾桶蓋;紛享銷客新建操作當中的常規新建與快捷新建)而它正是因為用戶在不同的場景需求下，所設計的形式不同。

在 B 端產品當中，不同場景的需求其實經常存在，但為什么沒有暴露出來?其實是因為用戶在 B 端產品當中，本身用戶就是處于弱勢群體，他們都是服從于上級的安排，而設計師不會分析，就會選擇最平庸的方式去處理需求。

B 端產品移動端設計的小趨勢

咱們講了很多桌面端的交互設計，最近在使用 App 時發現了一個自己觀察到的小趨勢，隨便寫寫與大家探討探討～

不知道大家在處理移動端導航中，有沒有遇到這樣的情況。公司的移動端設計是 “優雅降級” 即先滿足桌面端得到產品的設計后，再逐步去考慮如何適配移動端。導致移動端頁面中出現了意想不到的問題。最為常見的就是底部導航欄的導航菜單不夠用。

為什么不夠用，我拿釘釘桌面端進行舉例：

在釘釘的桌面端中，包含有我的團隊、消息、文檔、工作臺、通訊錄五大重要模塊，其次在左下方還會有日歷、待辦、DING、郵箱、會議、直播、收藏、更多等應用功能。在桌面端將這些功能規劃完成后，你會如何設計移動端導航呢?給大家是5秒鐘時間進行思考～

我們先想想移動端導航有哪些 “公式” 可以套，底部導航、頂部導航、桌面式導航、舵式導航，這便是移動端導航設計中最為常見的幾個公式模型。而它的導航承載的最大數量不會超過五個，因此使用起來顯然不太滿足。

而在釘釘面臨的問題在我實際工作中遇到的問題類似，底部的導航可能會出現 10+ 的情況，究竟應該怎么辦～

明白問題后我帶著各位進行分析分析：

• 首先我們在設計中，遇到數量多的內容時，首先想到的應該就是信息分層，無論是將10多個導航進行拆分，顯然釘釘也是這么做的。
• 接下來你會發現釘釘在最近更新的版本中，出現一個不同尋常的交互。

通過上劃底部導航菜單，類似一個底部抽屜，將剩余的模塊放置在抽屜下。這樣就能將完整的導航形式在移動端的方式展示給用戶。

說說這樣設計的優點：

• 確實能夠保證在桌面端產品結構不變的情況下，對移動端的合理適配。因為按照傳統的交互框架下難以滿足現在的問題
• 移動端與桌面端的導航體驗基本保持一致，滿足用戶對整個產品架構的認知

再聊聊缺點：

• 入口太深：因為交互入口需要進行上劃的操作才行，需要教育一段時間的用戶，讓大家熟悉這個方式
• 冗余：目前釘釘太多的內容導致整個產品給人的感覺十分臃腫，再新增這個交互后需要的學習理解的內容就過于繁多，說實話我作為一個釘釘的用戶，我要去寫一個工作中的項目文檔，我是應該選擇：去協作?去工作臺?去項目?去最近使用?同時又擁有文檔、石墨文檔、Teambition 如何選擇?

雖然知道釘釘擁有強大的 ISV 生態，但目前很多 ISV 的功能與釘釘自身產品功能重疊，交集過多。

當然這類交互并不是釘釘自己創新設計的，我是在 Teambition 以及飛書這兩款產品上首先發現(這兩款與釘釘的做法還不太一樣)，隨著釘釘的跟進，相信這類交互很快會成為 一個移動端的全新解決方式。

最后再說說飛書與 Teambition 在這個交互中的細節

首先在飛書中，底部導航的配置主要來源于兩個方面：

飛書管理后臺：提供入給管理員，讓公司的管理者可以對默認的導航進行一個統一配置

用戶：用戶可以根據自身的需求特定，對底部導航進行自己個性化的配置

其次，飛書不會存在釘釘入口太深的問題，用戶點擊更多，就展開抽屜，用戶更容易理解。

Teambition 也是類似，就不做拓展，這便是移動端設計的小趨勢，大家可以在實際工作中用起來～

從文檔類產品中尋找表單效率提升

表單作為一個 B 端設計的重要場景，一直以來我都在想，究竟應該如何高效的進行信息錄入?今天我們就從文檔產品中，去“借鑒”一些表單效率提升的方法～

首先在錄入的場景中，我會想到寫作類的文檔軟件：

我自己是一個文檔軟件的重度使用者，我曾使用過 Bear、印象筆記、Notion、Ulysses、飛書文檔、石墨文檔、語雀等等…，而恰好你也是一個文章作者，也應該嘗試過一種快捷信息錄入的方式：Markdown

1. Markdown

Markdown 是一種輕量的標記語言，常用于文章排版中，這種標記語言會讓你沉浸在寫作中而不是反復去糾結排版，進而打斷你的思路。

比如我想設置一個 “一級標題”

沒有使用 Markdown，操作路徑是

• 先輸入文本內容
• 使用鼠標，選中想要文本內容
• 點擊一級標題按鈕，從而完成整個錄入形式

使用 Markdown 后，我只需要

輸入：#+空格+文本內容即可快速完成上面三步的操作

我使用 Markdown 就可以提升我在信息錄入時的效率，手也可以不用去移動鼠標，減少切換控制設備所帶來的一系列的問題。在我看來這便是一個文本錄入效率提升的一個方式，而我們怎么將 Markdown 的思路落地到我們的 B 端表單場景中呢?

我本來也是沒有任何思路的，可是最近在使用滴答清單發現它的錄入特別有意思，當我在新建一個待辦事項時：

輸入“!”符號后，即可設定該待辦事情的優先級，同樣在輸入“～”符號后，即可設置該待辦事項的歸屬。

是不是和 Markdown 的特定規則有那么一點點類似了～

通過這樣設定特殊規則，我可以對待辦清單進行快速選擇優先級、歸屬箱等等…

不光是滴答清單，在 Notion、微信、語雀都有著類似的交互，我將此類交互稱為“特定規則錄入”

“特定規則錄入”：即使用特定的錄入規則，將用戶需要使用的信息進行快速的錄入

• 優點：能夠使用戶在不使用鼠標的情況下進行快速的信息錄入。
• 缺點：在日常真正需要使用該符號的情況下，下拉菜單會造成使用上的干擾。

比如我們在微信中，如果聊天需要用到 @ ，不會采取符號的形式，而更多將 @ 變為 “艾特”

最后的落地，在我們實際的 B 端項目中，我們在銷售填寫跟進記錄時也做了相應的優化：

• 我們可以用 @+空格 添加具體的銷售負責人員
• 輸入 #+空格 添加跟進記錄的標簽
• 輸入 !+空格 添加跟進記錄關聯的合同
• (由于保密協議，這里就不展開去講，算是給大家提供一些思路)

不過通過這樣的改版，確實讓用戶在使用跟進記錄這一模塊上有了極大的提升。當然目前還是會有一些小問題，就是在輸入 “!+空格” 時，很多銷售還是會反饋這個的影響有些大，希望能夠進行調整。

之后會考慮將這個快捷方式遷移到其他字母，希望能夠解決此問題。

擴大錄入面積

在我日常的寫作中，我會新建一個思維導圖。

一方面思維導圖能夠幫助我去梳理我的思維結構，整理一些腦袋中零散的知識點，另一方面我也可以通過導圖，幫助我進行快速的知識調度。

但在飛書文檔中，因為寬度限制，導致我在對導圖的編輯特別不友好，沒辦法正常的編輯我的思維導圖。這時候我可以雙擊導圖，進入到全屏編輯的狀態，這就對大容量內容的編輯，帶來的非常多的便利。

當然這只是在文檔場景下，其實我們在日常的表單錄入的過程中，同樣會面臨同樣的問題。

通常，表單的呈現都是采取彈窗的形式，但是當信息錄入過多時，就需要考慮是否支持將彈窗擴展至整個頁面，能夠將表單進行更快速的錄入。

比如在 Gmail 中，當你需要去新建一封郵件時，就有兩種不同的狀態：

• 一種是常駐在右下方，通過一個小窗口進行展示
• 一種是點擊全屏按鈕，能夠將整個頁面進行展開，作為全屏讓人進行錄入

 

這種交互形式也被放在我們自身的產品中，因為作為一個 aPaaS 類的可配置化的表單，我們本身是不能確定用戶的內容量，因此在采取彈窗的同時會為用戶增加大彈窗的入口，可以應對用戶靈活多變的各種場景。

當然這只是表單的一些場景，大家可以在評論區進行討論。

下拉菜單“懸浮”問題的解答

大家還記得我在選擇錄入上的文章留下的一個話題嗎?

為什么線上許多產品中 (明道云、簡道云、ONES…) 窗口下呼出下拉菜單后，滾動表單都沒有跟隨錄入框嗎?如下圖，今天我們就來聊聊其中的緣由。

我們先來看一看大家在評論區，都是如何討論的～

看到大家的回答，有的已經十分接近，但是實際的情況還是會有一些不同，我來帶領大家一起討論～

首先，在設計層面上，咱們最想要的結果是在彈窗中：下拉菜單與錄入框進行實時的跟隨，也就是類似下圖：

但是在開發層面，你會收到成本太高的結論。因為影響上訴結果的原因就是在 CSS 當中有一個屬性叫 Position(定位)，下拉菜單也正是通過定位來進行位置的判斷，從而實現下拉菜單與錄入框跟隨的狀態。

這里就不扯那些代碼什么的，我相信大多數設計師都看不懂，我就簡單將問題用設計師的角度去理解，你可以將彈窗本身看作是一個畫板，而錄入框、下拉菜單都看作是其中的一個圖層。

如果需要實時定位來進行計算(也就是上面 AntDesign 所呈現的效果)就需要將它們都放在一個畫板里面。

這時候大家應該忘了一個重要的條件因素：彈窗

當我們使用彈窗，必然會將整個畫板縮小，因而在里面的圖層也會受到畫板的局限，不能完全展示，在實際的開發中，就會出現下拉菜單遮擋展示不全。

當然遇到這種問題我們就需要找到解決辦法，也就是最開始與大家講到的其他產品的做法：

• 將整個的下拉菜單單獨看作是一個畫板，雖然不會對選擇錄入框進行實時跟隨，但是從整體來看，這種方式顯然影響用戶的使用體驗更小，在權衡比較過后，就會采取第二種方案。
• 其實作為設計師，我們要做的不光是頁面當中流程的體驗，同樣還需要去關注自己頁面落地當中所遇到的許許多多的問題，Problem Solver 才是設計師的常態。

相信你在設計的過程中，也會遇到許許多多與開發同學產生的矛盾～不如發出來，看看大家能不能幫你一起解決!

我是 CE 青年，一個 2 B 行業的 2B 設計師～