7000字干貨！教你用解構思維搞定B端需求設計

什么是設計中的解構思維，解構思維怎么產生價值？本章結合 B 端場景進行了應用解讀，通過對組件深入的解構理解以及對業務需求的解構設計，示意解構思維如何來解決 B 端業務需求和組件運用的問題，反映了解構思維的運作模型與價值體現。

往期干貨：

一、設計中的解構思維（解釋解構）

1. 廣義的解構思維是什么

“解構”一詞富有哲學色彩，早期的出現是哲學家雅克·德里達不滿西方幾千年來的傳統哲學思想，而提出的一種批判方法，是指對一切存在事物或現象的原因及本源研究，得出的穩定結構及其中心進行消解，每一次解構都表現為結構的中斷、分裂或解體，但是每一次解構的結果又都是產生新的結構。解構具有消除二元對立、打破固有傳統、去中心化、多元開放、包容差異等特點，對當下世界的多元化包容性都帶來不小影響。

而其思想內涵也在不同行業中生根發芽，在服裝、建筑、平面、影視行業中處處可見解構，以此為根源，20 世紀 80 年代“解構主義”作為一種設計風格的探索開始興起，解構主義用分解的觀念，強調打碎，疊加，重組，重視個體，不見本身，反對中心化或總體統一而帶來的支離破碎和不確定性（例如膚色階級的種族歧視、早期重男輕女封建思想等）。

如何理解呢？“解”有分解、拆解、理解的意思，而“構”具有結構、構造的意思，字面意思就是對事物的內容結構進行剖析。通常解構被認為是對傳統認知里的結構進行質疑和破碎重組，并建立具有新意義的結構。例如你一天放了 7 個不同聲音的屁，通過解構，我聽到的不再是屁，而是音符，經過譜曲，我成就了一首<別致的 Beat>。好的翻譯也可以視為解構，這個過程就是譯者對本質含義進行理解并使用新的語言結構釋義，其表達的本質沒有變，卻擁有了更為生動明了的譯文。

2. 體驗設計中的解構思維

一般結構形成表象，表象反應本質，但需求的構成是由其他本質推動的，這些本質既能形成 A 結構，就必定能造就 B 結構，所以解構主義不認為結構與表象能代表本質，設計中解構思維可以幫助我們跳出傳統的條條框框，就好像在說時代變了，你那套不行了。

體驗設計的范疇中，我將解構思維簡單概括為：不停留于結構表象，敢于質疑、深入本質，再創結構，是一種打破設計相關秩序然后再創造更為合理秩序的思維主義，是對本質的深入與多元化的理解，而體驗設計中的本質常常是以需求作為出發點，以用戶和場景作為合理性的準則，以解構出具有體驗或商業價值的方案。

一把舒適的椅子如何設計，從人體工學椅子到懶人沙發，依舊是一個不錯的解構案例，原來舒適的椅子可以這樣。

3. 解構與拆解、原子理論的區別

拆解是對某個事物按照一定邏輯或結構進行分解拆除，目的是獲取更全面或更深入的信息與理解，從而加深對本質的理解，拆解并不影響事物本身的結構或中心，而解構主義則是出于對結構或中心的質疑展開的，并試圖找到新的側重點或視角來理解本質，目的就是建立具有意義的新結構，同時在建構的過程中，還會用到更替、融入、結合、間離等手法，而并非是線性的拆解組合，在體驗設計的應用中，我認為解構有益于深入研究，以及跳脫競品或傳統結構設計的思維局限。

原子理論在 B 端組件系統中有深入的應用，像搭積木一樣，重心是找到可以復用的最小單元，然后利用這些單元組裝出更復雜更龐大的結構體，并且對這些單元的資源進行重復性利用，以減少生產過程中帶來的資產冗余、不一致、低效率等核心問題。側重點是交互層與功能邏輯，是一種工具化、模塊化的思維，主要是業務解構后進行 B 端交互頁面搭建的工具。

但是在傳統 B 端業務設計的背景下，解構思維可以配合業務情況對組件傳統的“組織”及以上的結構進行破壞重組，以誕生新的結構并更好契合業務。

二、再說說 B 端組件系統（解構對象）

1. 組件系統的誕生背景

B 端向來是以業務操作為主，而在繁瑣的操作過程中，盡管界面或場景不同，但是有很多操作行為或操作內容具備較高的一致性，為了減少對應資源的反復設計與開發帶來的時間浪費與資源冗余，這些對應常見的交互組件被系統化了，同時在不斷探索更基礎或高頻率通用的組件單元，以便后續的研發設計中可以隨時調用，于是組件系統誕生了。

2. 組件系統的核心價值

從內部研發視角來看，已經提到的減少資源冗余與效率問題便是核心價值了，從界面設計與品牌調性來看，使得產品樣貌與操作更為統一規范，便于資源管控。

而從外部視角來看，一套開源的設計系統還能賦予生態上的改變，一套基礎完善的 B 端組件系統可以支撐內部龐大的業務的同時，也可以賦予友商或幫助其他小微企業研發中后臺，對于業務生態、研發生態都有好處，收獲口碑的同時，是一種文化價值傳遞，也是影響力的滲透。

3. 什么時候搭 B 端組件系統

從技術難度工作量以及研發周期來看，顯然不能短期獲取回報，往往只能在業務生態需求量大、涉獵業務復雜或是發展迅速才有較好的價值體現，當然了不差錢為行業生態做貢獻也可以啊，盡管如此但也不是說不建議設計組件系統，具體也要看研發背景與組件系統搭建程度；

① 研發背景參考要素

大部分中小型企業，業務不是特別復雜，研發資源很有限，那就直接考慮開源組件系統好了，用現成的真的便捷太多，并且也不會涉及到到數據安全的問題。如果要搭建組件系統，那就需要考慮自身研發資源(時間、人力、成本)硬不硬，然后就是業務復雜程度是否大多開源的不能輕易滿足，這兩點很重要。

② 組件搭建程度情況

第一層實現設計產出加工件：

借助 Sketch、Figma 等主流 UI 設計軟件搭建界面常用的組件庫，用于內部設計資源流通，快速搭建 UI 界面，保證界面組件統一性和效率保障，搭建起步不要考慮全面，先從最基礎最常用的開始搭建。

第二層沉淀對應代碼庫：

設計師有了可復用的設計組件還是比較初步的，重要的是研發工程師對可復用的組件開始沉淀，并建立資源庫，研發過程中可能會伴隨業務需求一起完善，對于已研發的組件可以同步記載完善交互，然后規劃版本逐步完善。

第三層設計代碼一體化：

設計與研發的組件完成版本一致，實現組件從視覺效果到交互效果反饋完整，狀態齊全，引入即用，實現真正意義上的組件系統。

③ 進行系統二開維護

基于業務情況與開源組件系統進行二次開發，來建立沉淀自家的組件系統，如果這么做首先考慮的還是研發背景情況，進行二開可以節省不少時間，并且可以有更多差異化定制化的空間，需要注意的是目標二開系統的靈活性、擴展性等核心問題。

三、用解構思維深度理解組件（開始表演）

1. 從表象到數據背后

我們通過 B 端中后臺的表象開始解構，映入眼簾的往往是各種功能的導航、操作入口、信息反饋，很清晰很明了，各種操作都被組件結構所包攬并示意。

似乎已經看到了組件的作用，但又好像看見的還不夠，我們再次深入，組件的背后是便于操作，而操作的背后是什么，似乎很接近了，我們結合界面交互的構成結構換個視角看問題，如果沒有這些組件，任務還能進行嗎？顯然具備代碼能力是可以的（畢竟有些開發天天就是對數據 CRUD，不理解就問研發 [手動狗頭]），那么現在看來組件的作用就清晰明了呢，“組件是提供間接的代碼操作工具，便于我們通過界面交互來控制代碼數據的交互，幫助減少操作的門檻與理解成本”，我把這理解為組件的底層價值。

2. 解構組件的功能邏輯

組件本身注重的是行為邏輯，即交互邏輯，非業務邏輯，是業務邏輯構件的工具。從交互視角切入，基本的交互原則是組件本身必備的，要易于理解、易于操作、及時反饋，而組件運作的本質邏輯我理解為對數據的約束、反饋與數據交互，什么意思呢？你聽我說人話：

① 約束作用

看看以下圖片中的舉例，直觀感受一下組件約束能力的價值。第一組是沒有注重組件約束功能的，而第二組是采用了合適的組件約束能力后的效果；

通過以上對比，不難看出輸入輸出的信息都得以約束和規范化，從數據、從業務、從瀏覽都產生了極佳的效果。而在不同場景下這些約束會有差異，為的是更好滿足業務需求，因此就誕生了具有不同約束能力的各種組件，這里再枚舉一些例子；

② 反饋作用

反饋即通過數據加工產生更容易理解的表象，以及在操作后的提示反饋。反饋可以告訴我們有什么是什么、幫助理解這些信息有多少類目、理解這些信息有什么特征、理解這些信息量情況、理解此處有何操作等，盡管相同作用的反饋可能有不一樣的樣式，但這并不影響統一性，差異化只是滿足不同場景或不同容器特征而已，例如會話窗口通知與文本 tips 同樣是信息反饋，那么顯然會話窗口更加重視信息接收程度，出現場景更加正式醒目；

而這整個過程的反饋基本上圍繞“映射”原理進行，從代碼層獲取信息框架再通過界面釋義，就像是一段巧妙而精準的翻譯一般，業務是否吃透、組件用的是否得當、體驗是否良好，都要看這“映射”的功夫下足了沒有；

③ 數據交互

具備數據交互能力，即可以通過組件對界面上的數據發生變化以達成任務操作的目的，說人話就是可以直接幫助我們控制界面元素和數據增刪改查，例如搜索就是利用組件輸入查詢的關鍵詞，并通過按鈕或鍵盤發起數據索引，最終獲取反饋信息幫助我們完成任務。

B 端數據交互的類型相對是比較簡單的，主要包含了富文本、圖片、動圖、音頻、視頻為主，復雜的地方在于特殊格式的兼容和深入編輯的需要，因為要有指定的解碼器支持文件的顯示以及操作存儲，這也就意味著可能需要制作新的配套組件，或是引入其他的組件進行二開，例如代碼編輯器大多 B 端公開系統是沒有提供的，這就需要新開發或新引入。

3. B 端組件的同質化現象

在第一臺攜帶操作界面的計算機誕生時組件就有了，時過境遷，計算機界面的交互組件也配套設備輸入輸出的特征逐步定型，對比當下主流的開源 B 端組件庫，不難發現基礎的組件只存在細微交互動畫與視覺差異，功能邏輯基本一致，這是源于多年來計算機的快速發展沉淀下來的人機交互認知與共識，一切看似有標準但又沒有絕對的標準，約定成俗一般。

盡管 B 端組件還有一定個性化或差異化的空間，但大多也只是視覺表現層的一些調整，并且面對市場大眾化的組件認知與趨勢，很難做出別致的差異化了；

也許在 B 端組件發展的道路上，只會同質化越來越嚴重吧，沒有新型業務需求驅動，可能現有的基本組件就定型了，而市場上的組件系統也會被廣泛的應用與習慣，當廣大用戶養成了認知與操作習慣后，就更沒辦法對組件做出差異化了，這會違背大多用戶的認知與操作習慣，所以對組件本身進行解構創新的價值不大，解構的重點是功能用途的深入理解與應用。

4. 組件對設計師的價值

B 端重業務、重效率、少個性，而 B 端組件同質化正在加劇，那么設計師也就沒有必要去過分考慮組件的差異化或個性化，聚焦新型業務的交互組件或是業務需求設計才應該是眾望所歸，而組件系統的概念與組件的理解應用也應該成為設計師的標配能力，“組件”一定是 B 端設計師的重要價值，卻一定不能是核心價值，所以了也不要老是說 B 端的設計師們就是在搬組件了，這墻砌的不好嗎？

四、解構思維讓組件得心應手

1. 用好組件，先從需求解構開始

不同組件的功能用途首先要理解，至于使用什么組件取決于需求的數據交互以及約束條件和反饋需要，而這些條件均來源于需求，這個過程中，要發揮好解構思維的精髓，那么第一件事就是說“這是個偽需求”，一定不是思考如何執行需求，而是從質疑需求開始，接著就會開始對需求拆解厘清，當需求的結構被你摸清時，你就能感知到需求是否合理，是否有更優方案。然后就可以跟需求方說說你的觀點，我早些時候也是得益于這種思維模式，能夠加深對需求的理解，同時跟產品有來有往，對方也更愿意主動來探討，當然呢，需求方是不是傻*心里也就更有數了。

要開始需求解構呢，就要先清晰需求的結構，一般來講即構成需求的背景、場景、人群、流程、目標、模式等問題，然后拆解分析找到關鍵因素攻破。

當我們完成需求解構后，就需要進一步通過對需求的流程、信息、關鍵詞進行提煉，以匹配需求實現所需要的組件，匹配的本質是依據信息特征和功能要求，即信息的圖文視頻音頻類型、格式兼容屬性、數量單位、映射反饋、邏輯含義、約束條件等關鍵詞，整個解構過程可以用以下這個模型來概括；

案例一：組件區塊解構

案例中，在這套傳統數據表格里，我們需要添加部分微型數據圖表信息，提供給部分角色查看和比較前后行的數據差異，那么是你會如何進行解決呢？

傳統選手使用添加“查看圖表”操作，通過點擊后利用抽屜或彈窗承載圖表數據；

并在圖表顯示面板上補充了切換上下條數據用作比較；

解構選手把傳統表格給改了，采用了可擴展表格，并將數據圖表以卡片的形式嵌入了表格，通過點擊展開查詢圖表數據，可以隨時展開和收起數據的圖表信息。

兩者間有何差異：傳統往往是做加法，解構則是對現有結構做改變。這個過程中解構的是表格擴展數據的各種可能性，以及需求本身的目的是什么，而結合起來找到一種新的表格方式來實現需求。盡管后者方案表格代碼需要做更多調整，但是優勢顯而易見的，在保障能夠實現的情況下，約束了表格橫向的寬度延伸、展開數據支持二次加載減少了請求并發、支持多行數據展開圖表對比，盡可能減少了操作步驟。

案例二：解構樹狀列表需求

需求簡述；要做一個樹狀結構的表格，用于呈現控制節點的基本信息和關系示意，主要是提供給節點管理角色使用，構成的主要信息框架如下：

傳統設計中，提供設計的關鍵信息與關鍵詞基本已取得，我們可以根據需求開始構建頁面了，第一步搭建支持展開收起的表格，用于反饋節點的層級關系，表格 Title 主要由節點名稱、描述、Owner 名稱、工號、部門抬頭、分布域、節點開關構成即可，開關進行操作時進行二次確認彈窗確認即可，大致原型圖如下：

解構思維怎么設計呢？

第一步質疑結構：為什么是樹狀，為什么是表格，這個結構主要包含了什么，重點是什么？表象反映出了什么樣的本質？這樣帶來了什么問題？

第二步破碎拆解：帶著問題對結構拆解，對構成的各方面深入理解，找出新的發力點以及更全面的信息。

——需求結構特征：樹狀結構、信息顯示、開關操作

——需求本身的問題：信息優先級、節點數量規模、默認顯示節點、是否支持過濾、關聯數據或功能情況

——需求結構化：需求對應的場景、參與和使用的角色、服務的作用影響、底層邏輯與流程、交互的信息框架

當然了，需求結構化的方法并不是固定的，可以如上將構成的因素厘清，也可以通過服務藍圖或運作模式來將不同階段進行拆分和理解。

——拆解結構深入理解：對結構構成的多方面進行思考，找到關鍵因素或核心價值，并重新審視結構，來幫助構思新的需求方案。以上需求通過對需求服務對象和需求方進一步溝通，了解到節點管理者更關注樹狀結構的關系、節點的名稱、描述、分布域信息，然后才是負責人跟開關操作，并且節點分為三大類型，有時候會先注意是什么類型，然后辦公時會根據名稱路徑去找想要指定操作的節點，其實節點數量一般在10-30個之間，并且一般都是從第二級開始操作，后續數量上也不會怎么變化，節點與節點之間的互通則由開關直接影響...

第三步重塑結構：經過解構我們將構成聚焦放在節點管理員身上，并獲取了更為全面和有價值的信息，接著我們進入建構階段，思考如何更好的滿足節點的層級與流通性，當前現有的數據支撐和遺漏可用數據有哪些，數據的顯示并不是難點，我們開始思考哪些組件區塊具備層級關系與流通狀態示意能力，在呈現時，如何更好服務節點管理者的使用場景，帶著這些問題我們開始重新對需求進行設計，以及匹配合適的組件搭建原型。

第四步匹配資源：放棄了樹狀表格，但是延續了樹狀結構特征，對于節點的類型重新補充了進來，而信息也重新調整了優先級，使得整個需求結構更加完善合理，原型階段，我們通過拓撲結構來取代了表格，支持子集展開收起，并且以卡片來承載節點信息與操作，節點之間的卡片也用不同顏色的線條示意流通性，在有限節點中，也更好的突出了個體，默認也直接顯示完所有二級節點，大致原型圖如下：

案例小結

對于解構思維應當施加一定的靈活性，要識別是否具有深入和顛覆的解構價值，沒必要過度的解構，解構以后的建構也很具有挑戰性，你要思考優化結構賦予價值。另外有時候經過解構思考后，結論與原本的需求結構差異不大，甚至你也認同原本的方案，這并不沖突，這說明原本的設計者也是嚴謹或靠譜的，并且深入理解的過程是寶貴的，在體驗設計的范疇，解構思維應該是為我們提供別樣的視角，幫助我們深入本質解決問題，并不是為了生成新的結構而解構。

五、解構思維對 B 端的價值

1. 突破對傳統結構的思維局限

產品設計中，常常開玩笑說就是互相抄來抄去，要是競品斃光了，都不知道接下去怎么設計了，很多時候我們看問題常常憑借經驗或直覺看表象，未能深入或大膽的批判人家的不好，對權威提出質疑，而解構思維正好反其道行之，以使得我們對競品分析或用戶研究后不會拿出一個顯而易見的結果，卻沒有深入的結論做業務抓手。解構思維可以去中心化去權威化，幫助我們深入并注意到構成個體的價值，以為業務帶來更多的可能性。

2. 業務優化或改版的得力助手

看起來沒什么問題，或是對方案沒有底氣，那就試著解構一下，先把頁面里的業務拆出來，在把業務之間的關系和邏輯才拆出來，當你解的足夠清晰明了時，面對不同場景或角色特征，需求優化的方向就開始清晰了，解構思維能讓你變得游刃有余，是業務分析和理解的一把好手。

3. 深度理解組件原理與應用

以前總是問這個組件怎么用，其實應用解構思維后，才發現原來是自己太懶了，沒有進一步的對組件進行思考和理解，其實運用解構思維想想人家組件為什么這么做、還能怎么做、什么場景下用，馬上就通透了，并且對于組件的模塊化改造也是有著相當的作用。

六、結語

早些時候，我以為的解構，就是對某個結構進行拆解加深理解，而之后又意識到還要用一些顛倒、反轉、重組、疊加等一些列手段進行建構，目的是形成一個不同于以往的結構，再后來才發現解構也沒那么簡單，解構主義更注重的是對傳統觀念中的結構發起的質疑，從而引發新的深思，將本質不再停留在結構與表象本身，并試圖找到新的或其他合理的點進行重新建構，最終帶來不一樣的結構或價值體現，這種例子也在當今多元化的世界處處可見，稍加靈活的應用，解構也會是不錯的工具。

當然了解構已經在各行各業開出了不一樣的花，怎么理解怎么運用會有所不同，這里主要也是分享了在體驗設計領域中我對解構思維的理解與運用，算是拋磚引玉吧，你有看見什么好例子嗎？評論里告訴我，我們一起解構解構