在項目中，不怕產(chǎn)生問題，辦法總比困難多！

一、項目背景 Situation/Task

1.大企業(yè)工作臺項目體量龐大，業(yè)務邏輯十分復雜

阿里巴巴大企業(yè)采購簡言之是為大企業(yè)提供專業(yè)的SAAS工具生態(tài)+服務生態(tài)+市場生態(tài)的專業(yè)采購平臺。其中采購SAAS工具服務，即大企業(yè)采購軟件，包括但不限于電子詢報價、電子競價、電子招投標、物料管理、請購、審批系統(tǒng)、內(nèi)部商城、供應商管理、主子賬號管理、協(xié)議采購、交易金融等采購所需的電子信息化工具。具有專業(yè)壁壘高，業(yè)務邏輯復雜，工具生態(tài)體量龐大，協(xié)作角色眾多等特點。

而目前我們平臺對應的采購工具相對單薄，平臺服務大企業(yè)的底層工具建設薄弱，遠不能滿足大企業(yè)采購的需要。因此在2017-2018財年，我們將構(gòu)建全新的互聯(lián)網(wǎng)采購生態(tài)系統(tǒng)，期間將會有幾十個甚至成百上千個龐大的、業(yè)務邏輯十分復雜的專業(yè)工具系統(tǒng)從0到1的孵化并上線。

2.設計、前端、測試資源十分有限

面對業(yè)務產(chǎn)品規(guī)劃藍圖, 成百上千個復雜工具系統(tǒng)將在兩年內(nèi)全新上線，目前大企業(yè)工作臺的資源配置：需求輸入方14人，設計1人，前端13人，后端32人，測試4人，遠遠不夠。其中后臺產(chǎn)品交互視覺UX設計師1人對接上下游63人，更是十分緊張。在產(chǎn)品、設計、開發(fā)、測試資源都十分有限的情況下，如何高質(zhì)且高效地快速支撐業(yè)務發(fā)展需要，讓眾多復雜專業(yè)的后臺工具型產(chǎn)品快速孵化，將成為項目組面臨的迫在眉睫的命題和挑戰(zhàn)。

3.團隊倡導中臺化思維思考問題和解決問題

各協(xié)作方遇到的問題：資源有限，時間緊迫，重復性的工作較多。

1. 需求輸入方：終于理順復雜的業(yè)務邏輯，卻在原型輸出細節(jié)上耗費大量時間，相似的任務場景輸出五花八門，思考時間多，與設計師溝通成本高；
2. 設計師：人少活多，業(yè)務流程復雜，好不容易消化產(chǎn)品，相似的任務場景卻每次要從0到1摳像素地重新繪制；
3. 前端：相似的任務場景總重復開發(fā)，項目周期長，成就感不大，勞民傷財；
4. 測試：相同的邏輯反復測測測，資源消耗大；

二、解決方案 Action—場景中臺抽象規(guī)范及新協(xié)作方式的展開

面對業(yè)務的快速發(fā)展需要，各協(xié)作方的重復工作可通過流程優(yōu)化提高效率。

因大企業(yè)后臺80%任務場景具有強規(guī)律性、可規(guī)范性、高復用性等特點，ued與前端共建，進行了規(guī)范約定，將常用的任務場景進行框架層的抽象，包括但不限于其布局、內(nèi)容、交互、實現(xiàn)，框架下的需求內(nèi)容可靈活定制，不僅大大減少各協(xié)作方對相同場景進行重復性的思考及工程投入，縮短了項目開發(fā)時間，而且保證項目有高質(zhì)量和一致性的產(chǎn)出。

場景中臺化后，ued重點則更加聚焦在需求及體驗本身，幫助產(chǎn)品把用戶體驗打磨的更好。

具體開展步驟：STEP1場景分類（識別并歸攏）；STEP2場景細化；STEP3場景實現(xiàn)；

STEP1：場景分類（識別并歸攏）

我們通過大企業(yè)云工作臺中表單的數(shù)據(jù)流向，歸納出3種任務場景：

• 數(shù)據(jù)輸入型表單 包括：單表表單，配置表單，頭行表單，樹狀表單，分步表單，導入…
• 數(shù)據(jù)管理型表單 包括：管理列表—行，管理列表—卡片…
• 數(shù)據(jù)展示型表單 包括：detail單表結(jié)構(gòu)，detail頭行結(jié)構(gòu)，導出，結(jié)果展示，錯誤…

STEP2：場景細化（舉例說明）

1.數(shù)據(jù)輸入型表單

單表/配置型表單數(shù)據(jù)輸入

For 前端：頁面寬1200px標準尺寸的基礎上自適應，橫向兩端預留20px，縱向標題距頂10px，標題高30px，與Tab區(qū)域間距20px，內(nèi)容行項數(shù)（按需定制），標題列120px；若需配置，右側(cè)配置操作區(qū)域160px（可選）。

For 需求方：提供案例和模版，需求方可直接基于框架內(nèi)更換內(nèi)容，重點關(guān)注內(nèi)容，無需care像素細節(jié)。

2.頭行輸入型

For前端：頁面寬1200px標準尺寸的基礎上自適應，橫向兩端預留20px，縱向標題距頂10px，標題30px（內(nèi)容與左導航保持一致），tab/頁面級操作30px，頭公共基礎信息可一欄或兩欄布局，標題列120px，內(nèi)容列440px。行項列表單行時，高度40px，兩行內(nèi)容時60px，10行，翻頁區(qū)高度30px, 翻頁區(qū)域以下為自定義附屬信息，各功能模塊縱向間距10px。

For 需求方：提供案例和模版，需求方可直接基于框架進行內(nèi)容更換，重點關(guān)注內(nèi)容，無需care像素細節(jié)。

3.數(shù)據(jù)管理型

For 前端：頁面寬1200px標準尺寸的基礎上自適應，橫向兩端預留20px，其他詳見規(guī)范標注。

For 需求方：提供案例和模版，需求方可直接基于框架內(nèi)更換內(nèi)容，重點關(guān)注內(nèi)容，無需care像素細節(jié)。

除此之外，為了保證前端順利代碼化，我們根據(jù)現(xiàn)有后臺內(nèi)容盤點歸納了常用的表單列寬尺寸，提供了50，80，100，120，180，250px寬可供選擇，同時，每一列可設定一欄為主維度信息，主維度信息的列寬自適應（flex），不受以上幾種尺寸約束。列寬數(shù)量以不激活橫向滑動為原則，需要需求側(cè)需求輸入時能夠有所取舍，將重點項進行展示。

4.樹狀表單

For 前端：頁面寬1200px標準尺寸的基礎上自適應，橫向兩端預留20px。其他詳見標注。

For 需求方：提供案例和模版，需求方可直接基于框架內(nèi)更換內(nèi)容，重點關(guān)注內(nèi)容，無需care像素細節(jié)。

5.大企業(yè)工作場景常用關(guān)系組件

• 輸入input，常用的有Simple Input，Relationship Input，Autocomplete Input，即簡單輸入，關(guān)系聯(lián)想輸入，自動填充輸入；
• 選擇Select，常用的有Static select，Search select，Dynamic select，即靜態(tài)選擇，帶搜索的選擇，動態(tài)聯(lián)想選擇；
• 日期選擇器Date picker，常用的有Single picker，Range picker，單日期選擇，區(qū)間日期選擇等等，諸如此常用的場景化組件，進行歸納規(guī)范；

STEP3：場景實現(xiàn)

通過以上任務細化并定義規(guī)范后，前端進行代碼化的實現(xiàn)。當有相似需求產(chǎn)生時，可復用抽象的框架進行內(nèi)容替換。

三、效果 Result

原始流程：需求方根據(jù)業(yè)務發(fā)展需要，規(guī)劃產(chǎn)品，與用戶及業(yè)務方多輪共建，多輪需求打磨之后進行需求評審；UED接到需求，消化需求，從體驗側(cè)進行重新梳理，然后從0繪制，開發(fā)從0開發(fā)，測試從0寫測試用例進行測試，UED進行設計驗收。

場景中臺化后初步階段：中臺將元件、組件進行標準化，各方約定的組件元件不需要重新定義，反復造輪子。

場景中臺化后進階階段：當任務場景規(guī)范化后，UED在需求階段“往前站”與業(yè)務共創(chuàng)，聚焦體驗規(guī)劃，協(xié)助pd產(chǎn)出用戶體驗佳的產(chǎn)品需求，各方評審，其中可用場景規(guī)范的需求，只需根據(jù)已代碼化的框架進行在線文字內(nèi)容替換，即可上線。

最初的協(xié)作流程優(yōu)化后各方的投入時間表：

原先的協(xié)作流程：假設總共20張頁面，總項目時間100小時，每個頁面理邏輯加繪制需要消耗5個小時，需求邏輯和體驗視角的邏輯關(guān)注精力被極大的分散，核心體驗鏈路和頁面在均分精力下體驗得分可能只有60分。

優(yōu)化后的協(xié)作流程：可復用場景規(guī)范化的頁面無需再重復耗費人力投入，還是20張頁面，其中80%的頁面可用規(guī)范的場景進行輸出，那么總項目時間100小時不變的情況下，只需要核心聚焦在4張核心體驗頁面上，那么設計師在每張頁面的關(guān)注時間由5小時變?yōu)?5小時，有充足的時間挖掘每個頁面的體驗痛點和創(chuàng)新方案，核心體驗鏈路和頁面在聚焦精力下體驗得分可上升到90分。

場景中臺各方共識開始應用后，UED從畫圖為主的工作者變成真正的體驗思考者，相同時間內(nèi)，核心體驗問題得到更充分的關(guān)注，項目整體質(zhì)量和設計師成就感都會增加。

四、當前進展及未來暢想

1.當前實施情況

我們對目前大企業(yè)工作臺中場景進行了抽象和歸類，優(yōu)先規(guī)范并代碼化了單表結(jié)構(gòu)、頭行結(jié)構(gòu)、管理結(jié)構(gòu)的表單，規(guī)范后的內(nèi)容對上下游伙伴進行講解，并在若干項目中進行實踐。在初步實踐過程中，協(xié)作伙伴們遇到的疑慮：

1）需求輸入者最大的擔憂：會不會增加工作成本？

答：不會。場景中臺前期實施時，我們會對目前已有規(guī)范進行提前講解，協(xié)助業(yè)務伙伴在輸入需求前了解規(guī)范，并提供提供案例sketch/axure的模版，當需求方有此類結(jié)構(gòu)需求時，直接基于模版進行內(nèi)容替換，這樣繪制demo的環(huán)節(jié)更加便捷準確。并且設計師在接到需求后，會對需求進一步進行規(guī)范上的歸攏。

長遠來看，當業(yè)務伙伴了解并熟悉了模版，有相似需求時直接進行內(nèi)容替換，減少了需求輸入時相似任務場景再思考的成本，也減少了不必要的溝通和設計師歸攏再設計的成本。

2）UED：當前需要抽象場景組件，進行規(guī)范產(chǎn)出，協(xié)助前端代碼化，協(xié)助需求輸入規(guī)范化；長遠來看，已規(guī)范化的場景無需重復設計。

3）前端：當前需要抽象場景組件，進行代碼化。長遠來看，已規(guī)范化的場景無需重復架構(gòu)開發(fā)。

4）測試：設計師還會不會出稿件？

答：會。當前設計師會基于需求稿的基礎上進行規(guī)范修正，進行最終的統(tǒng)一交付。長遠來看，已規(guī)范化的場景部分達成共識后，需求輸出無需重復測試。

2.接下來場景將會結(jié)合業(yè)務發(fā)展進行豐富和擴展

會繼續(xù)豐富場景組件，將會新增：管理表單卡片式，步驟漸進式表單，樹狀表單等。

3.未來暢想

將場景規(guī)范代碼化后，搭建一個在線需求生成工具，業(yè)務方有相似需求時，直接在線進行內(nèi)容錄入，再進行需求評審，根據(jù)各方建議進行需求微調(diào)，后端開發(fā)完成后即可上線。

五、價值總結(jié)及反思

場景中臺化的協(xié)作方法適用于具有強規(guī)律性、可規(guī)范性、高復用性的業(yè)務，通過設計師和前端共建將相似的任務場景（布局、組件、內(nèi)容等）進行框架抽象，并代碼化。然后將規(guī)范后的框架在項目組進行講解，多方達成共識。

需求輸出時，將變得有章可循，無需浪費相同布局組件重新思考的時間，設計師面對相同的場景無需重新設計，前端無需重新開發(fā)，測試無需重復測試。使項目組各個協(xié)作成員的效率最大化，將精力回歸到需求本身，幫助業(yè)務伙伴在相同時間內(nèi)，將需求打磨的更加合理，體驗更加優(yōu)良，縮短項目整體開發(fā)時間，并且有效解決了資源少，重復性可歸納性強的需求體量過于龐大且邏輯十分復雜的客觀問題。

場景中臺規(guī)范化實施后，工作臺具有“流水式”統(tǒng)一高效且高質(zhì)的輸出，節(jié)約了各方不必要的投入時間，使項目整體提效。但對設計師而言，要始終帶著思辨的視角看問題，當遇到新的業(yè)務場景時，我們需要反思當前的規(guī)范是否合理，有沒有更好的體驗方式，不斷對場景規(guī)范進行升級和重塑，以保持思辨和創(chuàng)新的核心競爭力。在項目中，不怕產(chǎn)生問題，辦法總比困難多！希望本篇能對面臨相同“困境”的同行產(chǎn)生幫助作用。

作者：嵐馨（瀾莘）

來源：阿里巴巴UED

題圖來自，基于CC0協(xié)議