UXPin - Agile UX 線上直播筆記-1

這是一篇關於敏捷開發中 UX 該如何調整節奏、實作的筆記

UXPin 是一個製作動態 Prototyp 的工具,常用於 Sketch 完成 UI 的後續處理上,為了推廣自家產品 UXPin 經營了一個 Blog 做內容行銷,而因為快速的 Prototype 和高效的協作等特質都與敏捷開發高度相關,所以 UXPin 的內容中也有不少 Agile 相關的議題,最近他們更是由CEO親自出馬和邀請 Dell EMC 設計高管一起分享 Agile UX 的實行細節

要特別注意的是,UXPin 的商業模式面向大企業而非小型新創,因此這兩場分享的內容也偏向給大公司參考。

兩場演講的內容分別是:
1. Agile UX Documentation Best Practices (這篇先講這段)
2. The Dual-Track Agile UX Process at Dell EMC (敬請期待下一篇)

Agile UX Documentation Best Practices

這場是由 UXPin 的 CEO 分享,首先他表明 Agile 和 UX 確實常常遇到合作困難, Pure Agile 和 Pure UX 間有不少矛盾之處,首先是關於兩者的理論脈絡:

Agile:應用於團隊、快速交付軟體、持續交付軟體細部
UX:應用於使用者、交付對的產品、願景
(我的解讀:在此的願景有點像是 User Story mapping 中的 Skeleton)

在 UXPin CEO 看來,Agile 本身的教條是沒有重視使用者體驗的
(如下,100%的效率,0%體驗)

不過,如果我們把前面的黑白圖組合起來,可以得到這個新的結果,也就是Agile UX 想要達到的目標(的一部分XD):
●高效協作以達成用戶滿意
●在時限內交付對的產品
●交付願景中重要的軟件項目

OK,那要如何導入Agile UX 進入組織呢?雖然有點歪樓,但這個導入流程中其實包含了不少 designer 和 developer 協作時需要的文件,這也是為何講者從原先的題目「Document」轉向了「Recipe」,講者把步驟大概分成了3+2+1個部分

1.異步迭代
2.三權分立
3.按表操課
4.輕量文件
5.文件共享自動化
6.Agile UX的未來

1.異步迭代

上面這張圖在我看來,跟 Dual-Track 和 Parrarel Sprint 有 87% 像,也是幾乎每次談到 Agile UX 都會搬出來的項目,因此我只簡短解釋:
若 UI 設計稿還未產出,理所當然是無法進行開發的,這時候 Agile 常見的配套作法就是在正式開發開始前的 " iteration 0 "進行"iteration 1"開發項目的設計,而等”iteraiotn 1"開發產出後,UX 人員就可以在"iteration 2"進行市場反饋的數據蒐集並進行”iteraiotn 3"開發項目的設計

迭代中的內容

每個 Sprint 內 designer 都會把需要開發的項目,從研究、設計、原型、測試等工作跑過一次

當然這個方法只是一個比較通用的框架,實際上要如何使用還是要看產品性質做調整,所以講者也建議:
1.以 Team 能最大化愉悅&高產能為目標優化調整方式
2.不要把所有的 Research 都集中在 Sprint 0 進行
 (會變瀑布流我幫講者補充XD)

2.三權分立

如上圖,這三者需要有同等的話語權,否則設計很容易被 PM 或技術的顧慮給犧牲,體驗與這兩者有著同等高度,如果沒有獲得應有的重視,不管是 Designer 的賦權賦能或是自組織等等敏捷核心原則都會受到影響
這一部分要討論可以討論到很深,但真遇到大組織頭頭說的算的狀況恐怕也是無解,講者一個 BJ4 的節奏帶過去了

3.按表操課

在這個部分,初導入 Agile 給團隊不僅需要等待大家適應,也需要給大家一個明確、完整的流程(確實聽過滿多跑半套的公司下場都很慘),講者舉了自身公司所使用的工作流程如下:

其中有趣的是他特別標出了UXPin、Github、Propad和Target Process,如果你的公司在某一環節遇到問題,或許可以試試這些軟體,說不定能幫你突破瓶頸呢!

另外要記得,初衷的 Why 是為了透明化和高效合作!

4.輕量文件

首先講者搬出 Agile 的教條,可用的軟體大於詳盡的文件

不過講者認為還是要看狀況而定,為了達成某些目的(下圖),講者會建議以文件記錄必要之資訊,而這些項目盡量是 2-3 個月內範圍的計畫即可,其內容和目的大致為:

●建立共識與同步團隊的方向、目標
●定義開發項目的預期成果和驗收 KPI
●定義開發項目的成功標準

為了避免文件出現 Waterfall 的狀況,因此講者給出了幾點遵守原則:

1.最小化,只撰寫必要之資訊
2.有效性,避免撰寫的像說明書般冗長
3.流通性,要能夠讓所有團隊成員輕鬆了解內容
4.以開發為中心,要讓開發能夠更容易且快速

文件實例

講者提供了他自己常用的撰寫方式給大家做為範例,若有興趣的話也可以輸入下圖中的網址進入UXPin 官網下載,這份文件講者簡稱之為:PRD,Product Requirements Document,強調這個名稱也是因為這能幫助我們更聚焦到底文件應該包含哪些內容、避免過於冗長

另一種在傳統 Waterfall 常出現的"Old Fasion 文件",包含了太多細節、時間跨度可能長到一整年的開發、有可能開發完後才發現市場不買單等等,因此講者認為”Old Fasion 文件"是我們需要避免的(如下圖)

5.文件共享自動化

這一段講者分享了如何把文件由設計端高效低成本的傳遞給開發端,分別分享了自動化分享的文件內容、設計系統、軟件實例等等

首先他分享了,哪些東西會需要文件共享給工程師或是建立紀錄,包含:
●實行的準則
●設計可能的取捨、極端案例、合理性等等
●過去使用者測試得到的反饋

接著說到,有三點原因會讓我們需要建立開發文件:
●讓開發變得更容易更高效
●建立對產品的共識,避免來回溝通
●確保設計的一致性

設計系統

設計系統顧名思義就是建立一個有架構的設計準則,讓設計和開發都能維持一致性並避免事後的來回修正

如上圖,一個好的設計系統會包含許多設計系向的準則,大致又可以分為三類:設計風格、設計模式、操作規則等等

軟件實例

UXPin CEO 分享了他們自身應用的設計系統如下圖:

首先針對 UXPin 自身的服務,講者提出過去的做法Designer 常需要將 UI 的細節標註的到處都是,畫面凌亂不便溝通,麻煩、容易疏失也低效率

如果是好的方式,應該要在設計的當下就由軟件自動化產生文件資訊,如下圖自動將設計的尺寸、位置、顏色、甚至代碼都輕鬆呈現出來(圖為 UXPin 的產品)

再來為了要讓工程師能同步接收到資訊,講者自身公司使用的是這套叫做 
X Confluence 的軟件,能夠自動高效的將文件記錄並同步更新給團隊成員

大致使用這些軟件就能逐步建立出前述提到的設計系統了

6.Agile UX的未來

最後 UXPin 的 CEO 分享了他對於未來 Agile UX 的看法以及 UXPin 的願景:

上面這幾項都有點深,我也因此決定不翻譯成中文

不過,我的解讀是,未來工具軟體將持續優化 Agile 中設計和開發的溝通,透過將 Design Pattern 不斷的加入系統,設計開發間將會更加的同步,斷層和落差會越來越小,而同時敏捷也會因應這個狀況進化,讓設計和開發都會圍繞著溝通系統做出調整!

※本文以上圖片接來自於 UXPin 線上直播,有興趣者可於 UXPin 網站搜尋相關資訊:https://www.uxpin.com/