起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品設計中，用戶體驗可能不是重點
本文作者依據工作中項目實踐的所思所想，結合案例等分享了B端產品設計的相關流程以及過程中需要注意的關鍵問題，供大家一同參考和學習。
為什么寫這篇文章，是因為由我參與改造的一個系統正式投入市場后，經過幾次的迭代，親自接觸了客戶，獲得了認可，有些真實的感受想和大家分享。
大部分產品經理的職業成功之路是成為某個領域的產品專家，而做B端產品經理是一條成功率極高的路，這就是我選擇B端的原因。
我是大學期間就開始創業，折騰了幾次之后，交了一些學費之后，果斷求職。
先是去了一家房產中介公司做房產管理系統，一年之后進入現在這家教育公司，
現在是負責設計一款SaaS型培訓系統，你要問我對這個行業了解多深，完全是從一個小白開始的，經過一年多的深度實踐，現在可以用我設計的系統幫助客戶做信息化改造，幫助客戶實現線上線下混合式培訓。
這就是B端產品，Business，即商業，幫助客戶實現戰略需求，從線下已有的運行業務進行信息化、系統化、高效的處理。
B端產品基本模塊由用戶管理、權限管理、OA管理、CRM管理、營銷管理、訂單管理面、報表統計等組成，幾乎覆蓋B端客戶能應用的管理場景和運營場景。
一個行業經過幾十年的發展，才形成行業標準，一款成熟的系統本幾乎覆蓋上面提到的產品模塊，面對這樣一個錯綜復雜的場景，產品經理最好的做法是循序漸進，從最粗略的業務目標開始，然后分析業務流程，到各職位的工作內容，最后才是數據、報表的細節。
從理論知識，到具體的設計，到部署上線，再到客戶使用，這整個過程中我將踩過的雷在這里跟大家說說。
01 系統基本情況介紹
先說一說，我接手這款產品的背景，據說已經做了6年了，是從一個純線上學習平臺改造過來的，底層結構固化，客戶使用者個位數。
隨著教育信息化的普及，互聯網的高效、便捷的特點，讓市場需求越來越大，客戶付費的意識越來越強烈。
面對日益丟失的市場，可想而知，公司面臨著很大的壓力，我們這些干活的自然而然有了壓力，從市場業務人員，運維人員，產品團隊，技術團隊對客戶的需求有了清晰的認識，這款產品到了不得不改的地步了。
我們這款產品已經有用戶在使用了，為了滿足這些客戶未來發展的需要，降低運維成本，一款SaaS型產品最大的好處就是可復制，一星期就能就能完成新租戶系統部署上線。
于是我們領導確定了改造方案：在原系統上改造升級。
02 產品背景分析
在開始做產品規劃之前，首先要對產品進行定位，?這就要求多問自己幾個問題，這都是吃過虧總結下的：
- 這款產品解決了客戶哪些問題？
- 客戶為什么需要這款產品
- 適合什么類型的客戶
- 這個產品涉及到用戶是誰，什么部門？
- 這個產品幫助客戶想要達到的目標是什么？
- 這個產品的范圍是什么？
- 這個產品成功的標準是什么？
這些問題能幫助我們搞清楚產品的目標與價值，找出系統的關鍵受眾，列出他們要解決的問題，分析業務，尋找產品范圍，最終針對特性，提出系統用例細化功能需求和非功能需求
第一階段的任務是對產品所服務的業務領域有一個概括性的了解。我們可以從行業背景、業務目標與訴求、組織架構、崗位劃分等方面開展研究,這就是產品背景分析。
做背景分析的目的：要對我們的產品要重新定位，從原本模糊的客戶變成針對某一個行業，某一類的客戶，這樣能幫助我們明確目標，縮小業務范圍，這樣我們更好的深入了解業務，更好匹配客戶需求。
雖然第一層次并不足以讓我們了解業務具體運轉的邏輯，但是通過業務架構描繪出的一幅業務全景，對于進一步了解需求幫助巨大，這樣就不會迷失在茂密的需求森林中。
1. 產品背景分析的技巧
無論是設計C端產品還是B端產品，首先我們都要對“使用者”進行深入的分析：
C端產品直接看用戶特征，為用戶做畫像做分群；
B端產品則需要剖析B端行業的經營過程，再去看不同使用者的需要。
每個產品都有特定的用戶群體，B端產品也不例外。背景分析的第一步，首先我們要搞清楚，產品到底是賣給誰？
做C端產品時，我們習慣用“用戶故事”幫助我們定義用戶類型；做B端產品，同樣我們可以用一個“企業故事”幫助我們理清目標群體的需要。
2. 企業故事可以這樣描述
目標客戶是一家___客戶，沒有用我們產品之前，他們是這樣工作的：_____當前客戶在工作方式上出現了____問題，因此需要借助我們產品解決____需要，期望達到___的需要。通過這個企業故事，我們可以定位到產品針對什么行業、什么規模的企業，然后明確了這類公司的核心訴求，將來在做功能與設計的時候可以圍繞著這個核心訴求展開，也是產品不斷更新迭代的方向。
3. 業務需求資料來源
了解客戶業務需求資料的途徑，主要分為兩種：被動獲取和主動獲取。
- 被動獲?。?/strong>從客戶給的市場需求文檔、技術方案、合同、招標書等獲取；
- 主動獲?。?/strong>尋找合作的客戶，現場觀摩、溝通調研。
被動獲取資料的行業，一般市場上已經有這樣的產品，客戶有了明確的要求，產品經理只要根據這些描述，基本上能還原業務場景，然后做需求分析。
但這樣的需求分析是有缺陷的，因為這里面一些需求是客戶定制化的，不能代表同行業其他客戶的需求，這就需要產品經理收集更多的資料，從中抽離出共性。
主動獲取合作的客戶，需要依賴公司的長期積累的資源，通過市場銷售人員的反饋尋找標桿客戶。
不是這個行業的軟件公司想做這個行業的軟件產品，最高效，最便捷的方法就是尋找標桿客戶。
4. 標桿客戶的標準
你要尋找這個行業規模做的比較大，組織機構健全的客戶，因為大家都會相互學習，相互模仿，誰做的好，他的管理方法逐漸被其他客戶了解，并效仿，你做的產品才能迎合這些潛在客戶的需求，才能獲得更好的口碑。
在這個尋找標桿客戶的策略上，我們就走了彎路，選擇了一個規模不大的客戶，重管理不重運營，導致產品目標跑偏了，系統耦合嚴重，操作繁瑣，不僅沒有獲得市場認可，反而還讓競爭對手反超了，就因為標桿客戶選擇的比我們的更精準。我們花了一年的時間進行修正，終于回到正軌上，很多研發資源都投入到這個系統上，這個代價是很大的。
做產品背景分析是讓我們對產品做到“心中有數”，接下來的需求分析是我們產品設計的重點。
03 需求分類
在做C端產品時，最重要的步驟是需求梳理，也就是思考什么類型的用戶在什么場景下遇到了什么問題。
那么在做B端產品時，什么是B端產品的需求分析呢？
這個看似簡單的問題并不那么好回答，很多人認為的B端需求就是幫助用戶完成業務流程所需要做的事情。但這樣的理解并不完整，
需求分析并不是在分析系統如何實現用戶的需求，而是選擇一種業務導向的指引將零散的需求串聯起來，形成一個體系完整、內容清晰的框架，為下一階段的產品設計工作做準備
真正接觸了客戶你會發現B端的需求包含三種：
1. 表面需求（用戶想要的）
用戶經常從自身角度出發得出問題的解決方案。因為對產品定位、設計的依據等情況不了解，他們的建議很多時候并不是該功能的最好實現方式，也就不足以直接作為產品規劃的直接依據。如果根據表面需求來設計產品的話，很可能會出現“頭痛醫頭，腳痛醫腳”的情況。
2. 本質需求（用戶需要的）
用戶想解決的根本問題。獲得用戶的本質需求更可能找出更合理的方案來解決用戶的問題。
3. 產品需求（我們能給的）
依據用戶想解決的根本問題，得出的更好的問題解決方案。解決方案可以理解為一個產品，一個功能或服務，一個活動。
這里重點分析一下需求轉化的過程，叫需求透視，即透過現象看本質，我相信這是每個產品經理必須具有的產品能力。
我們們要做的事情就是挖掘本質需求。
主要任務是梳理清楚目標客戶所有的業務類型。為不同的業務類型劃分界限。并梳理出每個業務類型中所有的需求，也就是需求透視的過程。
04 業務流程分析
做好需求透視第一步就是要做業務流程分析，就是針對每一項業務事件，分析業務活動的特點，并確定業務活動之間的關系。具體要做的事情是：
- 記錄這些業務活動需要接收哪些信息；
- 記錄這些業務活動將產生哪些數據（報表），并確定數據傳輸的路線；
- 標識出這些業務活動是由哪些部門、崗位在負責；
B端客戶的核心價值就是對外部用戶的訴求進行處理，在為用戶創造價值的同時，為B端客戶創造價值。
因此由業務事件觸發的流程是分析需求時的核心線索。
在進行流程分析的時候有兩個關鍵要點，一是理解流程的層次性，二是了解流程的類型。
1. 流程的層次性
為了方便大家理解，這里我以親身實踐的一個客戶培訓來舉例：某省農業農村局委托某高校承辦全省鄉村第一書記參加某線上直播培訓。
流程有組織級、部門級與崗位級三個層次；
- 其中組織級是指經過抽象、提煉后的業務事件，如上圖中受訓方、組織方、承辦方；
- 部門級是指具體每個崗位負責什么活動，以及這些活動之間的關系。它是需求分析的主要線索，也是流程分析的主要輸出，如上圖中的省農業農村局、項目管理部等；
- 崗位級是指每個業務活動具體的操作步驟，屬于需求細節，如上圖中負責人B，班主任C等。
整個報名流程，在我們平臺如何實現報名需求：
第一種方案：市場部告知項目管理部有某個培訓要組織，項目管理部在平臺創建培訓班，有組織方分享給受訓方自己線上報名，班主任直接看后臺數據就可以了。
第二種方案：有組織方上報報名名單給項目管理部，項目管理部在平臺創建培訓班，導入用戶名單，生產用戶賬號，發送報名成功的信息給用戶就可以了。
2. 流程的類型
在B端客戶實際業務中，根據業務流程的目標可以將其分成不同的類型，一般我們可以分為生產流程、管理流程以及支撐流程三類。
- 生產流程是流程中最重要的部分，也是體現B端客戶價值的業務環節，通常最容易識別；
- 管理流程是對生產流程的管控，通常是對流程效率與質量的監督控制；
- 支持流程是對生產流程的補充，通常是對主流程起支撐作用的環節，非必須但容易忽略。
在本次培訓過程中，高校培訓部作為承辦方，在進行項目申報、培訓方案制定、培訓班創建等這類環節都屬于生產流程。
在這個主流程以外，每一個環節都有相應的審核操作，以及培訓過程中進行學員簽到、考核等這種流程屬于管理流程。
在培訓過程中，需要合同審批，項目備案、后勤管理等這些流程屬于支持流程，有這些功能更好，沒有功能能實現，客戶自己線下也能實現。
在產品設計的過程中，我們優先設計生產流程，也就是B端客戶的核心產品模塊；
在生產流程走通的情況下適當做一些管理流程，以保證客戶滿意度，這是產品亮點，也是產品的目標；
在后期的迭代過程中，根據客戶的要求上線一些支持流程功能。
05 角色與使用場景分析
做好需求透視第二步就是要做角色與使用場景分析，這個是很重要的分析過程，一個功能脫離了用戶使用場景，用戶就會感到很不爽，甚至直接放棄使用。
上面講的企業故事，這里講一個用戶故事來幫助大家做角色與使用場景分析。
作為某某使用者/參與者，通過某項操作，以便能夠達到特定的目標。
用戶故事是指某種類型的用戶為了完成某特定目標所執行的一系列操作。在描述層面我們可以暫時忽略業務目標，因此一條用戶故事包含兩個元素：參與者、做什么事。
例如，班主任要求學生完成簽到，就會遇到很多應用場景：有學員在現場報名時簽到，有每次線下上課前進行簽到，有每次線上上課前進行簽到等等。
于是我們平臺有了數字簽到、雷達簽到、動態驗證碼簽到、靜態二維碼簽到，這個四種簽到方式。
可有了這些簽到方式，常常還是有客戶抱怨太難用，很難理解系統的意思，也不知道從哪里去找需要的功能。
因為在傳統的結構化分析與設計方法中，對事物的分析視角都是站在解決方案層面思考的，即這個系統需要有什么，從系統的角度出發做功能規劃。
而以“用戶故事”驅動的需求分析方法，是一種更側重于“從用戶的角度出發，將系統當做一個黑盒子”的視角，這種方法能夠有效解決上述問題。
以線上學習每次班主任發起數字簽到為例，因為每次培訓正式開始前，班主任都會創建微信群，方便總要信息及時通知學員。這個場景下班主任和學員特別依賴微信群。如果班主任發起簽到能直接分享簽到鏈接到微信群，學員在微信群里直接打開完成簽到操作。學員不用在平臺之間直接跳來跳去，切換操作。
這樣一個分享的操作，即減輕了班主任給學員反復解釋操作流程的工作量，也簡化了學員的操作流程。這樣用戶就會感覺很爽，班主任也沒有負擔。
從另外一個角度來說，用戶故事的關鍵點在于發現使用系統的用戶，了解并梳理這些用戶如何使用系統，從而達到“以人為本”的需求分析。
面對一個陌生的領域，一個經歷了多年發展變化的業務流程，要在短時間內弄清楚的確是一個不小的挑戰。用戶場景分析的意義在于幫助產品經理在短時間內從結構、整體上了解業務構成。產品不斷迭代的前提就是建立在用戶場景不斷優化、不斷調整的過程中。
06 獲取用戶需求
在客戶調研的時候，經?？吹疆a品經理傻里傻氣地問客戶：你對這個產品有什么需求或者有想法嗎？
但不管用戶怎么回答，似乎都很難讓我們滿意?？蛻籼岵怀鲂枨?，你會覺得我們的客戶對這事好像也沒那么上心；更多的時候是客戶提的需求都是不痛不癢，或者你感覺極具個性化，讓你感覺做也不也是不做也不是；
和C端場景一樣，B端場景中的用戶需求也像是一個冰山，有很大一部分信息是埋藏在海平面之下，這就對需求調研工作帶來很大的困擾。
調研的客戶畢竟不是技術專家，只是普通的業務人員，因此他們沒有辦法對其工作提出產生變革的解決方案。因此需要產品經理對問題充分理解的前提下，選擇合適的實現方式以創造出用戶未想到的功能；
我在本次產品改造過程這些場景，也經常遇到，其中一個經費審批表導出就改了無數回，最終還是不滿意。
例：客戶提出需要導出PDF格式，防止業務人員隨意篡改。
我們照客戶的要求實現，我們滿心歡喜地給到客戶時，客戶說這功能還是不實用，發現在實際工作中，有的文字內容過多，表格顯示不全，導致分頁顯示，客戶表示不滿意，我們后來改回了word格式。
客戶反饋他們需要導出每個審批步驟和審批結果，我們照客戶的要求實現，發現在實際工作中，他們增加了審批步驟，還是導致分頁顯示。我們后來我們改成了審批流程自定義導出。
反反復復修修改，最終的方案，就是按照客戶模板回填數據即可。
這樣一個很小的功能，導致我們投入很多的開發資源，深挖客戶需求原來是：客戶從線下審批到線上審批需要過渡，需要平臺 數據導出數據以備年度領導審查，備案需要。
這個例子就是我們只發現意識到的需求，而沒有深究以及進一步分析的后果。
實際上B端產品的需求獲取并不難，難的是與用戶交流溝通的過程。因為我們的用戶僅僅作為一個使用者，他只是站在自身使用的視角，想讓自己的工作方便一些或是在利益分配上對自己更有利，很難站在系統規劃的角度考慮全面整體的東西。
遇到這種情況，最有效的應對策略是需求分析從流程入手，搞清楚業務活動在平時是如何開展的，再逐步過渡到存在什么樣的障礙，有什么困難等等。在這個過程中，多問幾個為什么，多思考客戶訴求背后代表的心里狀態與利益沖突。
所以這一階段，我們主要做的工作是收集針對業務活動的問題點、需求點。這時候我們獲取到的是原始的用戶需求。
實際上，在整個業務分類、需求梳理的大環節中，業務流程分析、角色與使用場景分析、以及獲取用戶需求都是伴隨著用戶調研進行的。
用戶調研是一個有計劃、循序漸進的過程。具體來說，在針對不用的訪談對象時，訪談的要點也不盡相同，具體的要點參考以下表格：
除了用戶訪談和問卷調查以外，有機會到業務工作中實際現場觀摩也是一種很好的需求獲取手段，有助于產品經理對業務場景建立更加感性的認識。在對關鍵任務理解不清晰、很多東西用文字沒辦法表述時，現場觀摩都是一種很好的方式。
到了這一步，我們已經收集到足夠多的業務信息供我們進行后續的需求分析工作。
07 需求細節確認
首先，我們按照需求列表按照職責、部門、崗位整理歸納，這樣我們能把產品劃分成不同的業務板塊，在這個層面看哪些系統需求是針對業務事件，確保業務流程正常進行的；哪些系統需求是針對報表的要求，確保流轉過程中的數據傳遞；
接下來再往更細顆粒的維度整理，梳理哪些系統需求是支持業務步驟的，基于這些業務步驟需要設計什么樣的功能點。這樣一來所有的系統需求都按照清晰的脈絡，層層遞進展現在我們面前。
在這些需求梳理的過程中要明確哪些是前置條件，哪些后置條件。
所謂前置條件是指在用戶操作某個功能的時候，用戶與系統應處于什么狀態。這個狀態是系統能夠檢測并且是有意義的。而后置條件是指在操作結束時，系統應處于什么狀態。同樣這個狀態也是系統能檢測到并且有意義的。
再通過上面組織培訓的例子來加深理解：
受訓方有培訓需求：這不是一個前置條件，因為這是系統無法檢測的；
當市場部和組織方達成合作意向，甚至簽訂協議或合同：這也不是一個好的前置條件，雖然系統可以檢測，但是只是一個支持流程，不是主要流程，客戶可以選擇不用，這個事情所表現出來的意義不大，對我們來說沒有幫助；
在項目申報審核通過：這是一個好的后置條件，當然也要根據客戶實際使用情況，但是系統可以檢測并且事件對流程有影響；
項目申報通過后，項目管理部或市場部進行培訓班的創建，復用項目申報的一些基礎數據，添加培訓簡介之后對外發布展示。
一般來說，前置條件通常是一種狀態，后置條件可能是一種狀態，也可能是一種后續行為。并非所有的業務流程都必須在平臺上存在前置條件與后置條件。
明確哪些是前置條件，哪些后置條件，能減少甚至避免在功能設計中流程耦合。
這種結構是以業務流程為整理的主線索，也就是按“事”的角度進行分解。這種方法對于工作流系統以及信息管理系統來說都是非常適用的方法。
08 消除需求間的矛盾
以上整理需求的方式，是按照業務流程進行整理的。在這個分析過程中，因為我們的需求來自不同的部門不同的崗位，難免會發現有些需求是互相矛盾、互相沖突的。
因此我們在整理后的列表中需要將這些矛盾的需求全部圈出來，然后快速地找到相關人員，通過進一步的溝通協調來消除矛盾的需求。
很多時候，需求沖突的真正原因是使用者與管理者之間的沖突。作為使用者，他的核心訴求是方便高效、省事，最好還能在某些方面獲得一定的利益；作為管理者，他的訴求是流程規范、過程可追蹤，杜絕損害公司利益的事情發生。
例如，項目管理人員/市場部因為委托方有很多不確定因素，自然希望在項目申報的時候能夠更彈性，有一些自由度。但是作為主管部門領導，他們需要嚴格執行審批制度、財務報表審批制度等，導致系統上有很多信息是必填項，操作者感覺很繁瑣。
從這個例子可以看出來，不同角色由于崗位不同，核心訴求也不一樣。
在發生沖突的時候，我的建議是以客戶的生產經營為核心，首先確保經營活動的規范化、流程化進行，在這個基礎上增加為普通使用者考慮的易用性設計與情感化設計，讓他們感受到產品不單單是一個反感排斥的工作系統，而是真正幫助他們提高工作效率的產品。
完成這一步后，才算是將整個產品的系統需求全部整理出來。以后每次迭代就是在業務需求與用戶需求的基礎上，創建新的系統需求，不斷完善、豐富產品。
09 最后
大多數C端產品的設計邏輯會把用戶體驗與效率放在首位，追求極致的簡單好用于高效。在整個產品設計上比較側重用戶的感受，精心打磨頁面與交互，盡量少讓用戶做選擇，保持產品的易用性與流暢性，都是做C端產品設計的不二法門。
但是做B端產品時，所有的產品設計都是為“流程”服務的。體驗和效率未必是設計的重心。
很簡單的一個例子就能明白：我們按照客戶的需求上線CRM模塊，不是為了讓市場人員更輕松，做業務的時候更“省事”，而是為了將整個客戶跟進的流程管理起來，做標準化的流程，為管理者提供更準確科學的決策。
又比如上面提到的，班主任和學員之間的互動基本都是靠微信群進行，這就要求我們產品增加微信一鍵登錄，微信分享機制，來減少學員的操作路徑。
B端產品更多是通過計算機技術實現B端客戶的信息化管理，對業務流程進行優化升級，從而達到降本增效的目的。
由此可以看出來，做C端產品更注重對“人”的理解，要求產品經理具備同理心，感知用戶的能力。而做B端產品更注重對“業務”的理解，要求產品經理具有系統性的邏輯思維，富有理性地對客戶業務進行全面梳理與診斷，給出合理有效的解決方案。
作者：時光；公眾號：時光遇見生活
本文由 @時光 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
不敢茍同。B端產品的體驗和效率甚至要更關注，如果工作臺不好用，如何保證企業的“流程”順暢？
不敢茍同。應該說C端更注重視覺設計，在視覺設計上很下功夫。B端對視覺設計要求不高，但也需要統一風格。并且無論B端和C端，都需要保證交互邏輯順暢，簡單通用。
將整個客戶跟進的流程管理起來，做標準化的流程，為管理者提供更準確科學的決策。—-這點和要把交互做好并不矛盾。并且，B端是決策者付費，但使用者也需要好用，如果使用者無法理解你的產品設計邏輯，用起來十分浪費時間，底部人員抱怨多了，管理層也會考慮要不要換軟件。
幾乎是完全不同意作者觀點：
首先作者對C端和B端的理解太過模糊和籠統，C端和C端軟件也是不同的，對于絕大多數C端產品，用戶體驗的核心是線下而不線上。比如：用戶用京東是因為質量有保證、快遞快，用拼多多是因為便宜，用愛奇藝是因為片源豐富且好，用抖音是因為抖音里有感興趣的視頻，這些和APP以及APP的用戶體驗好幾乎沒有半毛錢的關系。而B端的用戶體驗往往就是軟件本身，B端軟件本身解決的就是一個效率的問題，B端用戶的核心用戶體驗其實就是解決企業效率問題，軟件體驗做的差，實施效率低，使用效率低，維護效率低，用戶用不起來，這個軟件就沒有價值。B端軟件就是一個工具屬性，工具就好比一把扳手，如果這把扳手很難擰下來螺絲，這個扳手就沒有價值。
第二：作者對用戶體驗的理解，還僅僅限于交互的效率和界面。其實真正的用戶體驗是幫用戶解決問題，不僅限于界面、交互和觀感；
第三：我本人是做了十幾年B端產品的資深產品設計，目前在一家國內知名SaaS公司工作。目前的客戶對用戶體驗極度的敏感，多點一次都不行，我們任何一個體驗的優化都是極其謹慎的，并且分批灰度。稍有不慎，就會招致一堆用戶的投訴和反饋。
換句話說，B端軟件本身解決的就是一個企業效率的問題，如果安裝，實施，使用，維護B端軟件本身就是一個低效率的事情，那么B端軟件的價值何在？
贊
完全同意，我是看標題才點進來看一下，覺得作者會誤導帶偏小白B端產品經理。B端產品的發展趨勢就是借助流程的體驗、界面的體驗、用戶行為路徑的體驗進行全方位思考，來解決老的B端產品只重視解決業務問題留下的各種痛點。
贊同
非常理解，b端產品最重要的是提供一套客戶需要的解決方案，對于很多產品經理眼中的亮點功能，比如產品的美觀度、可用性，他們真的沒有特別大的觀感
看大家對作者的觀點站在不同立場各有其道理，我覺得，B端產品先是功能滿足，就是作者說的省事，再是好用，也是作者提到的用的舒適。結合這些年B端產品實施經驗，大致是這么個情況。但是，需注意是，省事滿足，舒適度很差，使用繁瑣，那這個B產品可能很難用起來
文章有標題黨嫌疑哦 其實主體都在講分析使用場景和需求的東西 作為產品新人 學到的是角色和使用場景分析這部分內容 說真的 和UX關系不大 所以樓上的也大可不必
被你發現了，這是產品運營小姐姐的功勞，我的公號文章標題，不是這個，哈哈
不管文章觀點對錯，都尊重作者的努力付出，但是標題黨把我帶進來，我不認可這種騙流量的行為，所以不覺得是什么功勞。建議你們的運營小姐姐要區分一下用戶的場景。
作為一個UX設計師，對你這個觀點持100%反對的態度。B端產品比C端產品更難做，是因為B端產品不僅要以決策者為本，還要以人為本。B端產品的用戶體驗也不僅僅是使用者，B2B的產品，在與企業合作前、合作中、合作后，都必須使用戶體驗朝著好的方向去發展，通俗地講就是合作前把客戶陪好也是一種用戶體驗，客戶的體驗好了，也能推進合作。
也許作者將用戶體驗片面的理解為是操作體驗，但同樣的，使用B2B網站的業務專業人員也在大量的B2C網站上操作，Jakob Nielsen的互聯網用戶體驗定律指出，用戶會從他們訪問的大多數網站中形成自己的心理模型期望。
所以總的來說B2B和B2C的用戶體驗是相輔相成的，對作者的觀點不敢茍同
歡迎大家來拍磚，互聯網產品只是工具，SAAS服務盛行，可代替者很多。我在做B端產品經理的同時，兼職著售前工程師的工作，能接觸到更多的一線客戶，深有體會，我相信任何做B端產品的公司，一定覺得自己的開發資源有限，因為需求永遠無法全部滿足，怎么在有限的資源上，開發出更符合客戶要求的產品，我想良好的用戶體驗就不是團隊的重要方向了，細節當然重要，更重要的是“流程”，如果這個方案搭配著我們的管理和運營系統能讓客戶原有的業務走的更快，走的更廣，即使我們產品頁面顏色做的不好看，圖標不協調，客戶也愿意給我們付費，這就是B端產品的思維，所有B端產品設計都是為“流程”服務的。，所以體驗和效率未必是設計的重心。這是本篇文章的觀點。謝謝！
所以你說的是狹義的用戶體驗，你所說的為“流程”服務，注重“流程”，這個“流程”也是用戶體驗的一部分
這篇文章的結論有些片面了?，F階段的B端用戶用了太多C端產品后，對B端產品的用戶體驗的要求也是直線上漲，不但要求功能實用，也強烈要求好看好用。
當然，不同客戶對于用戶體驗的要求和標準也存在較大差異。
文中的這個客戶，恰好可能就是對這塊要求不算高的客戶。也許換一個客戶，這個結論就會被直接推翻。