行業對設計師的要求?直都在不斷革新，只有「?技之?」的設計師已經很難滿??業需要，產品分析已經不僅僅是產品經理的工作內容，對于 UI 設計師來說，也是必備技能之一了，尤其是對于 B 端領域的設計師來說，更需要拓寬視野，思維前置。
那么，該如何去做產品分析呢？本文將從產品分析是什么，如何做兩個方面來講述，為大家提供思路，做真正落地的對設計有幫助的產品分析，提高自己理解業務、處理業務、解決問題的能力，體現出設計師的價值。
1.1 產品分析定義
1.11 B端產品是什么
對于 B 端產品來說，它只有一個目標，就是解決問題，通過對問題的分析得出解決方案，而任何一個問題都不會只有一種解決方案，在權衡利弊后得出了最終的解決方案，產品就是解決方案的表現形式和實際載體。
1.12 產品分析是什么
從設計師的角度來說，產品分析通常是挖掘產品缺陷，優化產品體驗，為產品迭代提供依據，比如：通過深度體驗產品，挖掘產品的在功能、交互體驗方面的不足，并通過分析制定產品優化方案。一款產品從淺至深擁有無數的可被挖掘的信息，這些信息本身是龐雜冗余無意義的，只有通過分類和清洗才能得到對人有意義的信息，本質上來說，產品分析就是在做信息分類和清洗的工作。
1.2 產品分析與市場分析、競品分析
1.21 市場分析
市場分析是對產品所在的市場進行宏觀的競爭態勢和市場規模的分析。市場分析主要包括行業背景、市場現狀和商業模式三部分?？梢钥吹剑袌龇治銎鋵嵤菑暮芎暧^的一個角度來切入，更偏向于戰略層內容，因此市場分析也是三者中距離設計師最遠的一個概念。用通俗的話來說，市場分析最主要的目的就是分析產品是否賺錢。
1.22 競品分析
廣泛意義上說，競品分析就是根據分析目的，找到切入角度，對競爭對手或市場進行客觀分析，找到競品或自己的優勢與不足，為下一步決策提供科學依據，其實就是「知己知彼」的過程。對于設計師而言，競品分析的目的更傾向于尋找解決方案，比如：通過競品分析來尋找參考從而解決自己當前遇到的問題。
1.3 產品分析對設計師的意義
-
1. 設計：幫助設計師理解產品的歷史和現狀，避免設計時天馬行空無法落地
-
2. 業務：幫助設計師快速理解業務和融入新團隊
-
3. 溝通：可以幫助設計師同產品經理更好地進行對話，降低溝通成本
1.4 難點——業務難以理解
不同于 C 端，B 端往往有很堅固的行業壁壘，所涉及業務也非常難以理解，究其原因，來自以下兩個方面：
1.41 業務邏輯復雜
B 端產品很多時候，都是在原有線下業務的基礎上進行數字化。邏輯的復雜度本質上是來源于這個行業多年來積累的足夠成熟的業務流程與規范，而這些東西沒有辦法速成，只能靠不斷地積累來增進理解。
1.42 遠離日常生活
C 端產品的設計中，設計師大部分情況下都或多或少地就是用戶本身，或者帶有用戶屬性，比較容易產生同理心，去發現問題解決痛點。
而 B 端產品不是給普通用戶使用的，是給特定群體使用的，這種特質就決定了設計師很難去真正地理解用戶的處境，設計師最厲害的特質——同理心也很難派上用場。
1.5 誤區
有的設計師同學，一接到產品分析的任務，到手就是先去網上看看別人是怎么做的，然后按著人家的結構對自己的產品進行一通分析，其中不乏用到了「用戶體驗五要素」、「SWOT分析」等看起來高大上的方法論。
按這樣做，產出的分析報告不能說錯，但是最起碼是不恰當的，對設計上的幫助微乎其微。其中有這樣兩個問題：
-
1. 與產品經理邊界混淆
-
2. 注重方法論，流于表面
1.51 與產品經理邊界混淆
產品經理是產品的第一負責人，需要對產品的整個生命周期負責，說人話就是產品經理負責產品做什么不做什么，該什么時候做，而設計師關注的是產品的用戶體驗。產品是商業的代言人，而設計師是用戶的代言人，二者本質上的不同，就決定了在做產品分析時關注點必然不同。如果按著產品經理的思路來做產品分析，得出大環境之類的太過于泛化的結論對設計沒有什么實質性的幫助。
1.52 注重方法論，流于表面
用戶體驗五要素，swot，等等這些高大上的方法論看起來非常有用，從多個維度把一款產品分析得非常清楚?？烧鎸嵉那闆r時，往往新手設計師同學既不懂方法論的本質，也不懂使用場景，只是盲目地套用，導致產出的是一篇「八股文」一般的產品分析報告，過于全面但沒有重點，什么都是點到為止，對自己理解業務和輔助設計沒有實質性的幫助。
我認為，「方法論」本質上是經驗主義，使用過去解決問題的方式來解決新的問題。在一定程度上，方法論是有用的，一些簡單的問題，確實是有固定解法的，而且，解決問題也更快。但是在更難更特殊的場景下，方法論不再管用了。很多時候，問題表面上看起來一樣，可是由于問題的背景不同，所以解法也是不一樣的，這時候再采用方法論，就會產生思維固化，強行去套方法流程，得到的一定不是最正確的答案。
在確定了目標和分析重點之后，我們就可以開始進行分析產出產品分析報告了，在這里我整理了幾個撰寫時的原則供大家參考：
2.1 避免主觀——不要把自己當成使用者
第一點是我們要避免去主觀臆斷功能的合理性。正如我上面提到的一樣，我們并非 B 端產品的核心用戶，有些我們感覺反常的地方，但是其實有它的合理性，因為 B 端用戶的痛點往往是在特定的工作場景下產生的。因此，在不了解真正用戶和場景的情況下，僅憑經驗下的結論往往是錯誤的。
我之前的一個項目的設計中，在給圖表配色時，我最初的一個版本是用的近似色去完成的，在發給產品經理初審時被打回來了，理由是這種配色不夠明顯。我追問原因后才知道，我們的一部分用戶是年齡比較大的用戶，對比度足夠高才能方便他們看清楚。最后出的一個版本是對比度非常高的配色，盡管從設計的角度來看這種配色美觀度不足，但是能夠讓用戶看得清楚。
在這個例子中，用戶對于美觀度并沒有很高的要求，反而對于數據的識別度要求更高。我們常聽的一句話是「己所不欲，勿施于人」，然而在B端的設計中，我們更要做到「己所欲，亦勿施于人」。
2.2 思考要全——使用者和決策者都要考慮
B 端產品有一個很重要的特點，購買決策者與使用者的割裂。我們在思考一個功能時，不能僅僅考慮使用者的體驗，也要考慮決策者的想法。
比如釘釘的「已讀未讀」這個功能，相信大家對這個功能是槽點滿滿。但是在 B 端產品中，決策鏈上游是購買決策者即老板，因此就有了這個功能。如果只考慮到用戶體驗，這個設計從一開始就不該出現。但是，與 C 端產品的流量思維不同，B 端產品不是靠體驗來吸引用戶存活的，而是靠滿足決策者的需要來活下去的。很多大家感覺不好用或者體驗很差勁的 B 端產品，仍然活得很好，就是這個道理。
說句題外話，釘釘已經注意到了這個細節，在去年的一個演講上，釘釘總裁也提到了對這個功能點的考慮，他舉了一個場景，在不改變現有設計的情況下解決了這個問題，通過智能手表等外設來預覽消息，而手機和電腦依然顯示未讀，自己考慮好了的時候再去回復。
2.3 自上而下——從宏觀到微觀
從戰略層到功能架構，再到每個功能細節，采用金字塔原理去遍歷，避免遺漏的同時層層深入。
在此處，我介紹一下我認為一份合格的產品分析報告應該包含的部分，各位設計師同學可以根據自己的需要進行適當調整。
3.1 文檔說明
3.11 版本說明
因為產品分析是有一定的時效性的，且是針對某一個具體版本去進行分析的，所以在文檔開頭要列出自己所分析產品的版本，例如（飛書 V5.6.9，釘釘 6.3.35）。
3.12 分析時間
即設計師進行產品分析的時間，留檔以供以后查看。
3.2 產品概述
此處要回答的問題是，產品是用來干嘛的，給誰設計的以及怎么賺錢的。
3.21 產品定位
即產品是用來干嘛的，不需要特別具體，只需要在大方面上對產品進行概括即可。舉個栗子，抖音定位是一款短視頻消費型產品，以“內容”的新鮮有趣為主，強調分享和信息獲取，滿足幸?？鞓返拿篮脮r刻需要。
3.22 目標用戶
即產品是給誰設計的，在此處需要對客戶和用戶做區分?？蛻粢话闶侵钙髽I的 CEO/管理者，他們來決定是否要斥「巨資」購買一款軟件。比如說某公司的 CEO 最終決定買釘釘還是飛書作為辦公協同軟件。而用戶一般是企業內的員工，他們使用軟件來完成一些日常工作。分析目標用戶的意義是，在之后的分析中，我們都要以用戶為落腳點，去分析功能的合理性。
需要注意的是，此處并不需要去做一套完整的用戶畫像，只需要大概描述一下是產品的客戶和用戶的職位和核心需求即可。
舉個栗子，對于某客服工作臺產品，
-
用戶：客服，主要職責是接受用戶咨詢，幫助顧客解答疑惑。
-
客戶：公司 CEO，目標是對業務情況進行把控，提高客服效率。
3.23 商業模式
即產品如何賺錢，在這里，我們并不需要用各種很高端的工具——比如商業模式畫布，去分析商業模式，我們僅需要知道產品的賺錢方式即可。作為設計師，我們不需要有產品經理那么專業的商業思維，但是我們也一定要能夠從商業角度理解產品的價值，一款產品最健康的狀態一定是用戶價值與商業價值并存。因為本質上而言，用戶體驗也是商業價值的一部分。
對于B端產品而言，有兩種最常見的售賣方式：
1. 本地部署 —— 按軟件數量售賣
本地部署是指產品的應用、數據都存儲在一臺計算機中，這臺計算機不與其他任何服務器、計算機相連。21世紀之前的傳統 IT 公司大部分都屬于這類，比如 Adobe 旗下的產品（盡管他們也在做云，但是更多情況下我們還是把 PS 當做本地產品來使用），那時候 B 端企業的商業模式是：主要服務于大企業客戶，通過與頂級的合作伙伴合作，推出頂級的產品，提供一整套軟硬件解決方案，并進行深度服務，一次性收取高昂的軟硬件費用，并且每年加收不少服務費。
2. SaaS —— 訂閱制
21 世紀后，隨著云計算技術的發展，越來越多的產品開始部署在云上，也就逐漸發展成了現在的 SaaS 產品，從這個角度來講，我們通常所說的 SaaS 產品其實就是將本地部署變為云端部署的產品服務。
這時候 B 端企業的主要商業模式是：不僅服務于大型企業，也服務于中小企業。以訂閱制的方式，定期收取費用，并且提供不同的版本，進行差異化定價，實現收益最大化。
舉個例子，藍湖就是提供了四個版本并且以季付或年付的方式進行收費。
3.3 功能架構
3.31 什么是功能
將需求轉化為對應的軟件層面可實現的能力，即功能，功能可以實現需求所期望達成的目標。
3.32 什么是功能架構
一個完整的 B 端產品包含若干功能，將一套功能依據業務進行分類整合，形成的抽象化業務模型即功能架構。
3.33 功能架構與信息架構
功能架構指的是產品是如何由這些功能組成的。我們在分析功能架構時實際上更偏向于產品的實現模型。
信息架構是包括組織系統、標簽系統、導航系統、搜索系統在內的綜合系統。我們在分析信息架構時，分析的是這個產品是如何將不同的功能組合在一起展現在用戶面前的，分析的是產品的呈現模型。
3.34 為什么要分析功能架構
一個成熟的 B 端產品甚至會有甚至會有三四百個功能，我們在分析功能細節前，必須要先厘清架構，以一種抽象的框架視角來全局思考，而不是也僅僅以用戶的視角來看產品的表象。
3.35 如何分析功能架構
收集
真正地去使用產品，并將產品的所有功能與模塊收集到一起。
整理
以模塊作為分類依據，將所有功能分到不同的模塊里，必要的話，可以繼續細分子模塊。
在這里要注意，一個功能是否屬于某一個模塊，不能以這個功能是否在某個頁面為依據。一個頁面出現了某個功能，只是因為這個場景下用戶需要這個功能，而不是這個功能屬于這個頁面。
以飛書后臺為例，很多人在分析時會把首頁也作為功能架構圖中的一個節點去分析，這是錯誤的。
首頁只是功能的聚合，而非功能模塊，例如「添加成員」這一功能應該屬于「組織架構」模塊中，如果將首頁也加入分析，勢必會出現功能的重復。
3.4 功能分析
在分析完整個功能架構之后，我們可以深入到每個功能的細節了。其中包括以下兩點：
3.41 功能使用流程
通過繪制功能的使用流程，我們可以模擬用戶在使用產品時的流程，發現一些從宏觀角度上忽略的點。在繪制時，要注意的是，要控制在頁面 & 操作維度，避免拔高到功能維度甚至業務維度。
3.42 背后的需求
我們除了要知道這個功能該怎么用之外，還要知道功能與業務的關系 —— 功能背后的需求。
3.43 需求分析
在分析背后的需求時，除了知道這一需求是什么，如果可以多走一步，對需求進行分類，那對于我們了解產品時大有裨益的。
3.44 馬斯洛模型的局限性
關于需求的分級，在 C 端中常用的模型是馬斯洛需求模型，但是這一理論并不適用于 B 端，主要是由于以下原因：
-
1. 馬斯洛需求研究的是人，而 B 端產品面向的是企業和組織
-
2. B 端系統一般復雜度較高，除了業務目標之外，還要考慮軟件架構、體系構建等問題。
3.45 B 端產品的需求劃分
一般而言，我們可以將需求劃分為功能性需求與非功能性需求。非功能性需求，指的是隱藏在功能需求背后以及開發需要考慮的的需求，也叫作“跨功能需求”。最常見的非功能性需求就是產品的響應時間，一般非功能性需求是由開發和測試同學考慮的。
而對于功能性需求，有三大類：業務需求、功能需求、產品需求。而這三類需求也有比較立體的層次關系：
業務需求，提出者是業務范圍、業務模式和業務規則的制定者，一般是指業務方的高層人物，比如 CEO、高級經理等。產品設計是服務于業務定位的，進而使得產品戰略遵循于企業的發展戰略，只有這樣產品方向才不至于發生偏差，因此，他們提出的需求一般不能違反，換句話說，他們提出的需求是整個系統設計的最高綱領。
用戶需求，提出者是基層管理者和執行者。他們關心的是如何使用產品完成自己的工作，提出的需求相對細節，例如對操作、流程上的訴求。
產品需求，由于 B 端產品的復雜性，在建設時需要考慮到功能復用問題，以及與其他系統的架構交互問題。舉個例子，語雀 App 是阿里旗下的產品，在開發登錄界面時，沒有重新開發，而是集成了阿里云的 SDK。產品需求本身對業務實現沒有價值，它的價值體現在節省人力和優化軟件架構上。
三者雖然并沒有絕對意義上的優先級順序，但是一般而言，B 端產品時優先考慮業務需求，其次關注用戶體驗，滿足用戶需求，最后才是考慮產品需求。了解了這一點，我們對功能背后的需求進行分類后，就可以從更高的視角來分析功能的設計邏輯，而不僅僅是停留在好不好看的層次上對功能進行分析。
3.5 交互設計
3.51 交互設計是什么
在《交互設計原理》中是指：對于交互式數字產品、環境、系統和服務的設計，定義人造物的行為方式，即人工制品在特定場景下的反應。
在《交互設計精髓4》定義為：設計交互式數字產品、環境、系統和服務的設計，聚焦于如何設計行為。
而在《超越人機交互》中則是指：設計交互式產品來支持人們在日常工作生活中交流和交互的方式，創造用戶體驗以增強人們工作、生活以及通信的方式，聚焦在實踐上，即怎樣設計用戶體驗。
交互設計即行為設計，關注于如何設計系統如何幫助用戶更高效愉快地達成目標。
3.52 怎么分析交互設計
僅僅知道是什么遠遠不夠，我們更要知道如何去分析一個產品的交互設計好壞。在這里，我提供兩個思路供大家參考：
從行為維度拆分
上文提到，交互設計的對象是行為，而這里的「行為」可以拆分為 3 個部分：導航，輸入和展示。
導航系統：即用戶在哪里和去哪里
設計要點：
-
1. 導航不能是一個頁面上可以鏈接到其他所有頁面，而是要有的放矢，選擇用戶關心的，更想要去的頁面添加導航。
-
2. 導航要顯示出來導航本身與所包含內容的關系
-
3. 導航要顯示所包含內容與當前頁面的關系
例如：掘金的頂部導航，既體現出來了導航本身與包含內容的關系（導航的標簽是當前內容的概括），又體現出來了內容與當前頁面的關系（當前頁面是首頁下的一個子頁面）。
輸入系統：即用戶向系統提供信息
這里的輸入不僅僅指我們日常中的輸入，而是一個廣義的概念，將所有用戶向系統提供信息的方式統稱為輸入。輸入可以通過多種方式完成，包括輸入命令、按下按鈕、快捷鍵、甚至打手勢、語音等方式。
設計要點：
-
1. 高效，例如絕大多數的產品都提供了快捷鍵提高用戶的操作效率。
-
2. 準確，例如 sketch 里方向鍵的作用是移動 1 像素，使用戶在使用鼠標快速移動的基礎上，也可以準確操作。
-
3. 防錯，例如大部分的產品都會在危險操作前二次確認。
-
4. 符合預期，例如在「幕布」中，在畫布區和在滾動條區都向下拖動鼠標，操作結果是相反的，但卻符合用戶的預期。
-
5. 適當隱喻，隱喻是指提供熟悉的實體，是人們能夠容易地理解底層概念模型并知道在界面上做什么。例如我們所熟悉的購物車就是現實世界中購物車的隱喻，幫助用戶快速理解軟件的使用邏輯。
展示系統：即系統向用戶提供信息
設計要點：
-
1. 突出重點。用戶的瀏覽動作不是讀，不是看，而是掃。設計中應該突出重點，弱化和剔除無關信息。
-
2. 保持一致性。樣式規范一致性給用戶帶來品牌信賴感的同時，還能夠通過一致的重復降低用戶反復學習成本。
-
3. 及時反饋。系統應該讓用戶知道目前的狀態, 并及時給予相對應的反饋。
十大可用性原則
尼爾森十大原則由畢業于哥本哈根的人機交互學博士 Jakob Nielsen 發表，他提出十大可用性原則，用來評價用戶體驗的好壞，我們也可以以此為依據來分析一個產品的交互設計好壞。具體的內容網上有很多資料，筆者就不再贅述。
3.6 視覺設計
3.61 概念
視覺設計即 UI 設計，負責產品的圖形、圖標、色彩、視覺風格等，從視覺層面把控產品界面設計，決定營造出什么樣的視覺體驗。
3.62 分析內容
視覺設計的分析內容可以拆分為形、色、字、構、質、動。在分析時，如果是網頁端，可以借助瀏覽器的開發者模式或者谷歌瀏覽器的插件「VisBug」來詳細查看各個維度屬性細節。
形
圖標的圓角，卡片的圓角，icon 的風格與統一度（包括：視覺大小，線段粗細，端點類型、拐點類型等）
例如，同樣是頭像卡片，QQ采用了圓形來體現靈動輕盈的風格，而主打熟人社交的微信則采用了小圓角。
色
色彩分析包括用色規范、色彩搭配、層級等。在 B 端產品中，色彩在使用時更多的是基于信息傳遞、操作引導和交互反饋等目的。
字
字體的屬性有字號、行高、字體、字重等。通過合適字號和字重可以對界面元素劃分視覺層級，幫助用戶識別。而在一些特殊的場景下，可以運用特殊字體來提高識別度和增加頁面美觀度。
例如：支付寶使用了常用的 Din pro 作為其數字字體，其他 APP 廠商也分別使用了特殊的數字字體。
構
此處的構是指頁面結構，分為層級和間距兩大部分。合適的層級和間距可以幫助用戶理解頁面，并給予界面呼吸感和通透感。
質
質感與風格、界面風格，投影數值，扁平還是擬物。
比如說相比普通的單層陰影， Ant Design 采用了三層陰影的表達方式，讓陰影更柔和，更符合真實狀態。具體可查看 https://ant.design/docs/spec/shadow-cn
動
最近幾年，越來越多的公司和團隊已經意識到動效在產品用戶體驗中的重要性，動效設計已經成為產品設計語言的重要構成之一。
動效設計并不只是為了修飾，使用動效不僅可以更清晰地體現內容元素之間的邏輯和層級關系，還可以提供當前的狀態反饋，加強用戶對操作行為的感知，給用戶以可控的感覺。
除了上述內容之外，我們在分析一個產品時還可以做以下兩件事：
4.1 用戶體驗自查
4.11 為什么要做體驗自查？
在被問到「你覺得這款產品的用戶體驗好嗎？」時，我想大部分設計師同學即使做完了產品分析，也很難回答這個問題。那么，我們該如何做才可以較為準確地回答這一問題呢？
基于這個問題，我們從用戶體驗的定義出發，ISO 對用戶體驗的定義有著如下解釋：
用戶體驗，即用戶在使用一個產品或系統之前、使用期間和使用之后的全部感受，包括情感、信仰、喜好、認知印象、生理和心理反應、行為和成就等各個方面。
從定義可以看出，用戶體驗不僅是主觀的，而且范疇非常廣，所以在描述時，我們不能僅僅用好/不好來概括。要解決這個問題，要點在于建立一個清晰合適的標準來量化用戶體驗，體驗自查就是在做這樣一件事 —— 度量體驗。
通過做體驗自查，可以達成以下效果：
-
1. 將用戶體驗量化，探索設計破局點
-
2. 幫助設計師更全面地審視產品設計
-
3. 將產品體驗上的問題可視化，更直觀地展示體驗問題
4.12 工具 —— 設計走查表
本質上，設計走查表通常是設計師在完成設計稿后，用于快速遍歷方案、修正遺漏或不周的工具。在產品分析中，我們使用這個工具也可以達成體驗自查的目標。通常，我們是需要根據產品建立一套適合自己的交互設計自查表的。如果暫時沒有，也可以暫時使用網上成熟的自查表來進行。
4.13 步驟
收集
字段說明
問題位置：
即體驗問題發生的位置。
類別：
不同自查表對問題的分類不同，例如用戶體驗五要素、可用性原則等。
重要程度：
如果采用正向思考，很容易陷入“都很重要”的困境，所以這里一般采用反向分析法，也就是如果不解決這個體驗問題，會造成多大的影響。我這里將重要程度分成了三個等級，分別是：
-
1. 基本沒有影響，有替代功能
-
2. 不解決也可以用，但不太好用
-
3. 不解決基本/完全不能用
發生頻率：
同樣是三個等級，需要注意的是，這里不是以時間頻率來定義的，而是以「每經歷 n 次業務節點就會出現這一問題」的方式來定義的，如果不好量化，也可以使用每次，經常，偶爾這樣的詞來代替。
嚴重程度：
嚴重程度 = 重要程度 * 發生頻率
這里要注意的是，我們作為設計師，提出嚴重程度的判斷僅僅是作為優先級參考，但是真正的優先級和排期還是需要產品經理來做。
問題描述：
即對體驗問題的詳細描述。
整理
首先，對問題進行重新審查和校驗，去掉非體驗問題、重復問題、補充不完整的問題描述等，然后整理到一起，這就是整個產品存在的大大小小、各種各樣的問題了。
然后，我們通過圖表對數據進行二次加工，一般采用雷達圖或柱狀圖。
示例 - 雷達圖的使用方式
嚴格意義上說，這并不是標準的雷達圖，只是使用了雷達圖的圖表背景。
外圈：上述表格中的「分類」
數值：上述表格中的「重要程度」
為每個模塊/流程各制作一張表，然后將每個問題都以點的形式置于圖中，哪個分類問題最多，哪個模塊/流程問題最多？哪些問題較為嚴重亟待解決？一目了然。
4.2 專業名詞庫
設計的本質是為了更好的解決問題，了解業務是解決問題的基礎，也是溝通順暢的利器。但是想要成為一個業務專家，沒有長時間的沉淀上是不太可能的，但是公司一般不會給很長的時間去學習業務，那我們該如何在短期內快速掌握業務知識呢？
在理解業務時遇到的最大挑戰就是那些晦澀難懂的特殊名詞，如 json 文件，API 等開發中特定的術語。
針對這個問題，在產品分析的過程中，我們可以同步建立一個專業名詞庫，來記錄這些特殊名詞，并將這些概念用自己的語言進行描述。這樣，在了解產品的同時也對業務有了一定程度的了解。
對設計師而言，相比 C 端的各種炫酷效果，B 端設計很難做的出彩，設計的價值更多是隱形的價值，基本不存在會有人因為你把一個按鈕做得好看夸你。從這個角度來說，確實成就感比較低。
但是，通過自己的設計讓幫助用戶更有效率地完成工作，這何嘗不會帶來滿滿的成就感？B 端產品一般是用戶不得不使用的產品，作為設計師的我們更應該對自己所設計的產品有著敬畏之心。
最后，給大家分享我很喜歡的一段話，與大家共勉。
本次的分享到這里就結束了，希望可以對大家有幫助。由于文章字數較多，筆者幾經修改，仍不免有疏漏錯誤之處，如發現錯誤，請讀者于評論區或私信指出，不勝感激。
在快節奏的洪流中，保持設計的初心，做有靈魂的設計，我們下篇再見~
作者：靳凱杰ah
轉載請注明：站酷
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼藍小助，報下信息，藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、
UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司
