2019-12-10 濤濤
B 端工作看起來總是沒有 C 端工作那么有趣，面臨的限制比較多，面對客戶（金主爸爸），很多時候總是左右為難。在實際工作中，面對這些情況該怎么辦？筆者根據自己的 B 端工作經驗，總結了一些交互設計的要點。
從事 B 端 SaaS 行業已經兩年有余，從最開始面對需求的茫然無措，到現在已經有了自己的一些基本方法論，這期間經歷了從有人帶到自己摸索的一個階段。
每天看看文章、看看書，大家講的都是 C 端的產品，C 端的交互和體驗；每天看同行們分析的不是如何提高用戶活躍量，就是 APP 的設計風格。這在我一個 B 端交互看來，無比羨慕啊。
C 端項目的設計師感覺每天和一線用戶打交道，忙得不亦樂乎，可以與用戶直接對接，可以添加有趣生動的文案。
而對于一個做 SaaS 的 B 端來說，Boss 常說的話就是：
你這個顏色太鮮艷了。
我們是 B 端，你這種頁面布局不合適吧。
這個文案太幼稚了，不適合我們產品的調性。
中規中矩就好，不要太跳。
整理了一堆的字段，畫了無數的線框和流程圖，卻拿不出 C 端設計師才有的豐富多彩的作品集，
盡管如此，設計的原則是通用的，無論是尼爾森十大可用性原則，還是格式塔原理，在設計方案的落實上，都有著相同的方法論。
無意在此討論 B 端和 C 端之間的差異，僅以此文章來總結下我自己的一些工作經驗，如有錯誤，敬請指出。
從業務需求的對接，到界面交互的細節，從功能的設計要點，再到產品的發展導向，我總結出了以下幾個方面，逐步展開：
C 端設計師最開心的可能就是收到用戶的反饋需求了吧，這樣表示自己的產品還有人在用，然后建個群讓用戶開開心心吐槽，完了就從里面提煉適合產品的一些需求和建議。
而對于 B 端設計師來說，如何處理需求是其成長的第一關，尤其是 SaaS 行業，不會處理需求，產品的功能更新將會遇到極大的問題。
B 端的用戶不像 C 端，雖然可以用用戶畫像來進行歸類和分析。但是由于 B 端的直接用戶是付費用戶，付了錢的就是大爺，因此大爺提的需求你敢不應？
用戶提的需求亂七八糟，有些是體驗問題，有些是功能問題，有些就是屬于比較極端的需求。那種傳說中甲方要你做一個可以根據手機屏顯示顏色而改變手機殼顏色的需求，在 B 端行業也是存在的。
那么問題來了，我們該如何處理紛繁雜亂的需求呢，我從收集需求-評估需求-需求落地挨個講起：
如果你也打算像 C 端產品體驗群那樣建立一個群，完了將自己的用戶聚集在那里，靜靜等待需求的話，我勸你三思而后行。你可以這么做，但是應該明確群的目標，可以收集需求，可以是 bug 反饋群，也可以是更新通知群；但是不要將其變成一個純粹的用戶反饋群，因為這會導致用戶的吐槽聲音過大，而讓潛在的用戶流失。
B 端的客戶一旦使用你們的系統，就要付出相應的金錢和時間代價，不是說想換一家就能換。因此他對于已經使用中的用戶反饋是極其看重的，B 端的產品很大程度是靠著同行間的口碑傳播從而取得了良好的效益。如果一個新用戶想進群了解，結果一進去就發現大家都在吐槽這個系統的不足之處，那么可想而知他的選擇是什么。
因此，最好的需求收集方式是通過運營、市場以及客服的同事們的反饋，因為他們是離客戶最近的人，他們每天都跟客戶打交道，了解這個行業從業者的一些基本情況。很多時候，客戶回訪和運營對接的時候用戶會提出一些功能的建議。
通常的一種情況是，在 SaaS 行業，你的一個客戶的流失意味著你的競爭對手多一個客戶。因此一般市場都會有競爭對手的信息，他們會知曉客戶從我們平臺流失到其他平臺的一些原因。最重要的是，他們也為你提供了絕佳的競品資料，進而可以進一步明確需求。
收集好的需求，該怎么處理呢？
工具之前我用的是 trello，很好用，你可以將需求按照類型分為不同的看板，規劃產品的進度。
之后由于團隊的原因，改用 teambition，功能要豐富點，可以寫測試案例等，對于國內用戶比較友好；可以按照 KANO 模型將需求劃分為不同的類型，用以安排產品。
KANO模型
基本（必備）型需求——Must-beQuality/ Basic Quality
一個產品應該具有的基本功能，能滿足用戶的基本需求，比如，微信的基本功能是即時通訊。
用戶不會因為該功能的出現而覺得滿意，因為這是基本的、必備的一項功能。如果連這個都沒法滿足，用戶滿意度會大幅下降。
期望（意愿）型需求——One-dimensional Quality/ Performance Quality
用戶迫切希望產品能提供的功能，當提供該需求時，用戶滿意度會大幅上升，當不提供該需求時，用戶滿意度會下降。
比如百度網盤一直為人詬病的下載限速，無法對單次下載而付費。而需要開通會員，用戶的抱怨恰好說明了其痛點；當提供單次下載付費的服務時，用戶滿意度明顯提升。
興奮（魅力）型需求—Attractive Quality/ Excitement Quality
用戶對該類型的需求并無明顯的期望，但是若產品能夠提供該類需求，用戶滿意度會極大提升，也會培養用戶的忠誠度。
比如，很多產品都有實驗室功能，即對那些不是必備需求的功能設計一個開關，用戶打開后可以進行使用。對于有的用戶來講，這些功能很大程度上會帶來驚喜。當然，每個人期望不一樣，實驗室方案也可以視為另類的灰度測試，用以驗證用戶對于功能的需求。
無差異型需求——Indifferent Quality/Neutral Quality
產品無論是否滿足該類需求，用戶的滿意度是不會變化的，正如用戶不會因為收到「瑪莎拉蒂5元代金券」而感到開心。因此在 B 端行業，開發時間有限的情況下，無需為該類需求投入資源。
比如優化一個用戶訪問量很少的網頁，也無需因為領導或者客戶的個人喜好而改變后臺頁面的顏色。無論使其鮮艷活潑還是穩重大氣，后臺滿足基本的視覺要求和規范即可。當然，這并不意味著你可以把后臺設計的簡陋和雜亂。
反向（逆向）型需求——Reverse Quality
當提供方向性需求的功能時，會招致大部分用戶滿意度的大幅下降。比如常見的在搜索中摻加廣告、強制用戶授權過多個人信息以及推送大量無用的消息等，會導致用戶的反感。
通常需求的收集不是你一個人在進行，產品經理、老板以及其他同事也會幫助你收集，匯總到你這里的需求會開會進行討論，下一步要做什么。
做之前首先要對需求進行評估，評估的原則基本是按照 KANO 模型來，但是也會有比較特殊的情況。
交互設計師需要注意的是，你除了需要關注用戶體驗的問題以外，還要與開發一起評估該需求的實現；你不懂技術沒關系，開發會告訴你該需求的落地會出現什么問題，在實現上會有什么難度。這些在評估需求的階段都要提出來，并且在交互層面解決掉，否則你畫出了原型以后，開發告訴你這個頁面必須要修改，否則開發成本過大，無法在排期內完成，這個時候你再去改交互稿將會費時費力。
評估完需求，定好下期開發的需求后就結束了么？
其實并沒有，因為需求收集不可能是一個固定的階段，它是漸進的、不確定的。因此收集需求和評估需求會不斷在實際工作中疊加和重復，比如你制定好了需求優先級，已經著手開發了；這時候老板或者領導突然又增加了一個優先級很高的需求，所以你得重新安排這些需求。如何在敏捷開發中保質保量的完成工作任務，這是一場斗智斗勇的 battle。
前面講到需求評估的時候，需要與開發人員一起評估技術難度。其實在你將需求落地為交互原型的時候，也需要持續溝通，這完全是為了避免因為技術問題而產生修改設計稿或溝通不順暢的問題。
如果你是在做的過程中，持續與開發人員保持溝通，能了解到他們是如何實現這個功能的。當然，有些基本的設計原則所不允許的事完全不用屈服于他們的「淫威」，畢竟他們得按照你的方案來。如果開發懶惰而想通過最簡單的辦法來實現，用戶體驗又是極其不友好，那么請直接對其說「NO」。
比如常見的刪除的二次確認等彈窗，一般最好的體驗是在按鈕旁邊彈出；但有些開發懶得寫彈窗，直接調用瀏覽器的彈窗，即瀏覽器頂部經常出現的那種確認彈窗，這個時候你要堅決告訴開發，這樣搞是堅決不行的。
需求的落地伴隨著競品分析，判斷一個需求是否靠譜、落地方案是否成熟的一個重要途徑就是競品分析，可以通過調查研究相關競品是如何進行設計的。這對于我們有著非常大的幫助，可以避免很多的彎路，甚至能避免犯錯，提高交互方案的可靠性。競品分析又是個比較繁雜的事項，如果是有特殊要求可以做成報告的形式，如果僅是去參考對照的話只需要去體驗競品即可。
B 端的業務比較重要，尤其是涉及到數據的增刪改查和金額的計算，一旦出錯，將會導致無法挽回的后果。因此在出錯前和出錯后，應該有相應的挽回機制。
1. 出錯前
內容編輯類的功能應該提供自動保存草稿功能，防止沒有及時保存而丟失內容；刪除、禁止等較重操作應該有二次確認，防止用戶誤刪。
對于操作流程應該建立明確的引導機制，長表單可以分開按步驟填寫。
提示信息應該明確而及時。比如一個表單需要登錄才能填寫，在未登錄的狀態下，應該先提示其登錄再填寫否則用戶在填寫大量信息后，因為一個錯誤而前功盡棄。
系統內的禁止信息、警告信息、提示信息建立一套相應的規則。
2. 出錯后
用戶的時間就是金錢，這對于 B 端商家角色中尤為重要，大量訂單的處理、表格化的導入和導出、批量管理和網站運營等方面，對于效率有著極高的要求，商家通過可視化界面來完成某項任務。
在這其中，影響最大的莫過于交互方式了，相信各位一定用過各大銀行的網站，頁面的導航關聯性弱、結構不合理、提示不明確、交互流程過長，甚至有的網站光是登錄，就得大費周章。
如何提率，我認為主要從以下幾個方面著手：
1. 提高易用性
如果你的產品，讓人看一眼就能上手，那么說明是非常友好的設計。易用性不一定意味著簡單和低智，依據復雜守恒定理（泰勒斯定理），每個應用程序都有自己內在的、無法簡化的復雜度。
所以，提高易用性意味著要設計合理的交互，易用性分為對新手（小白用戶）友好和對老用戶（專家用戶）友好，包括數量最大的中間用戶。
如果你的界面是僅僅對于新手友好，那么可能完成的任務都是簡單而輕松的。但是對于老用戶，他需要更復雜的功能來處理大量龐雜的任務；因此在設計的時候，既要提供傻瓜式的操作方式，也要對專家用戶提供提率的工具。
2. 智能化
此處的智能化既包括通過大數據或者人工智能自動將操作步驟變得簡潔，也包括諸如一些字段輸入、自動定位、圖片識別、OCR 等方式來使用戶的效率得以提升的功能。
以前的用戶要摳圖可能會在 ps 中操作好幾個步驟才能完成，但是隨著機器學習技術的發展，ps 已經可以更加智能的摳圖。當然，還包括其他功能的智能化。
在 B 端 SaaS 領域，智能化也是一個重要的趨勢，針對不同的商家所面臨的不同的行業領域，我們或許可以提供更加全面且友好的服務。
3. 場景化思維
如果你深入了解你的用戶，去觀察他們整個行業的運作模式，以及他們對于業務的處理方式，你就會明白你的產品的走向。
你需要深入每一個場景，比如，在戶外旅游領域，發布旅游產品線路的可能是在辦公室中的編輯人員，帶隊出行的是在戶外場景中的導游，現場簽到的可能是集合點的管理人員，而處理訂單的又是另一個坐在辦公室里的小伙伴。
他們需要協同工作，才能使各項工作順利展開，發布活動-用戶報名-訂單管理-報名人統計-活動成行-集合點簽到-帶隊出發-旅游結束-活動評價-領隊評價-交易成功，這一系列流程中，面臨的角色是復雜的，而意外也是常有的事。比如報名人無法參加活動而導致的退款、活動因為天氣原因而無法成行、戶外活動發生意外等。
你需要做的就是：
場景化的思維會讓你設身處地為一線操作用戶的體驗而努力。因此，交互稿完成以后，徹底回退到小白用戶的身份，假裝自己是在某個場景下要做某件事，通過你的交互方案，能否順利完成自己的目標。
此處的通用性是指，在 SaaS 軟件領域，不同客戶所面臨的行業有一定的差別，可能這個功能對于 A 用戶極其重要，但對于 B 用戶，該功能并不重要。比如有的客戶想要在前臺展示某活動的報名人的姓名以增加真實性，用以吸引用戶參加；但是有的客戶就明確反對該功能，認為這個功能侵犯了用戶的隱私。
諸如此類的需求相離、甚至相反的情況太普遍了。合適的解決方式是建立兩套開關，一套是由 SaaS 服務提供商的統一后臺來配置，用以區分比較大的行業差別，比如電商領域中，可以配置店鋪類型為：美妝、服飾、食品、電子產品等；另一套開關在客戶的站點后臺，用以控制不同的站之間的差別，比如前臺界面樣式、交易流程、相關字段或菜單的前臺顯示等。
另外比較重要的一點，也是最基本的一點，軟件設計中存在一個原則就是高內聚低耦合，模塊化設計，用以提高系統內部組件的復用。
交互設計也是同樣的道理，可以將你的商品視為一個模塊，那么這個模塊無論是添加到網站，還是小程序，我只需要創建一個商品即可，可以同步更新到不同的平臺。
另外，訂單的管理只需要添加相關的標記即可（比如來自小程序的訂單標記為小程序，淘寶訂單標記為淘寶等），一個平臺發布，多個平臺同步，有效提高了運營人員的效率。
同樣的，如果你的 pc 端產品和移動端產品沒有實質性的運營差異（即當成兩種模式來運營），那么很多數據（如文案、圖片、banner等）的獲取可以采用同一個數據源 。
最后，提高系統內的一致性，減少用戶認知成本。在同一平臺內的頁面，樣式和交互上要盡量保持一致性，不要有的地方是總金額，有的地方是總價格，這會讓用戶犯迷糊。提高通用性，也意味著你需要關注并熟悉系統內不同功能之間的關聯性，盡量做到統一處理。
在進行商業化運作和產品功能的優化時，對于正向的用戶需要激勵，對于負向的用戶需要限制。
這是我在讀完有贊的白鴉寫的關于有贊產品設計原則的文章后，影響最深的一個原則，他寫到：
我們的使命是幫助每一位重視產品和服務的商家成功。「每一位」和「商家成功」是我們最重要的關鍵詞，我們要服務的是每一位商家，然后幫助每一位商家成功，但是為了整個生態的健康，那些不重視產品和服務的商家，我們是（可以）不服務的。所以我們在產品設計原則上，在產品做一些功能的選擇上，如果這個功能做完了會導致商家不重視產品和服務，我們是不會/能做的。
舉個例子：消費者購買之后（可以）有一個評價，我們的購物評價是要么開啟要么不開啟這個功能。我們不接受商家去刪購物評價，因為商家一旦可以刪了消費者的差評，他就（很可能）不會那么重視產品和服務了。所以有贊永遠不會提供刪除商品評價的功能，商家要么就不開啟。可以不用，如果要用就要接受有人說你不好，商家可以去跟消費者溝通，溝通完了消費者自己改，但是我們不提供讓商家刪壞評價的功能。所以，這就是最基本的有贊產品設計原則，我們只服務重視產品和服務的商家，我們所有的產品設計原則都是需要這樣。
——《白鴉內部培訓：企業服務類產品的底層邏輯和有贊產品設計原則》
更多內容請看：
我將其概括為一個產品的中正原則，即中立且保持正向原則。
一方面，對于企業未來的發展而言，正向的用戶能帶給平臺無盡的潛力，平臺可以和商家一起成長，而負向的用戶，則會給平臺帶來隱患。比如，淘寶既限制商家的違規運營和欺詐客戶，也限制 C 端用戶的惡意薅羊毛，在商家和用戶之間做一個中立者和調節者的角色。
我在做需求的時候，也遇到過很多的負向需求，這在商家看來是一個必須的功能，作為平臺應該提供。但是若是提供給商家，則會對消費者的利益造成損害，刪除差評就是一個很好的例子。
看了白鴉對于有贊產品原則的闡釋，我覺得每一個平臺類的產品，都應該保持自己的中正原則：
在 B 端行業，口碑傳播是非常重要的一種被動營銷方式，很多 B 端公司都是低調的潛行者，堅持中正原則，并不會損害自己的利益，反而會獲得商家的尊重和消費者的信賴。
啰啰嗦嗦說了這么多，比較細碎，不乏邏輯凌亂的片段，但也算是對自己兩年以來對于 B 端交互的一些心得吧。
其實交互的原則基本都是通用的，無非就是根據平臺屬性做一定的調整，不同的是產品所處的行業，每一個產品都無法脫離其所處的行業而存在，這也是使用產品的具體場景。
因此做一個產品前，一定要了解行業，去熟悉行業的通用做法，了解行業的專業術語和規范，研究行業的所屬群體等，這樣你就會做出真正適合市場且能讓大多數用戶滿意的產品。
文章來源：優設