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

從垃圾桶到“多入口”，談?wù)?B 端設(shè)計思考

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

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

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

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

直筒式頂部開放的結(jié)構(gòu)，確實能夠給我們?nèi)永鴰聿簧俦憷瑫r也會暴露一些問題，就是蚊蟲。因為廚房里的垃圾桶會有很多餐廚垃圾，也因此會滋生很多蚊蟲，特別是在一些剩下的水果核上，會留下很多蚊蟲。

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

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

面對這一問題，我發(fā)現(xiàn)了一個新式垃圾桶：

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

而在我們設(shè)計 B 端產(chǎn)品時，同樣會有 “多入口”的情況。

比如在紛享銷客的設(shè)計當(dāng)中，新建客戶有著兩個不同的入口：

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

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

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

這是紛享銷客的一個特別設(shè)計，它在導(dǎo)航菜單處設(shè)置一個全局的新建入口，當(dāng)用戶在系統(tǒng)的任意頁面，都可以進行新建。

大家可以跟我一起思考一下，我們?nèi)绻且粋€銷售人員，在我的工作當(dāng)中，會去經(jīng)常新建客戶、跟進記錄等，那通過一個全局的新建入口，能幫助我們更快的進行操作。這便是紛享銷客的第二個新建入口。

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

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

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

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

B 端產(chǎn)品移動端設(shè)計的小趨勢

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

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

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

在釘釘?shù)淖烂娑酥校形业膱F隊、消息、文檔、工作臺、通訊錄五大重要模塊，其次在左下方還會有日歷、待辦、DING、郵箱、會議、直播、收藏、更多等應(yīng)用功能。在桌面端將這些功能規(guī)劃完成后，你會如何設(shè)計移動端導(dǎo)航呢?給大家是5秒鐘時間進行思考～

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

而在釘釘面臨的問題在我實際工作中遇到的問題類似，底部的導(dǎo)航可能會出現(xiàn) 10+ 的情況，究竟應(yīng)該怎么辦～

明白問題后我?guī)е魑贿M行分析分析：

• 首先我們在設(shè)計中，遇到數(shù)量多的內(nèi)容時，首先想到的應(yīng)該就是信息分層，無論是將10多個導(dǎo)航進行拆分，顯然釘釘也是這么做的。
• 接下來你會發(fā)現(xiàn)釘釘在最近更新的版本中，出現(xiàn)一個不同尋常的交互。

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

說說這樣設(shè)計的優(yōu)點：

• 確實能夠保證在桌面端產(chǎn)品結(jié)構(gòu)不變的情況下，對移動端的合理適配。因為按照傳統(tǒng)的交互框架下難以滿足現(xiàn)在的問題
• 移動端與桌面端的導(dǎo)航體驗基本保持一致，滿足用戶對整個產(chǎn)品架構(gòu)的認(rèn)知

再聊聊缺點：

• 入口太深：因為交互入口需要進行上劃的操作才行，需要教育一段時間的用戶，讓大家熟悉這個方式
• 冗余：目前釘釘太多的內(nèi)容導(dǎo)致整個產(chǎn)品給人的感覺十分臃腫，再新增這個交互后需要的學(xué)習(xí)理解的內(nèi)容就過于繁多，說實話我作為一個釘釘?shù)挠脩簦乙懸粋€工作中的項目文檔，我是應(yīng)該選擇：去協(xié)作?去工作臺?去項目?去最近使用?同時又擁有文檔、石墨文檔、Teambition 如何選擇?

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

當(dāng)然這類交互并不是釘釘自己創(chuàng)新設(shè)計的，我是在 Teambition 以及飛書這兩款產(chǎn)品上首先發(fā)現(xiàn)(這兩款與釘釘?shù)淖龇ㄟ€不太一樣)，隨著釘釘?shù)母M，相信這類交互很快會成為 一個移動端的全新解決方式。

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

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

飛書管理后臺：提供入給管理員，讓公司的管理者可以對默認(rèn)的導(dǎo)航進行一個統(tǒng)一配置

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

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

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

從文檔類產(chǎn)品中尋找表單效率提升

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

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

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

1. Markdown

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

比如我想設(shè)置一個 “一級標(biāo)題”

沒有使用 Markdown，操作路徑是

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

使用 Markdown 后，我只需要

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

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

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

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

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

通過這樣設(shè)定特殊規(guī)則，我可以對待辦清單進行快速選擇優(yōu)先級、歸屬箱等等…

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

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

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

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

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

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

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

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

擴大錄入面積

在我日常的寫作中，我會新建一個思維導(dǎo)圖。

一方面思維導(dǎo)圖能夠幫助我去梳理我的思維結(jié)構(gòu)，整理一些腦袋中零散的知識點，另一方面我也可以通過導(dǎo)圖，幫助我進行快速的知識調(diào)度。

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

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

通常，表單的呈現(xiàn)都是采取彈窗的形式，但是當(dāng)信息錄入過多時，就需要考慮是否支持將彈窗擴展至整個頁面，能夠?qū)⒈韱芜M行更快速的錄入。

比如在 Gmail 中，當(dāng)你需要去新建一封郵件時，就有兩種不同的狀態(tài)：

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

 

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

當(dāng)然這只是表單的一些場景，大家可以在評論區(qū)進行討論。

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

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

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

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

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

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

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

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

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

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

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

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

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

相信你在設(shè)計的過程中，也會遇到許許多多與開發(fā)同學(xué)產(chǎn)生的矛盾～不如發(fā)出來，看看大家能不能幫你一起解決!

我是 CE 青年，一個 2 B 行業(yè)的 2B 設(shè)計師～