B2B產品設計心得之二：莫忘初衷
第二篇關於B2B產品的心得我想聊聊「如何思考客戶與產品的互動」，雖然B2B和B2C產品兩者之間的差異主要是在商業模式而非產品設計，因此在產品或是體驗設計上大部分的概念還是相同的。
產品設計涉及的面向非常多，也會因為每間公司的文化或是開發流程而有很大的差異，這篇會比較像是在工作流程上的各個階段的心得記錄。
下面我會先介紹在點點簽產品團隊中產品設計師角色的定位，接下來再依照常見的雙鑽石模型（Double diamond）來作為架構，試著在不同的階段列舉一些我在進入B2B產品設計後遇過與思考過的問題。
本篇內容：
1. 基本的團隊組成與PD角色定位
2. 需求探索階段
3. 定義與設計階段
4. 開發階段
5. 交付階段
6. 最後，這篇的標題叫莫忘初衷
1. 基本的團隊組成與PD角色定位
目前我所在的產品團隊在開發時基本角色有：PM（Product Manager）、PD（Product Designer）、工程師（Developer）。
產品設計師（以下簡稱PD）在團隊中擔任的角色是Feature Owner，從需求探索開始，功能定義、細節設計、與工程師溝通、功能驗收到交付等，PD會一路扮演著把關品質的角色。
所以PD在開發過程中不同階段該做的事情大概是這樣子的：
- 在需求探索階段與最瞭解市場的前線戰士們合作，了解客戶需求與痛點。
- 進到定義與設計階段時會透過實驗與團隊溝通來建立對功能的掌握度與信心，並且確認好手上這支功能在產品中的價值。
- 開發階段提供盡可能完整的文件讓開發人員開發，一起討論與釐清不夠清楚的部分。
- 開發完成到交付市場之前把關品質，必要時會刪減掉可能產生風險的部分。
在我們團隊中文件是用PRD形式交付，團隊中所有的角色都會從PRD中得到所需的內容。關於PRD的架構與撰寫我曾經在Tom Liu的「猴子也會的PRD指南」中獲益良多，無論是有寫PRD經驗或無經驗的設計師都可以看看。2. 需求探索階段（Discover）
2–1. 市場的成熟度會改變
市場對新事物接受的速度比我們想像中快很多，比較日常的例子是：臺灣Podcast的收聽人數從2021至2022年成長幅度是200%，兩年前捷運上的人可能都是在聽喜愛的專輯音樂，而現在可能已經有一大部分的人在聽百靈果、股癌或是敏迪選讀Podcast。
而在B2B的市場也是如此，甚至可以說一旦市場確定了新事物可以帶來的價值後，後續就是用驚人的速度進入成熟階段。
以電子簽名所在的市場為例，在產品剛進入市場的初期，客戶詢問的問題還是相當大著重在：這個有法律效力嗎？會不會被竄改？可以拿來簽租賃契約嗎？…等，是屬於還在試探產品是否可行的階段。
而2019年的武漢肺炎疫情催生了電子簽名市場的快速成熟，客戶開始詢問的是：你們產品能不能滿足某某情境？競品有某某功能你們有嗎？能不能整合到特定的CRM系統？
所以，市場成熟度的不同除了銷售上的差異以外，也會帶來不同的需求與痛點。而以我目前的經驗看來，越成熟的市場客戶提出的需求會越複雜並且越細分產業。
2–2. 截然不同甚至完全相反的需求
在B2C產品的探索階段，經常可以利用實驗或是問卷來輔助決策設計方向，小從功能的預設項目大至整個功能價值的定位，但在B2B產品則很可能在這個階段找到截然不同甚至完全相反的需求。
舉一個我曾經遇過的例子，同樣是在面對面簽名的情境：A公司使用在公司訪客簽到表的情境而B公司則是用來簽署購課合約，這兩種情境中需不需要讓簽署人收到簽署完成的副本就產生了矛盾。A公司的訪客簽到表是公司內留存用，不希望每一位簽名的訪客都收到簽到表副本；B公司則是雙方合約，一定要讓客戶可以收到合約副本。
這樣的例子會在需求探索階段就不斷的出現，因為B2B產品的使用者是來自不同產業在不同情境下使用的不同角色，他們用我們的產品解決截然不同的問題。
3. 定義與設計階段（Define）
3–1. 製作積木與組裝積木
進入設計階段後，雖然大部分的設計思維是相同的，但我特別想提出來的差異是：在設計B2B產品時需要盡可能的讓功能與架構保持最大的彈性。
原因除了B2B產品本身經常是複雜且龐大的以外，與上一段提到的需求差異性也有很大的關聯。
龐大且複雜的產品該如何設計？我在這部分學習到的概念是：像堆積木一樣思考產品。
在每一次的設計規劃之前，先將裡面的各種元素想像成小積木，而這些小積木會用來拼湊成完整的功能。有時候可能是從產品裡面已經有的功能拔小積木過來用，有時候是製造新的小積木，而這些新的小積木未來也可以組合到其他的功能。
這概念很常在不同領域見到，例如前端的原子設計（Atomic Design）或是設計系統（Design System）。
承上段的的面對面簽名情境範例，可能的解法就會是把「要不要收到副本」做成小積木裝到面對面簽名這個功能裡面，讓客戶選擇在什麼情況下要收到而什麼情況不要收到。
堆積木的概念最大的目標是保持彈性與提升效率來適應不同客戶的需求與搭配各種環境。當然我想這也可能是造就了為什麼B2B產品看起來總是一堆開關與設定的元兇之一。XD
3–2. 利用各種資源來建立信心
我在剛進入B2B產品設計時首先遇到的最大難題是：「我發現我對使用者一無所知」。不像B2C產品容易找到使用者進行訪談或資料搜集，甚至也有很多使用者情境與我自身的經驗相近所以可以利用直覺來進行判斷，B2B的使用者像是躲在非常遙遠的深處，很難接觸得到更難得知他們的想法。
但就算真的找到了實際使用者想進行訪談，在追求迭代與速度的團隊中我覺得我又遇到了第二個難題：「我好像沒有時間進行研究或是訪談耶…」。
在初期這兩個難題深深困擾著我，因為在設計沒有經過驗證的狀況下會讓自己對規劃出來的內容沒有信心。客戶真的會這樣使用嗎？怎麼樣的體驗才是更好的呢？
後來在讀了Inspired還有和身邊前輩討論後，我重新思考並且整理了幾種在現有的B2B產品和開發節奏下可以用來增加信心的方式：「借助內部資源」和「簡單快速的測試」。
「借助內部資源」意思是善用身邊同事的專業。在設計過程我最常做的是先和「前線戰士」們聊聊手邊客戶的需求和情境。不只是平鋪直述的說客戶想要什麼，而是進一步詢問客戶在使用產品時，「誰？」「在哪裡？」「做什麼事情？」，通常和負責不同客戶的前線聊過後，已經可以整理出七八成的客戶樣貌，也會對設計更有信心。
「簡單快速的測試」意思是縮小測試規模。在UX的專業訓練中我們已經很習慣把研究規劃的嚴謹，當然嚴謹的研究很棒，也可以得到更有信效度的結果，但是在追求快速迭代的開發節奏裡面不一定有時間讓研究可以追求嚴謹追求完整的跑完。
所以我們嘗試利用「減少受測人數」或是「請身邊對產品不熟悉或是與目標使用者背景相似的同事協助測試來取代招募外部受測者」等方式來縮小測試規模。以A/B Testing為例，通常可以把時間縮減到半天就完成。這樣的測試雖然沒辦法像正式研究一樣嚴謹，但是對於某些影響產品範圍比較小的功能來說已經足夠。
無論是「借助內部資源」還是「簡單快速的測試」都是可以用來建立對自己設計規劃信心的方式，可以根據會影響產品的範圍來調整測試的嚴謹程度。例如比較小的外部功能就可以找三五個同事進行簡單的訪談或測試即可；但是如果是新的架構要建立，可能會影響大部分的其他功能的話就還是需要時間規劃相對嚴謹的訪談或是測試，這中間的彈性就由設計師依情況調整吧。
4. 開發階段（Develope）
4–1. 細節！細節！細節！
由於我不是一個記憶力非常好的人，以前把設計規劃交給工程實作時很常出現漏東漏西需要來回修補的東西（RD大大們對不起 QAQ）：「如果執行失敗要顯示什麼文案？」「如果是沒有訂閱的使用者會是什麼流程？」「還沒建立內容的空狀態是什麼？要預設值嗎？」。
通常如果已經進到開發階段才發現交出的設計有缺漏時，壓力會非常大，而在這樣的狀態下很容易做出補洞的決策：「先想個提示文案直接上吧！」「先快速給個空狀態的圖吧！」「如果沒訂閱那就把入口拔掉吧！」時間一久產品中的設計債或技術債就越積越多了。
當然在年紀漸大的情況下要提升記憶力應該是不太可能了 QQ， 尤其B2B產品經常牽涉到多種權限和多種付費方案的交互細節，在記憶力不可靠的情況下，我們想到的解決方法是把工作「模板化」。
前面所提到的PRD就是模板化的實現方式之一，我們把每一次功能規劃需要考量的細節都先建立在PRD模板中，例如：「影響哪些訂閱方案？」「影響哪些平台服務？」「哪些權限可以使用這個功能？」「沒有權限時怎麼顯示？」…等。
而每一次交給RD實作後，如果還是有缺漏的細節，就會再補上模板來避免下一次規劃再次缺漏，來回個幾次後就可以盡可能地避免掉補洞決策的問題了。
4–2. 敏捷！敏捷？
我其實並沒有待過很標準的敏捷團隊，即使是現在的也不算是。只是在B2B的環境中，我感覺快速的迭代、漸進和進化是產品團隊能夠輔助前線戰士們方式之一。
前線戰士們背負著成交的壓力和客戶不斷提出需求的壓力，但如同需求探索階段所說，不同客戶甚至會提出完全相反的需求，因此我們不太可能每一個需求都花費一兩個月的時間探索再花費半年的時間開發出完全符合客戶期待的功能。
因此快速的迭代就會是產品團隊可以提供前線戰士們與客戶討論的籌碼。
但是快速迭代不代表在設計期間只做半套就交給RD進行開發，然後丟下一句：「我們看看市場反應再說囉。」通常這會有兩種下場：一是不小心淹沒在後面排著隊的其他需求之中；二是一開始沒想清楚，結果收到市場回饋後發現要打掉重練。
我的做法是在規劃提案時盡可能的確認痛點情境的完整性，但是在設計提案時保留RD開發時可以依照時程與重要度進行切分。
假設完整解決客戶某個痛點總共需要A.B.C三個小積木來組合而成，但是為了維持開發節奏我會先將A.B.C三個小積木依照重要程度簡單分級，例如：A-Must、B-Nice to have、C-Nice to have。
交由RD評估時請他們評估在預計的時程內，如果A必做的狀況下他們可以做到多少？而這次時間內沒做的再依照重要程度留到下次或是達到預期的市場反應後再發動來完成。
再舉個小小的範例：點點簽中有個「欄位驗證」功能是可以在簽署人填寫欄位內容時先依照發文者的要求來驗證簽署人填寫的內容是否符合規定，例如：發文者要求該欄位要填寫Email，則簽署人填寫時如果欄位內沒有包含@就會先提示錯誤且無法送出任務。
在規劃這個功能的初期，整個完整的設計會包含「視覺錯誤提示」、「提示文字」和「讓發文者自定提示文字」，但是由於開發時間所以我們先只實作了視覺提示就先上線了。後來確實在客戶使用後有直接的需要提示文字的需求回饋回來，這時我們就可以再利用比較小負擔的優化再上一個版本，不會滾動到要重新規劃，RD也已經在最初先保留好彈性可以快速的迭代。
這樣的做法可以保持設計規劃的完整性，也不會因為為了等市場反應而掉棒。在開發的合作上，也能夠讓RD一開始就清楚未來走向來讓開發保持足夠的彈性。
5. 交付階段（Deliver）
5–1. 驗收心得：減法
一旦開始進入到設計規劃與開發後，在不同的階段我們考慮的重點都會有點不同：
- 在「定義與設計階段」我考慮的是體驗的完整性和規劃的內容在整個產品的架構內能不能足夠應付未來的擴充與彈性。
- 在「開發階段」我考慮的是如何配合RD的開發節奏，將最完整的規劃拆分成小積木來維持開發速度。
那到了交付階段，「風險」會被納入考量的重點，這邊所說的風險其實範圍很廣，像是延遲交付的風險、體驗不佳的風險、系統出問題的風險等等。
所以在交付階段，設計師除了進來驗收RD實作的成果有沒有符合原先規劃要解決的痛點以外，可能會出現一些需要決策的狀況，例如：「原先規劃要完成的部分沒辦法如期完成，該延期上線還是先以現在的版本上線？」「缺少了某個情況的規劃，要在現在再花時間補上嗎？」。
到了交付階段可能出現的問題非常五花八門，很難有個標準做法來應付所有的情況，但是到這個階段我在決策時會以評估風險來當主要依據，例如：如果功能壞掉的風險會大於延遲上線帶來的風險，那我會選擇和PM討論上線時間能不能延後；但是如果延遲上線可能帶來的風險大於體驗不佳的風險，那我就會選擇犧牲目前版本的體驗。
To be, or not to be, that is the question.
6. 最後，這篇的標題叫莫忘初衷
最後，雖然前面是說要介紹B2B產品在設計時要考慮到的差異，但回歸到設計目標，無論是B2B或B2C產品，設計的出發點都是滿足使用者的需求。（是不是被我騙進來了？抱歉>_^）
而B2B產品是滿足使用者「業務上」的需求。
雖然使用者通常會因為過於習慣於他們現有的工作流程和工具，以至於很難表達他們真正想要什麼。直接詢問使用者的話他們可能會向團隊提出功能上的需求：「我要可以管理成員能不能下載檔案。」、「我要增加上傳圖片的功能。」，但很難直接從使用者口中的需求找到產品長期發展或是創新的方向。
回過頭來思考一下，那自己在工作上的目標是什麼呢？除了希望有效率的完成工作以外，我自己還考慮過職涯發展、專業領域以及跨領域的學習還有團隊成功等等。同樣的，面對B2B使用者時是不是也可以進一步思考產品之外他們在工作和職業上的需求是什麼？
進一步了解使用者在整個工作情境中的需求以及痛點，並為產品在未來可以做什麼來解決這些痛點繪製一條路徑，對於設計師來說，真正了解使用者的長期目標是什麼，就可以多很多可以做的事情。
好了，先寫到這邊。歡迎所有的回饋與討論，讓我有動力可以寫下一篇啦。
