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