為什么大廠高手都說「設計推理」是B端設計師的核心能力？

前言

幾年前從 ToC 轉到 ToB 時，請教了幾位前輩 “什么是 B 端設計師的核心能力”，得到回答最多的是設計推理能力。但有時花了很長一段時間，把方案背景、設計推理過程打磨得“天衣無縫”，結果方案一拿出來，就被劈頭蓋臉的問題問到懷疑人生。我開始思考，通過邏輯自洽的推理，究竟能不能做出好設計？如果不能，怎么做才能更好？

拓展閱讀

設計推理是什么

設計之所以需要推理，是為了讓我們在面臨復雜的情況時能更好地決策，推理本身是從已知的命題得出新命題的思維過程 ，已知命題是前提，新命題是結論。推理最常見的方法是三段論，舉個例子：所有的植物都需要陽光，所有的向日葵都是植物，所以，所有的向日葵都需要陽光。

在工作中，我也經常用上述的三段論推理，比如，在為騰訊云金融遠程風控平臺定位設計關鍵詞時，推理的邏輯是：所有和金融類產品的體驗關鍵詞都是安全，遠程風控類產品是金融產品，所以，遠程風控平臺需要安全感的設計。再比如，我們在手機銀行適老化設計中，給了客戶更大字體+切換入口的方案。推演邏輯也同樣是三段論：大字號能幫助老人識別信息，手機銀行需要服務老年群體，所以，手機銀行適老版應該采用大字號的設計。

自洽的設計關鍵詞推理

1. 自洽的推理未必合理

上面兩個案例的邏輯看上去沒有問題，但結合實際場景，遠程風控平臺是給坐席端和盡調員使用的，盡調工作由原先兩人一同前往客戶現場變成了一人坐鎮后臺指揮另一人在客戶現場用手機取材，這樣的轉變對產品 1.0 階段體驗要求應當是“低門檻好上手，方便客戶工作習慣的遷移”。而手機銀行適老版同樣，如果我們在信息架構已經非常復雜的手機銀行中，做了切換版本的設計，老年人能否找得到，找到了是否愿意用，都是問題。

銀行適老化設計案例：

邏輯自洽的結論，問題出在哪兒。我之前聽到一門課上，老師講到“邏輯自洽的設計并不一定是好的設計”，如果我們仔細推敲由這些邏輯推導出的結論，其實就會發現有問題。

究其原因，本質是一種復雜問題謬誤。即在一個推理的前提中，悄悄地置入自己的傾向，甚至結論，這本身就是一種邏輯謬誤。比如當問起“你為什么不喜歡張三？”，就包含了不喜歡張三的前提。

同樣，“金融類的產品要為用戶營造安全感”，這里已經包含了“金融產品必須為用戶營造安全感”的結論，但為什么是安全感？并沒有做出解答。 這就導致了后續的推理過程，實際上是在一個錯誤的前提下進行的。

2. 三個思維為你的推理加持

怎么做可以讓推理變得更嚴謹？我們可以嘗試跳出現有的思維方式，用另一個視角對推理的合理性進行思考。這就涉及到三個思維方式：批判性思維、結構化思維和故事化思維。

從另一個角度看待推理的合理性

• 批判性思維讓推理更嚴謹
• 結構化思維讓推理更系統
• 故事化思維讓推理容易接受

我們用這三種思維重新審視前文提到的“遠程風控”和“適老版”的設計方案，在遠程風控項目中，我們用批判性思維推導出一期的發力點應當在線下盡調習慣的遷移，方便前后端盡調員更容易配合，從這個目標，最終提供了打標記和盡調 SOP 的體驗：

盡調 SOP 體驗

在適老化虛擬營業廳項目中，我們通過結構化思維，對手機銀行的項目進行反思，跳出來加入了普適性設計原則，從而最終為老人用戶做了無感的版本切換，并在辦理中提供了家人幫忙辦和直觀的驗證指引體驗：

適老化的虛擬營業廳

用批判性思維讓推理方式更嚴謹

1. 批判性思維是什么

首先我們要先明確一個概念，批判性思維與邏輯推理的關系。

前文在金融項目中的舉例，是以演繹的思維方式，推導出設計發力點，我們可以嘗試從他人視角來關注這種思維的局限。當我們向他人呈現出這種方法時，你會發現對方會關注：你的思路是否充分，是否具備了足夠的前提和背景，是否定位到了真實的用戶并精準抓住了體驗需求，在競品的總結上是否有普適性。對方更關注的是邏輯推導本身的充分性。

但批判性思維不同，批判思維不是邏輯推導，而是 argument，就是跳出來看怎樣進行論證是有意義的，怎樣推理是更合理的。如果說邏輯推演是過程，那批判性思維更像是一個篩子，幫助我們篩掉一些糟糕的論證。換句話說，批判性思維就是一種針對思考過程的思考。

之所以設計師需要用批判性思維來看待推理過程，本質上是通過完整的思考，讓方案更加健壯，因此完整的思考=論題+論證+結論。如果我們希望進一步加強推理能力，就需要能夠找到思考過程本身的爭議之處，也就是重新定義論題所在，然后通過更多元的論證，找到真正的結論。

批判性思維

2. 使用批判性思維讓推理更嚴謹

重新定義論題

前文提到了三個關鍵詞，論題、論證和結論。我們要先搞清楚各自的定義，首先是論題，尼爾布朗的《學會提問》里，將論題總結成了以下兩種：

• 描述型論題。這類論題是在描述一種存在方式，比較客觀，不受主觀情緒影響。例如：減少轉賬流程中的點擊次數是不是有助于提高用戶的使用效率？
• 規定型論題。這類論題提出了什么是對的，什么是錯的，受主觀情緒影響。例如：在用戶使用金融開發工具完成一項任務后，是不是應該有個慶祝的反饋來提升用戶體驗？

在與同事的合作中，當你直接問：“這樣設計究竟想解決什么問題”試圖找到論題時，多數情況對方的答案并不能說服你，或者對方無法給你準確的答案。因為在現實生活中，無論是哪種論題，往往無法點明，需要自己尋找。此時，需要設計師自己重新定義論題。有一些方法，例如了解對方的背景，對方所處的組織架構，了解組織對他提出了什么要求。以及你的產品當下面臨的階段萌芽期、成長期、發展期還是平緩期等等。這些方法中，比較常用的是拔高一層找論題。

舉個例子，當設計師拋出方案后，經常會面臨這樣的問題：“這里的細節 xxx，你這樣設計的目的是什么？”如果不去重新定義論題，就會陷入直接拿結論討論的過程，即：我使用了某某專業方法做了這樣的設計。討論到最后，就會演變成，設計師說：“我認為這里沒必要。”對方回：“我認為這里有必要。” 這種無意義的爭執中。核心的原因就是你沒有定位到對方真正想要與你討論的論題，不在正確的方向上，就會導致無疾而終。

找到論題后再討論

實際上，無論是客戶還是老板提出這個問題時，更多的是需要我們拔高一層去找到真正的論題：

1. 這樣設計有沒有提升商業目標、產品目標 -商業目標型論題
2. 是否定位到了真正的用戶以及他們的訴求 - 用戶需求型論題
3. 研發實現成本如何/當下人力是否能實現這個設計 - ROI 型論題
4. 執行層面是否優化一下能有更好的方案 - 方案優化型論題

通常來說，內部的合作團隊例如產品、研發更關注的是 1、3、4，外部客戶更關注的是 1、2。展開來講，比如 1，論題就是這樣設計的，本質上是為了提升用戶轉化、DAU，還是你單純覺得有趣才這樣設計的。再比如 2，指的是你這樣設計是從滿足你自己的需求出發的，還會有真正了解過目標群體，為他們的痛點設計的。

找到論題之后，就有了有效討論的前提。下一步就是去尋求更多元的論證，關于論證層面所使用的到的思維，會在下面即將提到的結構化思維部分中，我們稍后來討論。假設我們找到了論題，并且擁有了合理的論證，下一步就是要找到對方真正的結論。

尋找真正的結論

要找到結論是什么，要先明確對方拋出來的是結論還是觀點。結論是推理出來的，需要一個個觀點支撐，如果對方斷言某件事是真實的，卻沒有提供相應的陳述來支撐，可以說這個是觀點，反之則可以是結論。

觀點和結論

按照結論做設計，會比按照觀點做設計更加精準。

以助農網點項目中遇到的問題舉例，當時我們接到一個反饋是：“小程序里每個模塊跳轉不要太多，最好不要超過 3 層，否則會讓頁面顯得很復雜。”這就是一個明顯的觀點，因為其沒有相關的支撐。經過討論，我們重新組織了這個需求，找到了真正的結論：“小程序里每個模塊跳轉不要太多，最好不要超過 3 層，因為客戶經理每天需要并行的業務較多，加上小程序已有的功能超過了 30 項，所以希望體驗上能更加輕量。” 這樣的結論讓我們在最終的設計上，提供了數據導向的框架+穿梭窗的設計，確保客戶經理打開小程序時以及使用功能中，能夠不被復雜的信息架構和流程所擾。

從觀點出發的思路

從結論出發的思路

從結論出發給出解決方案

設計師在平時推導結論的過程中，可以關注以下關鍵詞：因此、表明、由此可知、由此得出、因此可以判定、顯示出、證明、告訴我們、問題的實質是等，這些關鍵詞更加貼近結論。

當然，也要注意避免一些常見錯誤，例如

• “我之前的經驗看客戶經理應該這么想”- 偏概全謬誤
• “抖音設計了沉浸式上下滑動的體驗非常成功，所以這種極簡的體驗是能幫助產品成功的” - 典型案例謬誤
• “很多設計大師都講少即是多，所以這種設計理念也應該被應用在產品中” - 當事人證言謬誤

謹防數據的謬誤

有一個謬誤值得大家關注，就是數據謬誤，我在工作中也經常會犯這樣的錯誤，當你希望通過數據來佐證設計是否合理時，就可能被數據繞進去，總結起來有以下幾種：

批判性思維-數據的謬誤

不明來歷的數據

例如：40%的用戶打開銀行 App 時，只使用了轉賬和查明細 2 項功能。

在設計手機銀行的信息架構時，堅定地相信了這項數據。但如果仔細思考，你會懷疑：給出數據的人是如何得出這個數據的？這里的樣本量是多少？統計的用戶畫像是什么？多少人是高頻用戶？等等。不明來歷的數字也會容易將我們帶跑偏。

平均值與中位數的混淆

例如：使用我們產品用戶平均年收入在 200 萬以上，所以品牌調性可以盡量往高端定位。

這里使用到了平均這個詞，但實際上卻有三種不同的方法來測定平均值。

• 第一種方法就是把所有數值相加，然后用總數去除，得出的結果就是平均數。
• 第二種方法是將所有的數值排序，找到位于最中間的數值，這個中間數值就是中位數。
• 第三種方法是統計每個不同數值（或一個數值范圍）出現的頻次，出現頻率最高的叫眾數。

上面的案例采用了平均數的計算方法，將高端用戶一并算入其中，這樣會拉高平均數，而對于我們真正希望抓住的目標用戶，也就是占比較多眾數而言，影響卻不大。

用 A 的結論證明 B

舉個我們在遠程風控產品調研中遇到的例子：作為盡調員，需要判斷借款公司的資質是否與其提供的一致，當現場盡調時，十有八九拿到的報告數據都與實際有偏差。我們之前統計過，因為數據偏差導致最終額度批準過高的概率是 n%。無論這個數據多高，都只證明了一件事，即多數盡調員首次現場收集的數據都不準確。但不能推導出額度批準過高，是由數據偏差導致的。要回答這個問題，可以問：“批準額度的整體流程是什么，除了報告數據，是否還有其他的因素導致這個結果？”進而找到 B 真正的結論。

絕對數值的欺騙

例如：之前問朋友對老家鄭州這幾年變化的印象，經常得到的一個答案是越來越像文化荒漠了。我繼續問為什么？有位朋友的答案很有意思：“比如啊，城市不斷有新公司出現，把市區里的那種人文氣息趕跑了。就在去年，城里的公司數目增長了 75%。”75%很吸引眼球，但是這里缺少了一些東西：百分比所依據的絕對數值。假如我們知道這種增長是從 4 家到 7 家，而不是 12 家到 21 家，就會對結果有所改觀。

以上就是我對批判性思維的理解，借助它可以讓我們已有的推理邏輯變得更強。

用結構化思維讓推理方式更系統

1. 為什么要用結構化思維

先搞清楚結構化思維的定義。回到文章開頭的案例：所有的老人隨著年齡增長，都會出現視力下降的癥狀，所有的產品都做了放大字體切換版本的設計，所以，所有的適老版設計都是放大的設計。

在這個案例中我發現，當我開始設計前，會習慣性地使用演繹法，來定位設計機會點，似乎有一個思維定式讓我不由自主地想去使用它，這是為什么？

我在加里·梅哈爾的猴子定律中找到了原因，將 5 只猴子放在 1 個籠子里，并在籠子中間吊上一串香蕉，只要有猴子伸手去拿，就拿高壓水槍教訓所有的猴子，直到沒有猴子敢動手。此時，當實驗人員用一只新猴子來替換籠里的猴子時，這只猴子就想伸手去拿香蕉，結果被其他 4 只一頓 K。實驗人員替換了幾次，猴子發現不去拿香蕉就不會被噴，感受到了這個規矩的好處，于是這里形成了一種”不許拿香蕉“的思維方式。

我們起初參加工作時，腦子里帶著一堆的思維方式進入職場，在多次的摔打后，形成了一種有效的思維方式，然后會不斷用這種方式處理大部分信息，將這種思維方式本身帶來的紅利最大化。這也就是為什么，當我開展設計時，通常都會習慣用演繹法來推理設計目標。這個過程看似是一種推理，實際上也是一種固化的思維方式，如果我們希望在推理中變得更強，就需要掌握多種思維方式，在不同的情境中靈活運用。

2. 怎么使用結構化思維豐富推理方式

如果進一步定義，結構化思維=多種思考有序地搭配或排列組合，所形成的一套推理系統。

之前我在做手機銀行項目時請教過一位用研大咖：可用性測試的樣本有限，如何確保結論的可靠性？他的回答是：不要只把目標聚焦在手機銀行用戶，可以擴大樣本到業務經理。其實這個就是結構化思維，通過擴大樣本量對結果做交叉驗證，確保結論的有效性。不只單一固定的某種推理方式，而是將多種思考推理系統地搭配使用。

結構化思維

我們曾參與過一款項目金融開發平臺，主要是幫助銀行等金融機構開發移動 App。按照推理，我們將設計目標定位在了如何帶給用戶安全感。除了用演繹推導之外，我們還嘗試了工單分析進行交叉驗證，來重新定位客戶所關注的是不是安全。分析過去 1 年的工單，將工單類型做歸類，就會發現功能數據報表的全面性、幫助文檔的易用性、功能說明的簡單性，這些都是客戶關注的問題，并非簡單的安全感，為此我們提供了相應的設計方案。

產品的易用性設計

除了工單分析之外，有很多種方法例如第一性原理、客戶體驗地圖、客戶轉化地圖、SWOT 等，這里就不展開細講。重點是當我們在推理時，要使用結構化思維讓推理結論變得更加健壯。

但到了這里，仍然有一個困擾我的問題，要用更多的方法來佐證推理，那么方法有很多，像演繹、歸納、體驗地圖等，但這些方法在真正的實戰中，更像是一個個零散的點，他們之間的關系是什么？怎么形成一種結構？

3. 結構化思維的結構

其實總結來看，歸納和演繹是認識事物的方法，當你認識事物后，金字塔模型就是你思考問題的思維結構，但光有了結構還不行，需要結合不同的場景運用，這些具體的運用，就是我們經常提到的客戶轉化地圖、流程思維、故事思維等。就是說，當我們掌握了歸納和演繹以及金字塔模型后，可以自己生長出很多上層思維運用。

思維結構

關于這幾個思維模型在設計項目中的運用，后續也會單獨開一篇《用推理為設計加持-思維模型運用》來和大家討論。確保思維的完整性可以用 MECE 法檢查，即各個要素之間不能有交叉，也不能有遺漏，相互獨立，完全窮盡。

產品思維介紹：

例如：用戶不使用，可以拆解為外部原因、內部原因，外部原因可以接續拆解為環境、手機、App 性能；內部原因可以繼續拆解為需求未滿足、覺得產品 low。

這樣去拆解，你就可以從一個更加全面的維度去審視推理過程。

用故事化思維讓推理容易接受

對于 B 端設計師來說，設計的對象由 C 變成 B，由內部產品團隊變為外部客戶，外部客戶在對方領域是專家，但由于工作經歷、行業的差異，大多數客戶很難坐下來，像內部團隊一樣開需求評審會，花時間聽你的分析邏輯，我們可以通過故事化思維，把你的邏輯更有效地讓對方接受。

1. 故事化的思維是什么

要向不同知識背景的客戶闡述你的設計推理，就需要將枯燥、理性的推理轉變成對方可以接受的形式 ，也就是我們經常說到的“提案”。

2. 怎么使用故事化思維讓推理更易接受

什么才是客戶能接受的方式？首先，我們的大腦都是親近清晰而疏遠含糊的。故事，就是把復雜的信息安排地井然有序，從而讓大腦更好地接受。那具體應該怎么做，ToC 和 ToB 的環境差異較大，這里以 ToB 面對客戶的場景舉例。基礎邏輯可以分為以下幾步：

故事化思維框架

1. 立一個主人公；
2. 主人公遭遇了一個問題；
3. 此時向導出現了；
4. 為主人公提供一套方案；
5. 幫他避免失敗；
6. 最終獲得成功；
7. 召喚他采取行動；

例如我們在和幾個客戶的提案中，從開始即定位成客戶為本次的故事的主人公（1），在 PPT 的第 2 頁就直接亮出問題（2），隨即就講在解決這個問題中，騰訊能帶來什么，扮演的角色是什么（3），接下來就是方案（4），方案講解完畢后，另起了一趴去講在過程中可能會遇到的風險以及我們如何規避（5），在結束前，將最終合作后所帶來的效益與客戶同步（6），最后，引導客戶采取下一步行動（7）。最終的效果都很不錯，成功地拿到了合作。

這里在過程中要注意幾個問題：

• 精準定位客戶遭遇的問題。說服的有效性取決于（2），主人公遭遇的問題其實要在一開始就定位清楚。設想一下，如果你對一個客戶提案，前 5 分鐘連對方的問題是什么都沒有精準定位，那剩下的時間基本就是災難了。作為設計師，我們可以通過售前反饋、市場報告、用戶問卷/訪談、競品分析等方法，確保我們定位的問題是精準的。
• 我們扮演的角色是向導而非主人公。主人公式的表述會導致客戶缺少參與感，從而最終導致合作失敗。所以要注意我們的定位是向導，而非主人公。
• 在結尾要引導客戶采取行動。闡述方案后要有明確的下一步計劃，拋一個合作的方式，引導客戶采取行動而不是僅僅是停留在方案交流。

總結

批判性思維、結構化思維、故事化思維，這三者在設計推理過程中必不可少，在有限的時間里，設計師可以關注故事化思維，確保推理過程能有效地傳遞。在平時項目之余，可以多關注結構化思維，搭建自己的思維彈藥庫，項目緊張時可以拿出來使用。在項目進程中，當你推理出一個設計發力點時，也可以嘗試使用批判性思維，跳出來對思考過程進行思考。

本文沒有觸及推理本身，而是希望能換一個視角，對推理過程進行思考。設計推理是一個長期的命題，也是構成設計師核心價值的底層能力之一，里面的課題還有很多，本篇作為一個開端，后續也希望能繼續完成這一系列

• 《用推理為設計加持》（本文）
• 《思維模型運用》
• 《故事化的迷人之處》

以上內容僅為我作為 ToB 交互設計師這幾年的思考，如有謬誤歡迎指正探討，也希望能和更多同學共同探索，一并前行。

參考資料

1. M Neil Browne and Keeley, S.M. (1981). Asking the right questions. Englewood Cliffs, N.J.: Prentice-Hall.
2. Miller, D. (2017). Building a storybrand : clarify your message so customers will listen. New York: Harpercollins Leadership, An Imprint Of Harpercollins.
3. 葉修(2020). 學習的邏輯 . 中信出版社
4. Page, S.E. (2018). The model thinker : what you need to know to make data work for you. New York: Basic Books.
5. Sherwin, D. (2012). Success by design : the essential business reference for designers. Cincinnati, Ohio: How Design ; Newton Abbot.7
6. 張建軍, 2014. 邏輯學導論 , 中國人民大學出版社.

歡迎關注作者微信公眾號：「騰訊設計族」