2022-9-26 純純
圍繞應用生命周期的編排設計是一種企業(yè)級技術產品設計策略。
它的核心是要解決設計師很難上手企業(yè)級技術產品，且更加難以找到體驗設計機會點的問題。我們是一群工作在企業(yè)級技術產品領域里的設計師，同時也是掘金者，這篇分享即是我們在企業(yè)級技術產品領域里探索的一些方法總結。
在我們日常工作中，和技術產品 PD 聊需求是一件非常痛苦的事情，他們講的每一個字都認識，但是組合起來就不知道是干什么的了，因此設計師也很難去想象用戶是怎么在用這些功能。
因此相較于 C 端產品來說，B 端的技術產品目前還處于基本可用的狀態(tài)，更談不上什么體驗了。
究其原因，我們總結有三點：
① 這些產品大多數都是由技術來主導，功能優(yōu)先
② 設計在整個流程中都處于非常被動的狀態(tài)
③ 設計與技術之間存在一定的專業(yè)壁壘，技術往往比較抽象難以理解
同時，我們的用戶并不是客戶，用戶不能根據自己的意愿喜好選擇產品。用戶隱藏在企業(yè)內部，設計師日常中很難接觸到真實用戶。另一方面，用戶的技術專業(yè)背景與設計師的專業(yè)存在鴻溝，這使得設計師對用戶需求的理解也不夠深，所以說在這種環(huán)境隔離和語境不通的狀態(tài)下，設計師其實難以和用戶構建同理心。
在這種狹小的設計發(fā)揮空間里，我們能做什么呢？
其實我們設計師有明顯的優(yōu)點：
比較擅長找規(guī)律找方法，有破局意識，從而能夠發(fā)現設計的機會點。
所以我們回過頭看一下之前做過的這些產品和功能，從它們的作用對象、出現時間、用戶目標、用戶行為這四個維度對他們進行歸納和總結。
我們發(fā)現這些產品具有很強的階段性，通過不同的產品來支撐各個階段下的用戶目標。用戶通過產品的功能來實現各種編排動作，例如對應用本身代碼的編排、對應用依賴的底層資源的編排，從而支撐用戶應用的生命周期。
因此企業(yè)級技術產品具有以下四個特點：
階段性
驅動性
流程性
抽象性
首先我們要針對這四個特性進行一輪判斷，了解這個產品的場景，場景下對應的角色，每個角色執(zhí)行的是單線還是多線任務流，以及任務流是由哪些功能支撐。經過這層判斷之后再定位具體問題：
① 每個階段的目標是什么
② 階段下每個角色各自的小目標又是什么
③ 任務要對應用還是應用相關的內容進行編排
④ 產品的功能是如何實現的
當找到這些問題的答案以后，我們就可以對產品的上下游場景進行編排，明確各階段的側重以及上下游場景的限制條件；對角色進行權限分配以及協(xié)作觸點的確定；將任務流從起點到過程再到結果進行梳理；以及最后通過對底層技術的理解，合理編排產品信息架構和界面內容。
為了能夠更加高效的完成以上信息的收集和處理，我們沉淀了 CMTD 四個小工具。
C 是 Collaboration，協(xié)同場景，主要回答四個問題：When、What、Who、Where。
① When：用以明確產品所處階段以及上下游階段，以全鏈路的視角看用戶的完整使用場景，因為產品往往可能只是解決用戶部分場景的問題
② What：定義當前場景的階段目標以及要做的事情
③ Who：當前階段的事情由哪些角色參與
④ Where：這些角色在線上或線下是如何配合協(xié)作的
例如我們要做一個技術產品，通過 Collaboration，我們知道它覆蓋了發(fā)布階段、日常運維階段，目的是把經過測試的應用發(fā)布上線并進行日常維護，主要是運維人員配合研發(fā)人員和發(fā)布經理完成線上的問題排查和線下配置文檔的交接，我們就能比較清楚的知道我們要做的是一個運維平臺。
M 是 multi-role，多角色，主要用以分析產品是由哪些角色共同協(xié)同驅動的。
與 C 端產品不同的是，我們除了對核心角色的自然人屬性進行洞察，還要定義清楚該角色的目標有哪些，目標對應的任務流以及支撐的功能和權限。并且企業(yè)級技術產品往往都不是一個角色就能完全執(zhí)行完成，所以該角色的上下游角色也要摸清之間的協(xié)作觸點在哪里。
多角色的信息我們可以通過在客戶現場或者用戶訪談來收集，并沉淀為用戶角色庫。
基于收集來的用戶信息，來定義我們產品的角色：
T 是 Task flow，任務流。任務流一定是基于一個用戶角色的某個目標，來定義任務的起點-過程-結果。
起點就是界面上用戶的操作入口，過程需要包含觸發(fā)操作、自操作、條件判斷以及是否有協(xié)作角色參與進來，在結果處除了提供結果反饋還要提供下一任務的去向入口，幫助用戶把流程串聯(lián)起來。
任務流可以借助現有流程的走查或按照 T 模型來梳理任務流信息，從而幫助我們更好的定義一條用戶的任務流是如何執(zhí)行的。
例如我們要做的運維平臺的產品，核心角色是運維，他其中的一個目標是為應用創(chuàng)建工作空間。按照 T 模型，我們可以很方便的將這條任務流定義出來。
D 是 deep ，深化。主要從兩個維度展開：技術架構和邏輯原理。這是兩個在做技術產品的過程中經常會接觸到的兩個概念。
在分析技術架構時，我們可以重點關注兩個點：看由哪些功能模塊構成，這些功能之間的靜態(tài)結構，是包含關系還是依賴關系。分析邏輯原理，一是了解這些功能產生的實例，是一對一的關系還是一對多的關系，信息或流量在這些功能模塊之間如何流轉。通過這些分析，我們可以把掌握的功能特征和邏輯規(guī)律。
舉例來說，運維平臺的核心角色運維人員需要為應用創(chuàng)建工作空間，按照梳理出的任務流，用戶需要經過3次跳轉7步完成，那這個是否還有優(yōu)化空間呢？
我們可以從 Deep 深化的角度入手，看這條任務流是由哪幾塊功能支撐的。例如工作空間內包含網絡和安全組，安全組內包含負載均衡和虛擬機。就像我們了解汽車的制動裝置，看到裝置內包含氣室，氣室內包含活塞體、密封墊，密封墊連接在推桿上。
再從邏輯原理圖入口，了解流量會先按照工作空間進行隔離，從工作空間走專有網絡還是經典網絡，網絡將流量分發(fā)到安全組，安全組里的負載均衡會負責調配流量到虛擬機。他們之間層層遞進互相依賴。就像汽油從油箱到達制動裝置，在發(fā)動機里和空氣一起被壓縮燃燒后能量轉化轉送到動力裝置一樣。
通過上面的分析我們了解到這幾個功能其實是緊密關聯(lián)的，用戶沒有必要分散到不同的地方進行添加和創(chuàng)建，完全可以借助流程表單和抽屜把他們串聯(lián)在一起。
因此我們找到優(yōu)化體驗的機會點，把之前需要三次跳轉7步完成的任務流，優(yōu)化到1個入口5步完成。
企業(yè)級技術產品有四個特性：階段性、驅動性、流程性、抽象性。通過 C、M、T、D 四個小工具來幫助我們收集和歸納信息，實現對上下游場景的編排、角色的定義、任務流的編排以及界面的編排。
作者：Ant_Design
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯(lián)系，我們立即更正或刪除。
藍藍設計( www.bouu.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司