本文認為，B端設計是基於任務為核心的設計模式，無論多龐雜的設計都是基於任務去解決需求。因此，作者提出了以任務為核心的 BTSD 設計模型，這對完成商業目的和提升用戶體驗有積極的作用。
提起 B 端設計，我們可能下意識的會想起後臺設計，大部分情況是以 PC 端為主的界面設計。更深一步去想，B 端設計的需求來源是龐雜業務，設計師的主要工作是為了滿足這些需求給出合理方案。在大量的需求和邏輯中，設計師的方案往往顧此失彼，使得設計不能同時滿足用戶體驗和業務需求。
無論面對多龐雜的 B 端設計，我的解決方案永遠都是基於任務為核心的設計模式，它是基於任務場景、任務發起方、任務角色、產品易用性的綜合考量，是解決龐雜 B 端設計問題和提升產品易用性的利器。
在多年的工作中，我提出了以任務為核心的 BTSD 設計模型，為完成商業目和提升用戶體驗助力。
一、什麼是 BTSD 模型？
1. BTSD 模型的定義
首先，我們先來看一下以任務為中心的 BTSD 模型：
- B=商業價值 Business
- T=用戶任務 Task
- S=設計策略 Strategy
- D=設計方案 Design
商業價值引出了用戶任務，用戶任務引領設計策略，設計策略決定設計方案，設計方案賦能商業價值。
2. DTSD 模型的由來
你已經發現，BTSD 是增長設計的變體；增長模型是商業價值引領設計策略，設計策略決定設計方案，設計方案賦能商業價值。
二者的卻別在於 BTSD 引入了用戶任務的模塊。
對於 C 端產品來說，用戶是主動使用產品，從而滿足自己的各種需求；而對於 B 端產品來說，用戶一定是被動使用產品，從而完成各種任務；所以任務才是 B 端設計的核心，圍繞用戶任務進行設計，才能最大程度的滿足業務需求。
二、任務的基本概念
1. 任務的定義
「任務」可以理解為有目標的活動。
對於以螢幕為載體的界面設計，「用戶任務」可以理解為界面之上系統和用戶共同完成的有目標的活動；
2. 任務，界面，資訊系統，用戶和體驗的關係
「界面」是用戶和資訊系統的橋梁，商業設計師的角色其實更像是一名構建橋梁的翻譯者。
詳細來說就是將硬件和資訊系統的抽象，通過界面的橋梁，把資訊翻譯給用戶的翻譯者，讓用戶完成有目的的操作（即任務）。
當下，無論是 SaaS 類產品還是 C 端產品，都面臨存量市場的競爭，產品的易用性和體驗已經提升了到很高的位置。
翻譯者工作的好壞，有時會決定產品的成敗；比如20年疫情期間，Zoom 的異軍突起，就是因為它的線上體驗優於其他產品。
商業和體驗是不可分家的，只考慮體驗的商業不可持續，只考慮商業的體驗沒有底線。
3. 活動的定義
活動本身是資訊系統和用戶為了完成用戶任務產生的全部操作、動作。
想要徹底的理解活動，我們還需要從用戶和資訊系統的兩個層面理解。
資訊系統的本質是為了對數據的增刪改查，資訊系統的增刪改查也是其的動作，資訊系統可以包含抽象的資訊、關係、功能、數據等。為了實現有目的的增刪改查所以出現了功能。
用戶來到界面的普遍路徑為辨識、發現、操作、反饋，在可用性測試中，我主要驗證產品對用戶的認知（能不能認得）、知覺（能不能找的到）和操作（會不會用），由此可見，辨識、發現、操作是用戶的行為，反饋是用戶和系總共同作用後的結果展示。
4. BTSD 的核心
將用戶行為和系統功能提煉整合後，我們就得 BTSD 的核心，從用戶任務起始到完成目標的關係圖。我們不難發現，這也符合設計工作的本質，從抽象到具象的翻譯。
5. 任務與流程和過程
為了完成任務，我們一定會經歷一個過程，當出現條件分支時，就產生了流程，所以用戶任務是通過過程或者流程完成的。這也解釋了產品設計師做流程圖的方式，先將過程梳理，最後加入變量（人因/條件判斷），最後形成流程圖。
6. 任務和目標的關係
完成一個目標可以有多個任務，比如我們最熟悉的審批，為了完成審批，需要負責人完成審批任務，需要申請人完成填寫和提交的任務。所以任務和目標的關係是 N:1。
一個流程或過程可以有多個目標，而目標之間可以包含關係的，比如OKR，Object 可以理解為父目標，KR 可以理解為關鍵子目標。
需要注意的是，任務和任務之間不存在包含關係，任務和任務之間只存在串行和並行關係。所謂串行任務，就是某個或某些任務是另一個任務的前置條件，所謂並行任務就是彼此沒關係，比如我要刪除照片（任務），首先我要在系統中有照片（創建照片）。
7. 任務的「大與小」
在理解完上述基礎概念後，我們再進行深挖。
我們先理解最主要的任務，一個資訊系統最主要的任務是由其業務決定，業務決定了產品有什麼功能和什麼角色去使用，角色對應的任務就是資訊系統的「主」的任務。
為了方便用戶去完成任務，設計師會根據角色任務規劃導航，每個導航的入口也對應了用戶任務。我將其命名為「大」任務。
對於資訊系統來說，為了完成每個任務，用戶需要達成一個又一個的目標，我們為了使目標易達成，會制作流程圖，對應某一個大任務的流程圖內的子目標，又產生了「中」任務。
為了完成「中」任務，用戶的直接接觸點是界面，所以我們可以將組件/控件也拆分為獨立任務，比如創建一個用戶的任務要填寫用戶資訊，選擇用戶性別是任務，輸入用戶姓名是任務，提交表單是任務，所以「選擇用戶性別」和「輸入用戶姓名」由最基本的組件/控件/交互模式完成的任務我稱為「小」任務。這麼看來，每一個組件組件/控件都對應一個用戶任務。
「小」任務的描述可以用數據類型+任務形式的方式去描述。
對於設計師，需要了解的數據類型有14種，其中日期、時間、數值、金額是有序數據。
用戶在界面的「小」任務可以分為單選、多選、區間選擇、輸入、上傳、其他。
我將單選作為系統的「原子」任務，也是系統的原子操作。用戶來到界面，主導航讓用戶完成入口選擇是單選任務；在列表選擇某一項也是單選任務；任何任務其實都可以拆分為原子任務，比如多選可以拆為多個單選。
所以，對任務的認知直接決定了界面交互的合理性和易用性。
三、BTSD 的設計流程
我將 BTSD 的設計模型的實現轉化為五個設計步驟，任務拆解→洞察需求→設計策略→設計方案→設計驗證。
1. 任務拆解
首先我們要知道本產品的核心價值或者北極星指標，依據目標提煉產品的核心任務；其次，我們需要提煉產品的主要使用角色，根據核心任務制作用戶的角色+任務泳道圖，有時，我們還需按任務頻次進行分類。這樣，我們就對產品的「主」任務有了基本的框架，並且可以配套構架/優化「大」任務 – 導航。
同時，我們需要了解用戶的使用場景，比如用戶大多在什麼場景、用什麼端口，一開始不要太細化這裡，只做大方向標註，因為真實的使用場景是用戶和系統相互培育出來的，是不斷更新和平衡的。
最後，我們就可以看到產品的主要使用角色與主要任務的關係，當然我們不能忘了產品購買者最在意的任務。
從上述不難看出，我們這一步的主要目的是明確產品目標並發覺其與任務和角色的關係，判斷任務的重要程度。
2. 洞察訴求
我常用的洞察訴求的手段一共有三種
第一種是從內部尋找訴求，和 CEO 簡單聊天可以了解戰略層；從 CTO 可以找到產品規劃和現有痛點；和業務聊可以知道產品現狀和業務訴求；和銷售聊可以明確產品的優劣勢及市場情況；和產研相幹人員聊可以知道現有產研難題等等。每個公司職能部門都有不同，我們可以通過實際工作、與相幹人員聊天，查閱公司資料，跨部門參加會議等手段，盡量豐富我們對公司的了解，從中挖取本職產品的定位和訴求，從而發覺設計的機會點。
第二種是針對用戶的定性調研。如果產品規模不大，我建議 6-8 名用戶即可，需要注意的是，問題需要包含全局層，也要圍繞核心任務，去挖掘訴求。
第三種是針對用戶的定量調研。我推薦使用阿裡平臺的易用性度量問卷，其本身結果與 NPS 成正相幹。但是其調研量非常少，只需幾十份有效問卷即可，而且調研問題圍繞易操作性、易見性和易學性展開，且問題固定。這大大降低了我們定量調研成本。定量調研主要用在產品改版前和改版後，來明確是否需要改版，改版後產品的大致情況如何，當然，定量調研也可以針對產品的某個核心任務。
在通過內部和外部的洞察後，我們需要完善用戶畫像，制作用戶任務地圖，明確用戶在任務和全局上的行為、痛點、訴求和接觸點。如果進行了定量調研，要依據其結果著重發現對應痛點在易用性上哪裡出現了問題。
3. 設計策略
產品設計人員需要根據訴求提煉出全局和每個「大」「主」任務的痛點，對於任務來說，所有任務一定是對應典型交互模式或者界面的，比如 B 端設計常見的權限類，一般就是保存型表單+列表的設計模式，訂單管理就是查詢型表單的設計模式，首頁一般是 Dashboard 的設計方式等等。每個設計師都應該有自己的武器庫，針對各種典型頁面有專業的手段，從而提出對應設計策略和解決流程。
4. 設計方案
這一部分就是常規UX和UI的工作了，需要注意的有兩點。
第一，就是設計手段，比如針對各種典型頁面的設計手段，比如降低表單龐雜度的設計手段，再比如表格的設計手段，每個人的工具箱都不一樣，但我建議每個設計師都有自己的工具箱。
第二，就是依據「小」任務進行任務梳理，產品的大部分組件/控件都是對應其喻體的，用戶之所以會操作產品，是因為組件/控件都是生活中的映射。比如 radio button 的喻體是收音機按鈕，收音機按鈕每次扭動，都對應獨立頻道，一個收音機不可能只有一個頻道而且轉動按鈕即時生效，所以 radio button 一定是以 group 的形式出現，並且立即生效。radio button 生效後是否能取消？在現實生活中其實是不能的，只能扭到另一個生效頻道，這又對應了組件/控件的行進策略。所以研究喻體是解決小「小」任務和提升基礎交互水平的手段。
方案設計後，如果是高頻且主要的任務，建議進行小範圍的可用性測試。
5. 設計驗證
我將設計驗證分為客觀和主觀層面的五點，分別是易用性、一致性、任務效率、任務完成率、咨詢/投訴量。
易用性是依據上文提到的易用性度量問卷完成；
一致性是依據一致性走查表，團隊走查完成；
任務效率是利用數據檢測任務完成時長得來，任務完成時長 = 拜訪結果頁的時間刻度 – 拜訪表單頁的時間刻度；
任務完成率是任務的完成情況，任務完成率 = 完成結果頁 PV / 新建結果頁 PV * 100%；
最後咨詢/投訴量的數據對比。
通過這 5 點，我們可以得出設計的驗證，從而判斷設計的合理性和價值。
四、結語
方法本身不是限制，只是為了讓工作更好的提效，讓產出結果有理有據，上文所說的設計師」工具箱「也是需要設計和產品慢慢積累的。依據任務的設計並不只是用於 B 端設計，了解任務的顆粒性一定會幫助你在今後的產品設計工作中能更深的刨析抽象，同時更好的建立抽象資訊之間的關係，為產品和用戶做出明確且具象的表達。就像我說的，設計師本身是翻譯者，將抽象翻譯為具象。
本文由 @JQ Design 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
>B 端設計｜以任務為核心的 BTSD 設計模型