相信有那麼一天,我們將可以像畢凱艦長一樣用嘴巴叫所有主機做事!


Cheng Wei Chen



Agile Tour Taipei 2015 筆記與心得(四)| 邁向 Scrum of scrums - 杜秉穎、練出精實UX - Mike Chou

接續同系列文章《Agile Tour Taipei 2015 筆記與心得》,本文繼續記錄 Agile Tour Taipei 2015 下午的議程筆記與心得。

下午選擇的是 Track 2,當時在午飯時間苦惱了一陣子,雖然一度很受到 Track 1「How to apply Agile to Growth Hack - Someda Takashi, 染田貴志」的議題吸引想要先聽 Track 1 再換場 Track 2,但 Track 2 的場地視野不佳、座位也少,考慮到換場一定搶不到好位子,因此最後整個下午都留在 Track 2。

邁向 Scrum of scrums - 杜秉穎

講者簡報已經釋出,可以前往線上觀看

下午第一場是「邁向 Scrum of scrums - 杜秉穎」,但必須要先自首,因為精神不佳,在這場議程中一度陷入昏迷,所以記錄到的內容超少。

這場議程在劇情上是接續上午「如何在組織內有效引領敏捷變革 - 蕭存喻」的案例,也就是遊戲橘子內部的敏捷變革經驗分享。

首先講者向聽眾問了幾個問題:

  • 團隊類型?
    是新創、公司自開發產品、接外包或其他。
  • 團隊規模?
    5 ~ 50 以上是落在哪一個區間。
  • 開發方法或流程?
    是 Waterfall、Being Agile、Doing Agile或自以為 Agile。

透過問題開場之後,講者開始進入正題,前面的題目也是講者在爲自己鋪梗,因為講者所處的團隊正是經歷由小變大與持續引入敏捷變革的過程。

在他們持續引入的中途遇到了一個狀況,即是乍看之下「團隊好像很 Agile」,感覺該做的都有做 (testing、CI、CD),但隱約還是感覺有些問題,例如會議時間很長、沒效率且難以達成共識、對 sprint failed 好像沒感覺又好像很害怕。因此驅使他們決定新一波的敏捷改革。

(然後不好意思,接著我就開始昏迷了⋯⋯)

最後只記得自己聽到一個重點:
  • Doing agile ≠ Being agile

即是再一次呼應講者一開始的提問,你們的團隊目前是 Doing Agile 還是 Being Agile 呢?


練出精實UX - Mike Chou

繼續記錄下午第二場議程「Lean UX」,講師簡報也已釋出,可線上瀏覽,有興趣者務必閱讀,個人覺得這是用來認識 Lean UX 相當不錯的簡報。

這場議程是由來自趨勢科技的介面設計師 Mike Chou 帶來的精彩分享,內容主軸即是與大家分享「什麼是 Lean UX」。

當 Lean 及 Agile 的精神越來越普遍之後,開始就有各種將「概念」跨界應用的趨勢,其中 Lean UX 就是一個案例,當 Lean 及 Agile 的精神碰上了傳統的 UX 設計流程後,就產生了 Lean UX 這一個新的火花。

首先講者從 UX Design 當前的挑戰開始說明,在傳統的 UX 設計流程中目前有幾個問題:
  • 類瀑布的設計流程
    因為需要經過「了解使用者」、「找到問題」、「研究歸納」、「原型設計」、「測試」⋯⋯等流程,所以需要花費很多的時間,導致 UX 設計會拖慢整個專案時間。
  • 繁瑣且繁重的設計文件
    UX 設計師不是藝術家,他的工作內容有很大的比例是在產出文件。透過文件詳細規範設計的細節,字型、顏色、元件外觀、大小、互動流程⋯⋯等。偏偏文件不做又不行,畢竟其他人可是按著文件來工作的。因此講師還特別強調文件不只是多而繁瑣,文件還必須是「完美且完整」才行。
  • 使用經驗的價值反被文件完整度來衡量
    延伸前一點繼續說明,所以 UX 設計師變成了一個「文件產出者」,最好能一直產出「完美且完整」的文件。但這不應該是 UX 設計的價值吧?UX 設計真正的價值應該是提供優良且合適的「使用經驗」、「使用者體驗」。
  • 使用經驗變成了瓶頸
    因為要驗證一個 UX 設計是否良好,需要進行使用者測試,但一測下去幾周的時間就過去了,而專案經理似乎沒有這麼多時間讓你可以慢慢的去測試 UX。
  • 耗時也造成不必要的浪費
    接續前面幾點,為了要確實的驗證 UX,就需要消耗一定的時間,在過程中還會製作出多種 Prototype。這些被消耗的時間與未能成為最終結果的 Prototype 就形成了一種浪費。

基於上述的問題,於是就有人提倡了 Lean UX 的概念,這是由 Jeff Gothelf 所提出。Lean UX 其實就是將原本的 UX 設計流程加入了 Lean startup 的原則及精神之後產生的新東西。目的是讓 UX 的設計實作也能「精實且敏捷」。而 Jeff Gothelf 也將他實際運用 Lean UX 的經驗寫成《LEAN UX》這本書。(似乎有簡中版,有興趣的勇者可以考慮買來看看。)

再來講者繼續說明 Lean UX 三大基礎,分別如下:

首先是 Design Thinking Process

Design Thinking Process 是由知名的設計公司 IDEO 所提出,基本上 Lean UX 以此作為基本架構,並在此基礎上修改演進而成。因此 Lean UX 的流程與 Design Thinking Process 是非常相像的。

再來是 Agile Development,這分為四點說明。
  • 沒有英雄只有團隊
    在傳統 UX 實踐中,UX 設計師有一點像是英雄的角色,最終由他專門提出解決方案。但在 Lean UX 希望是團隊作業,因此在流程中有所調整,不再強調英雄而是團隊,讓成員都參與在其中。
  • 降低「產出 Output」,著重「結果 Outcome」
    前面提過傳統 UX 設計要提出「完美而完整」的文件,彷彿整個團隊都只是在等文件產出。而 Lean UX 則要改變這個狀況,著重於結果 Outcome。
    (講師後續會再特別說明 Outcome 與 Output 的差異。)
  • 不必功能完整,只要驗證式學習
    如同 Agile 軟體開發定期會有結果並驗證產生新的回饋,團隊再依據回饋進行修正。而 Lean UX 也是如此,透過反覆式的設計流程,每一次設計結果都會經過使用者驗證,得到回饋再繼續修正,如此循環。
  • 不再死死跟隨計劃,而是快步趕上變化
    簡單來說就是敏捷起來,快速地對改變作出反應。不再是傳統 UX 設計那種類瀑布的設計流程,而是能敏捷快速的回應「改變」。

最後是 Lean startup,這裡強調三件事情:

第一件是「驗證式學習 Validated Learning」。Lean startup 要你先產生一個 MVP 之後去驗證它,從中取得回饋並學習,再繼續下一步。就像簡報 P.19 繪製的流程「build -> measure -> learn (循環)」。對照至 Lean UX 也同樣強調三個步驟「make -> check -> think (循環)」,很容易能理解,因為是同樣的概念,這也是在做「驗證式學習」。

第二件是「減少浪費」。關於「浪費」,講者前面也一再提過,而 Lean UX 就是借用 Lean startup 的 MVP 的概念,不用一開始就打造全面且完整的介面,僅打造所需的介面,將重點放在核心的驗證。

最後是「跨領域合作 collaboration」,就像 Lean startup 常常要一個人身兼數職。Lean UX 也是如此,每個人可能不再只有一個身份,皆需要「跨領域合作」。

分享完 Lean UX 三大基礎後,講者繼續跟大家分享「Lean UX 的架構」。架構很單純就如簡報 P.21,Lean UX 是以結果 (Outcome) 為導向,反覆進行「ASSUMPTIONS <-> MVP <-> Feedback」。

因為再次提到了「結果 Outcome」,講者特別用簡報 P.22 舉例說明「結果 Outcome」與「產出 Output」的差異。
  • 我們將開發單一登入的功能 = Output
  • 我們想要增加新使用者註冊的量 = Outcome

簡單一點可以這樣理解,你做出一個 Output 是希望能帶來一個 Outcome。沒有 Outcome 的 Output 會不清楚它價值爲何。另外就是 Outcome 同時也是用來驗證 UX 的標準。

再來講到流程「Lean UX 的流程」,就是簡報 P.23。簡報左半部是 Lean UX 的流程,右半部黑色的區塊是 Desin Thinking Process ,講者將它們同時列出來好讓大家可以對照比較。

另外講者也特別說明 Assumptions 與 Hypotheses 的差別,因為乍看之下兩者的中文翻譯都是「假設」。但 Assumptions 指的是「你所相信的事實」(這是一種假設),而 Hypotheses 則是對 Assumptions 作出更詳細的說明並加上可量測的標準。

接著講者就一一詳細的說明 Lean UX 的每個流程,因為有太多細節我就不一一記錄了。


最後補充一些其他的內容:

中間有人插入問了一個問題:「工程師何時加入 UX 開發流程之中?會不會有人力資源浪費?因為這與工程師好像無關?」
講者的回答:「一開始就加入。這其實是觀念上的改變。就像 DevOps 一樣。」

再問:「要把 Dev 抓進 UX 設計流程中?你要如何說服老闆這件事?」
再答:「根據趨勢科技的經驗談,只要把老闆與 Dev 實際抓進來看看,他們就會懂了。」

講者也推薦大家去搜尋觀賞「IDEO 改造 shopping cart 的經典案例」及「design thinking」的相關影片。

另外講者有提到傳統的 UCD 需要較長的準備與時間才能啟動,而 Lean UX 則能改善這一點。Lean UX 是直接根據客服部門、業務、相關人提供的資料即作出 Assumptions,並啟動後續的流程,所需的準備與時間較少。


心得

很慚愧的說,因為中途昏迷所以對「邁向 Scrum of scrums」並沒有留下太多深刻的印象,不過最近因為連續聽了許多經驗分享,幾乎都會聽到幾個類似的建議:
  • 不要妄想一步登天
  • 不要為了想做而做
  • 不要強迫推動,要用引導的
  • 要讓團隊自發性的前進
  • 要 Being 不是 Doing 
  • ⋯⋯

這些建議都是在回應「文化與習慣」及「人」這一類經常被提出來的問題。看來在討論到該用哪種「工具」或「框架」之前,先化解這些問題已是一種先決條件了,或者至少也要一邊前進一邊化解才行。

Lean UX 這一場相當的有意思,因為這就像是將「精實」與「敏捷」的精神放入其他領域的案例。在競爭如此激烈、每天都必須求新求快的時代,各行業都需要「精實」與「敏捷」的輔助,如此一想就覺得會出現 Lean UX 也是必然,不過就是時間早晚而已,就像 DevOps 的出現一樣。


此系列文章傳送門:



沒有留言:

張貼留言

不歡迎留言打廣告,所以有進行留言管理,敬請見諒。