這次案例是一個我最近在預定的船票預定服務，由一家叫名門大洋的渡輪服務公司提供。下面是對它預定的簡單介紹：
步驟1：打開官網，到 [船上生活] 模塊查看有哪些船（只有兩艘）和房型，以及船上有哪些服務設施等。
步驟2：進入 [運費和費用] 模塊，先看他們的預約規則，然后打開他們提供的PDF查看預定的日期和價格，來確定自己想要選的房間。這里房型價格和熱門時間有關，官方分了A、B、C三個價格檔來對應熱門冷門時間。
步驟3：進入 [預定] 模塊，填寫個人信息和想預約的房型，房型選擇有3個，如果前面的選擇滿房就向后遞補，填寫完成后，就可以點擊發送預定信息。
步驟4：隔日等待反饋郵件，到郵箱中查看。還能預定的話就會有一個鏈接，進入鏈接中進行支付。之后就可以獲得登船的憑證。
后續的細節就忽略，一個簡單的買票緩解，操作起來這么麻煩，是不是感覺非常陌生，這是因為國外有很多服務的預定都需要到官網預定，和國內出行完全依賴綜合旅游軟件如飛豬、攜程、去哪兒等不同。
而這個訂票的流程，到審核（人工的）回復的整個過程，就叫 —— 業務流程，是一個被設計好并標準化的商業實踐過程。
每家公司的經營都會包含大量的業務，房間預定只是它的其中一個業務，還包括登船、房間清理、物資采購等。而每個常規的業務的執行如果全憑員工自己的想法、感覺，那么企業的運轉一定會一團亂麻。所以經營者就要針對這些常見的業務，設計出相應的流程出來進行標準化，讓員工和顧客遵循這套流程來完成商業活動。
而業務只有流程框架還不夠，必須包含大量的細節，比如前面提到的不同定價時段，滿房的遞補，退票的方式等等，這些都是業務流程中的細節規則，我們可以統稱它們為 “業務邏輯”。
簡單來說，企業經營要先確定業務，然后設計流程，再制定具體的業務邏輯，形成完整的商業閉環。但這和設計師有什么關系呢？
因為業務是產品的出發點，常規項目只有業務形式確定下來，才會進入產品的設計階段，而不是先設計產品功能再讓業務去適配它的特性。而產品后續一系列的復雜、抽象、晦澀的決策也全都和業務有非常大的聯系，
如果設計師不先理解業務，就可能無法理解產品的需求和決策，導致最終的設計結果和目標想去甚遠。
這個預定過程對于熟悉國內互聯網的我們來說肯定是太復雜了，用個線性流程表示的話，對比如下：
國內軟件預定：打開軟件 - 搜索船票 - 選擇日期 - 選擇房型 - 完成支付
官方網站預定：搜索官網 - 打開官網 - 查看房型 - 查看價格 - 填寫信息 - 等待回復 - 查看郵件 - 完整支付
從字面上感覺可能不明顯，但實際上操作時長、點擊次數以及總消耗時間，它的做法遠比國內的服務慢，加上細節里有很多會延長完成時間的邏輯，比如沒有想要的房型就要重新去選一遍，而這在國內軟件里一開始就能知道直接規避掉。
這個業務過程非常的原始，后臺可能有一個簡單的收件系統，由人工來逐一審核提交的郵件，創建訂單，然后再提交回復。
如果我們要提高這個業務的效率，就必須要改進這套系統，將人工的機制進行簡化，即客戶可以直接在前端完成篩選、預定、支付的操作。相信大家都很熟悉這種操作過程，而這種改進就叫 ——
企業數字化升級
。就是本來使用人工或者很原始的方式執行的業務流程，引入數字化的系統、產品，來提升它的運行效率。
而產品經理要在這個過程做業務的分析，具體分析什么呢，可以簡單總結成：
前兩點前面已經解釋過了，當前業務是存在缺陷的，而產品經理必須先理解完業務和找出問題，才能進行后續工作，而不是直接忽視背景打開 Axure開始畫圖。
有了問題，下一步就是建立產品的框架，比如這個業務會涉及到多個端，產品就要先創建多個端的功能框架出來，包含的端可以簡化成下面三個：
用戶端就是普通的網頁預定模式（這里不討論APP和小程序等），讓用戶直接選擇日期、船型、房型后支付獲取憑證，非常容易理解，不用多做介紹，我們重點放在管理端和后臺服務的解釋上。
TIPS：這里有個可以思考的小點，沒做用戶系統你們可以分析下為什么。
在管理端上，管理員已經不需要手動審核預約了，所以只需要對訂單和賬單（這是兩件事）有查看和管理的操作即可，來完成一些特殊業務事件的處理。
而在后臺服務上，就要確定有哪些數據信息，以及處理它們的方式。比如訂單的支付、退款，會涉及到非常復雜的后臺處理過程，包括不同支付方式接入、對不同貨幣的支持、資金的轉出等等。其它功能還包括房型數據更新、價格數據更新。這些都是用戶端和管理端無法直接看見，但又在真實運行的功能。
根據上面對不同端的分析和構想，就可以創建產品的 —— 功能架構圖，比如下面這個極簡的版本：
對于一個成熟的產品經理來說，進一步制定產品的需求肯定不是直接打開Axure畫原型，而是先圍繞業務的需求制定 —— 數據字段。
數據字段即前、后端服務中要存儲、計算、展示的具體對象。比如一個房間，前端頁面會展示房間名、價格、人數、面積、類型、評價等各種數據。但這些數據不是憑空出現的，而是要先計劃和開發才能實現的內容，且不同字段背后可能還包含復雜的設置或計算規則。
所以產品要花很多時間分析應該記錄哪些數據字段，這些數據怎么產生，背后有什么邏輯，在前端顯示的標準是什么。
用個更具體的案例來解釋，比如要創建房間價格這個字段，這個字段的值就具體價格值。但是房間的具體價格不是固定的，包含三個檔位，根據日期決定的檔位進行靈活的變動。所以要實現正確的價格顯示，光有一個房間價格字段是不夠的，我們需要建立更多字段來滿足它的使用，包含：
-
-
房價當前系數：根據忙時和閑時變更定價的系數，比如忙時是原來的1.5倍，閑時是原來的0.8倍
-
房間當前價格：根據定價基數x 系數得到的當前價格，是前端展示和付款的具體金額
這是個非常簡化的版本，除了使用基數x系數的邏輯外，也可能直接給房間制定A、B、C三個價格的字段直接填價格不做系數計算。在真實項目中，該功能會創建得字段數遠不止這些，產品還需要去明白數據的來源、計算邏輯、應用規則。
對于成熟的項目來說，項目的數據字段就是業務需求的延展，是整個業務正常運行的基石和原材料，產品制定的需求就包括它們的內容和規則，再讓后端工程師去實現出來（而不是后端自己憑感覺想）。
有了上面這些準備，那么產品應該做成什么樣就清晰很多了。下一步，產品經理就可以先用思維導圖去規劃管理端的頁面結構與內容，而這種思維導圖通常被稱為 ——
產品地圖
。
規劃完產品地圖后，下一步才進入正式的產品原型設計過程，將我們對產品應該做成什么樣通過原型線框圖表現出來，只要能讓其他人理解我們的意圖即可。
當然只看圖是不夠的，很多細節的決策和邏輯就需要添加文字的說明，這種結合原型+文字的需求就交 PRD需求文檔。它的作用是讓設計師、程序員、測試工程師可以看懂并把它們做出來的 “施工方案”。
而作為B端UI設計師就要在了解業務和獲得這些需求后，才能明白我們后面應該完成哪些工作，輸出什么樣的界面內容。
前期準備要做的事情很多，包括參與立項的各種會議，接收各種信息和要求。但占據我們最多精力的工作，就是展開對項目設計的 —— 前期分析，這也是很多同學在作品集包裝中看到的大段分析文本的來源。
每個項目前期的分析內容都有差異，但我們大體可以總結成以下幾個模塊：
-
-
-
-
-
項目分析就是了解整個項目背景的過程，比如這個企業的背景、提供的服務、業務的內容等等，最重要的目標就是 ——
明確項目目標
，即項目要實現什么成果的預期。在這個渡輪項目中，項目的目標可以總結成提高顧客預定的效率和體驗，同時降低人工審核處理的工作量。
了解這些信息是最起碼的要求，假設你不了解這些項目的信息，直接開始跟著產品原型畫圖肯定是非常迷茫的。就像一個士兵被分了把槍到前線接收指令，你并不知道自己為何而站，為什么要占領前面那些陌生的高地。
業務分析則是了解項目具體面向業務的具體流程、規則、邏輯。渡輪的預定業務邏輯我們上篇已經探討過了，很容易理解。但我們的項目是對原先業務流程的優化，這就意味著業務端必然會發生一定的改變，我們就要清楚這個改變的原因，舊業務的模式和缺陷，以及新業務的形態和優勢。
這些信息主要從產品經理那里了解，或者他在特定的會議中會提供，就看你有沒有認真聽了。即使沒說也可以主動提問，這個問題并不復雜。
再接著就是產品分析，這個分析是理解產品經理規劃的產品是什么樣的，即通過查看原型和文檔來理解他的意圖。雖然只是看，但理解起來并不會太輕松，越復雜的項目理解起來成本越高，所以我們也稱這個過程是一個分析過程。
如果不能理解這個邏輯，就可以找一本相機說明指南仔細閱讀，即使這本指南寫的事無巨細，你要徹底搞懂它有哪些產品功能和對應操作邏輯，也要花費大量的精力和時間。
再下一步，就是體驗分析部分，而這里要我們發揮主觀能動性的部分就多了。通常，體驗分析的目標，就是在產品需求確定后去找到有哪些可以提升體驗的地方，確保最終設計的成果能讓用戶感覺體驗更好。
要實現這個目標就要盡可能了解用戶，即 ——
用戶調研
。因為體驗是基于用戶產生的，只有足夠了解用戶你才知道怎么面向他們做什么。雖然用戶調研的方式多種多樣，但在B端領域中用研卻很簡單，因為我們更容易直接和系統的操作員（不是用戶端消費者）溝通，了解他們的訴求。
然后根據他們的訴求，來推導產品應該怎么設計、怎么優化更能滿足他們的訴求，技術處體驗方案。這個過程可以講的內容有很多，篇幅關系不在這里展開，了解體驗分析對B端項目來說是非必須的，大致理解概念即可。
最后就是設計分析，即根據前面的獲取的信息，思考接下來的設計應該完成哪些工作，以及交付什么樣的結果。用更直白的話說，就是足夠了解自己的工作目標和任務。
因為產品需求不會清晰的寫著設計師要完成多少個頁面，畫多少個圖標，制作多少動效，如何和程序員協作等，所以我們要自己對 “確定要做” 的和 “可能會做” 的事情進行分析，才能確定工作量。
以上就是前期準備中要分析的內容，根據項目的大小會花費不同的精力和時間，但不會太多。它們遠沒有大家想象中復雜，準備做的越多，后續設計的效率也就越高，過稿率也會更高。
前面完成分析工作以后，下一步就可以展開設計相關的工作了。而正常設計流程絕不是打開Figma 創建第一個畫布開始一次性畫完所有內容就結束了，而是要分為不同階段，逐步完成不同內容的設計。
首先是交互設計，交互是B端最重要的設計對象，決定產品界面的布局和操作方式。很多新人以為交互是產品經理完成的，但實際上他們制作的產品原型只包含了少量的交互信息或是完全沒有。
所以設計師需要去填補交互信息，即產品怎么使用的規則。如果項目簡單，比如我們這次設計的預定系統，因為操作和交互很少，是可以先把設計做完以后再考慮交互的問題。但如果項目很復雜，就肯定要提前通過原型的方式把交互先確定下來，再完成后續的界面視覺設計。
為什么要做交互設計，我們假設房間的退款流程非常復雜，要經過人工操作和審批還有檢查等十幾個流程才能完成退款，中間有非常多的操作。如果我們不先做交互直接做頁面，很可能會因為各種錯誤、意見要重做，這會造成巨大的時間浪費。在項目中先完成交互的最大貢獻就在提高效率，而不是增加額外的工作量。
確定了功能、布局、交互以后，完成界面就變得輕松了也容易理解，而主要的難點就是你想做出什么風格的界面，就是設計師自己發揮和探索的部分了。
對于小型項目來說，完成界面的設計基本就可以進入后續的交付工作了。但如果是規模較大的項目，就需要再設計過程中制定 ——
項目設計規范
，來確保多人協作或未來迭代時設計的一致性和效率。
而B端項目設計規范主要包含三個部分內容，即 ——
布局規范、樣式規范、組件庫
。
布局規范是B端界面框架、全局組件、響應式規則、柵格參數的標準，這些內容決定了項目的整體布局和框架的一致性。
樣式規范則是UI元素上使用的樣式參數標準，比如色彩、字體、字號、圓角、投影等。在Figma中提供的Style樣式功能，就是解決樣式規范應用的重要工具之一。
組件庫是將設計好的UI元素進行統一整理的地方，因為B端不同B端界面中有大量重復應用的設計元素，所以我們會這些元素進行匯總，存放到固定的位置方便后面復用，而不用每次都重新設計一遍。
Figma提供的Component，就是幫助我們將組件進行存儲并復用的功能，通過它可以很快的完成對同一個組件的匯總、編輯、復用。
設計的最后一個部分，就是動效設計了。但在B端中，這部分的設計需求其實非常少，比如我們本次項目的界面就很簡單，完全不需要畫蛇添足去添加動效。只有在完成界面設計后確實需要制作動效演示的地方，設計師才會去制作相關的動效演示。
所有設計完成且通過團隊的評審以后，那最后的工作，就是協助程序員交付你的設計了。而交付部分包含 ——
標注切圖和設計走查
兩個步驟。
標注切圖就是提供項目的標注文件，讓程序員可以看到設計的具體參數和說明，比如字號大小、間距、色號等等，他們需要根據這些信息完成對頁面開發的參數設置。切圖則是提供圖標、圖片、LOGO等無法用代碼實現出來的視覺元素，它們需要將這些圖形置入到前端項目文件內，才能在頁面中正常顯示。
標注和切圖的實現方式有很多種，今天最主流的方法有兩種，一種是直接使用 Figma的團隊協作完成，另一種是上傳藍湖這類專屬的標注、切圖工具。
最后的設計走查，是前端工程師在完成前端頁面開發以后，設計師去檢查軟件界面的 “還原度”。前端界面開發類似室內裝修的施工，即使有詳細的圖紙最后的施工結果也可能想去甚遠。
所以作為最熟悉設計稿的角色，設計師就需要去檢查開發出來的結果存在哪些問題，并通過特定工具來提交這些錯誤并監督程序員完成對它們的修復，讓前端實現的界面和設計稿盡可能一致。
在B端項目中，往往留給設計走查的時間很少，所以最終上線效果大多和設計稿的差距極大。而專業B端設計師就要依靠自己的經驗，盡可能在整個項目的開展過程中避免兩者的差距過大，這就是另一個話題了。
完成以上這些步驟以后，我們在本次項目的設計工作就基本結束，最終就是等待項目被開發完成并最終上線了。
作者：酸梅干超人
鏈接：https://www.zcool.com.cn/article/ZMTY4MDUwMA==.html
來源：站酷
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
蘭亭妙微（藍藍設計）www.ywne.cn 是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。
