編輯導語：針對設計與技術之間的壁壘存在、設計師難以上手企業級技術產品的問題，圍繞應用生命周期開展的編排設計可以有效解決這些困難，本篇文章里，作者總結了編排設計的方法與流程策略，讓我們一起來看一下。

一、什么是圍繞應用生命周期的編排設計

圍繞應用生命周期的編排設計是一種企業級技術產品設計策略。

它的核心是要解決設計師很難上手企業級技術產品，且更加難以找到體驗設計機會點的問題。我們是一群工作在企業級技術產品領域里的設計師，同時也是掘金者，這篇分享即是我們在企業級技術產品領域里探索的一些方法總結。

二、當設計遇上技術

1. 工作現狀

在我們日常工作中，和技術產品 PD 聊需求是一件非常痛苦的事情，他們講的每一個字都認識，但是組合起來就不知道是干什么的了，因此設計師也很難去想象用戶是怎么在用這些功能。

因此相較于 C 端產品來說，B 端的技術產品目前還處于基本可用的狀態，更談不上什么體驗了。

2. 分析原因

究其原因，我們總結有三點：

1. 這些產品大多數都是由技術來主導，功能優先；
2. 設計在整個流程中都處于非常被動的狀態；
3. 設計與技術之間存在一定的專業壁壘，技術往往比較抽象難以理解。

同時，我們的用戶并不是客戶，用戶不能根據自己的意愿喜好選擇產品。用戶隱藏在企業內部，設計師日常中很難接觸到真實用戶。

另一方面，用戶的技術專業背景與設計師的專業存在鴻溝，這使得設計師對用戶需求的理解也不夠深，所以說在這種環境隔離和語境不通的狀態下，設計師其實難以和用戶構建同理心。

3. 能做的事

在這種狹小的設計發揮空間里，我們能做什么呢？

其實我們設計師有明顯的優點：比較擅長找規律找方法，有破局意識，從而能夠發現設計的機會點。

三、企業級技術產品設計探索

1. 發現規律

所以我們回過頭看一下之前做過的這些產品和功能，從它們的作用對象、出現時間、用戶目標、用戶行為這四個維度對他們進行歸納和總結。

我們發現這些產品具有很強的階段性，通過不同的產品來支撐各個階段下的用戶目標。用戶通過產品的功能來實現各種編排動作，例如對應用本身代碼的編排、對應用依賴的底層資源的編排，從而支撐用戶應用的生命周期。

因此企業級技術產品具有以下四個特點：

1. 階段性；
2. 驅動性；
3. 流程性；
4. 抽象性。

2. 提出策略——圍繞應用生命周期的編排設計

首先我們要針對這四個特性進行一輪判斷，了解這個產品的場景，場景下對應的角色，每個角色執行的是單線還是多線任務流，以及任務流是由哪些功能支撐。經過這層判斷之后再定位具體問題：

• 每個階段的目標是什么；
• 階段下每個角色各自的小目標又是什么；
• 任務要對應用還是應用相關的內容進行編排；
• 產品的功能是如何實現的。

當找到這些問題的答案以后，我們就可以對產品的上下游場景進行編排，明確各階段的側重以及上下游場景的限制條件；對角色進行權限分配以及協作觸點的確定；將任務流從起點到過程再到結果進行梳理；以及最后通過對底層技術的理解，合理編排產品信息架構和界面內容。

為了能夠更加高效地完成以上信息的收集和處理，我們沉淀了 CMTD 四個小工具。

3. 策略詳解

C 是 Collaboration，協同場景，主要回答四個問題：When、What、Who、Where。

• When：用以明確產品所處階段以及上下游階段，以全鏈路的視角看用戶的完整使用場景，因為產品往往可能只是解決用戶部分場景的問題。
• What：定義當前場景的階段目標以及要做的事情。
• Who：當前階段的事情由哪些角色參與。
• Where：這些角色在線上或線下是如何配合協作的。

例如我們要做一個技術產品，通過 Collaboration，我們知道它覆蓋了發布階段、日常運維階段，目的是把經過測試的應用發布上線并進行日常維護，主要是運維人員配合研發人員和發布經理完成線上的問題排查和線下配置文檔的交接，我們就能比較清楚地知道我們要做的是一個運維平臺。

M 是 multi-role，多角色，主要用以分析產品是由哪些角色共同協同驅動的。

與 C 端產品不同的是，我們除了對核心角色的自然人屬性進行洞察，還要定義清楚該角色的目標有哪些，目標對應的任務流以及支撐的功能和權限。并且企業級技術產品往往都不是一個角色就能完全執行完成，所以該角色的上下游角色也要摸清之間的協作觸點在哪里。

多角色的信息我們可以通過在客戶現場或者用戶訪談來收集，并沉淀為用戶角色庫。

基于收集來的用戶信息，來定義我們產品的角色：

T 是 Task flow，任務流。任務流一定是基于一個用戶角色的某個目標，來定義任務的起點——過程——結果。

起點就是界面上用戶的操作入口，過程需要包含觸發操作、自操作、條件判斷以及是否有協作角色參與進來，在結果處除了提供結果反饋還要提供下一任務的去向入口，幫助用戶把流程串聯起來。

任務流可以借助現有流程的走查或按照 T 模型來梳理任務流信息，從而幫助我們更好地定義一條用戶的任務流是如何執行的。

例如我們要做的運維平臺的產品，核心角色是運維，他其中的一個目標是為應用創建工作空間。按照 T 模型，我們可以很方便地將這條任務流定義出來。

D 是 deep ，深化。主要從兩個維度展開：技術架構和邏輯原理。這是兩個在做技術產品的過程中經常會接觸到的兩個概念。

在分析技術架構時，我們可以重點關注兩個點：看由哪些功能模塊構成，這些功能之間的靜態結構，是包含關系還是依賴關系。

分析邏輯原理，一是了解這些功能產生的實例，是一對一的關系還是一對多的關系，信息或流量在這些功能模塊之間如何流轉。通過這些分析，我們可以把掌握的功能特征和邏輯規律。

舉例來說，運維平臺的核心角色運維人員需要為應用創建工作空間，按照梳理出的任務流，用戶需要經過3次跳轉7步完成，那這個是否還有優化空間呢？

我們可以從 Deep 深化的角度入手，看這條任務流是由哪幾塊功能支撐的。例如工作空間內包含網絡和安全組，安全組內包含負載均衡和虛擬機。就像我們了解汽車的制動裝置，看到裝置內包含氣室，氣室內包含活塞體、密封墊，密封墊連接在推桿上。

再從邏輯原理圖入口，了解流量會先按照工作空間進行隔離，從工作空間走專有網絡還是經典網絡，網絡將流量分發到安全組，安全組里的負載均衡會負責調配流量到虛擬機。他們之間層層遞進互相依賴。就像汽油從油箱到達制動裝置，在發動機里和空氣一起被壓縮燃燒后能量轉化轉送到動力裝置一樣。

通過上面的分析我們了解到這幾個功能其實是緊密關聯的，用戶沒有必要分散到不同的地方進行添加和創建，完全可以借助流程表單和抽屜把他們串聯在一起。

因此我們找到優化體驗的機會點，把之前需要三次跳轉7步完成的任務流，優化到1個入口5步完成。

四、總結回顧

企業級技術產品有四個特性：階段性、驅動性、流程性、抽象性。通過 C、M、T、D 四個小工具來幫助我們收集和歸納信息，實現對上下游場景的編排、角色的定義、任務流的編排以及界面的編排。

期望通過分享，能夠幫助到企業級技術產品的設計師們在未來的設計之路上越走越輕松，越走越有趣~

作者：壹樂，螞蟻集團設計師

本文由 @Ant Design 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議