文/ Nor
這真是一場有趣的體驗，還沒有這樣參與一場領域的年會。
去年第四季我開始走訪各地跟敏捷相關的團隊與社群，仔細回憶了一下，其實在 2015 就在好友 Max Lai 的引薦下，在台中的社群帶過一場 Lean UX 的工作坊，算是我跟敏捷的第一次接觸，但其實沒有跟敏捷式開發有進一步的協作。直到今年第二季知道要來給 40 分鐘的 talk，我加速了我的敏捷取經之旅，走訪了 5 家公司、4 個專業人士、以及參與 4 場社群工作坊。
基本上我並不是對於敏捷開發特別熟悉的人，自認目前還是個入門者，但是我收集到的問題，應該比一般人多，其中大部分的問題，其實不是在 Agile 與 UX 的協作上，而是開發團隊對於用戶研究的預期與實際取得的成果有落差，這些問題從我的角度來看，其實都不存在技術或是領域知識的問題，而是用戶研究從業人員的經驗問題，追根究柢還是人的問題。
越後期才修正錯誤成本越高
在分享之前，我對聽眾的預期是四成的敏捷圈朋友，二成 UX 圈，三成管理階層，以及一成的散客。所以我一開始的切入點，把 UX 定位在幫專案省錢，Agile 開發幫專案賺錢。立論點其實是反映現實面，用戶研究有助於提早找出錯誤，而進入開發後，越後期發現的錯，越消耗成本；另外，在沒有用戶研究下，就會拉長易用性測試的時間，或是服務上線之後，才發覺方向要大修正，所以用戶研究消耗的時間，其實是省下後續易用性以及市場面的測試時間，而後面的時期代表成本消耗也越大，但以上其實是針對管理階層所安排的說明，UX 帶來的價值遠超過省錢。
人人都應該帶進使用者心聲
敏捷開發的組織精神，主要是營造一個扁平去中心化的自組織，每一個人都應該對組織主動貢獻心力，這也包含了對於產品功能的決斷上。本著用戶體驗的精神，任何關於解法的討論，都必須回到真實的生活情境，如果直接進行功能面的討論，很有可能會產生一個現象：任何的意見都是個人經驗的投射，而非來自使用者需求。在沒有用戶研究的情況下，至少，我們要能夠知道一個真實用戶的使用情境，即使是周遭親友也可以，每個開發成員都應該這麼做，提出真實的情境會形成有效的功能討論，所以每個團隊成員都應該在日常生活中，對周遭人事物保持關心，就有機會觀察到自己產品服務的使用情境。
從使用情境來說明 User Story
我參與的會議中，其實很少看見在會議中討論 User Story，大部分都是確認開發成員是否理解機 User Story，以及確認後續的做法。但是在會議後以及工作坊的交流中，常常會聽到對於 User Story 來源的疑問，或是功能必要性的討論。我個人經驗是，跟工程師朋友談功能時，被打槍的理由都是過去程式開發的經驗不會這麼做，但是如果我把使用情境拍下來，或是節錄受訪者的逐字稿，再讓工程師參與設計轉化的工作坊，讓工程師直接感受情境，有時候工程師還會放棄自己的意見，跟我們一起想出更好的解法。所以情境的強調是種肥沃的土壤，健康的User Story種子加上肥沃的 Scenario，就會長出使用者人人想吃的好功能。
在腦中建立情境的方式
一般而言，我會使用「情境」（Scenario）的時機點有兩個，一個是在定義問題時，我會把真實的情境帶入工作坊，另外一個是提出解決方案後，會將情境用圖片或是演出小短片的方式，來跟後續接手的開發、企畫、以及行銷人員做解釋。User Story 已經是要實作階段了，所以比較偏向後者，也就是說可以用情境圖片加強對於 user story 的理解，或是用更強大的方式。
這個方式我在其他場合有公開強調過，就是要寫劇本，把使用情境演出來。他會有幾個好處：
1. 快速理解方案要解決的問題與需求。
2. 演出的過程中還可以進行情境的除錯。
3. 演員可以自行演出突發的狀況，成為解決特殊問題的新功能。（或是先給客服人員有心理準備）
當然在敏捷開發會議中是沒有時間這麼做，但至少給一張視覺化的使用情境，對於理解 User Story 一定有正面的幫助。
UX 不只幫專案省錢，他主要的目的是找出用戶心中的價值
分享的後半段，我重新論述了 UX 的價值。前半段我從幫專案省錢切入，後半段我開始導回到 UX 協助找到新價值的部分，我相信先從預算切入比較有說服力，但一定要強調用戶體驗除了省專案錢，更能夠挖掘用戶心中的新價值。
我個人的經驗，讓客戶驚艷的內容，不是把一個服務做到極致，而是協助客戶找到一個框架外的解法，對於用戶生活有深入並沉浸的觀察，精準的定義需求與問題，這是 UX 的第一個價值。
對於 IT 背景的朋友，數據是最直接的資料，透過後台數據，我們可以推敲一個線上服務是不是貼近了用戶的需求。如果我們可以退一步想，我們知道服務往用戶貼近了，但為什麼用戶願意讓我們貼近？這部分就需要 UX 在質性面向的切入，我們對於載具外的人性都存在的朦朧美，唯一可以看見的是具體的行為，但決策的根源來自於人性，如果我們可以走出辦公室跟實際的人交流，踏出辦公室的一步就是領先對手的一步，這是 UX 的第二個價值。
在資訊服務的規劃上，有時候會有一個情況，我們在需求驗證沒有出錯，在 flow 或是 UI 規劃也具備易用性，但是部分用戶在使用上仍然會有中離或是卡關的狀況。這其實是在部分的資訊服務上，使用者的在進入資訊服務前的情境，被我們忽略了。帶著負面情緒進入到使用情境，耐心與注意力相較於情緒正常的人，存在著差異，所以在進入資訊服務前，我們就必須新增一些新功能，讓使用者的情緒正常了，就可以好好使用我們的資訊服務，讓流量正常的導入，這是 UX 第三個價值。
開發團隊對於 UX 的疑問
透過這次大會，我也將開發團隊的疑問一一解答，我覺得這是一個特別適合的場合。我這邊最常被詢問的三個問題：
1. 籌備全新的服務時，用戶研究的時間太長
2. 開發B2B的服務時，找不到使用者。
3. 進行中的服務若是要優化，可能會牽一髮動全身。
使用者研究時間太長
用戶研究時間拉太長，我必須坦言，這跟研究者本身的能力有很大的關係，大部分都是經驗不足造成，如果跳過這一塊不討論，其實在用戶研究中可以避免的耗時，就是在招募使用者的階段。當然我不會在這邊談招募技術，我想談的是，如果資訊服務的對象是一般社會大眾，必須要有大量用戶才能損益平衡，這時我會建議在研究之初就應該要建立一個 subject pool，意思是在第一次研究時，就要建立大量受訪者清單。這會讓第一次研究的時間拉更長，但是在後續的研究上，招募受訪者的時間就會有明顯的縮短，既然要找受訪者，我們不如就要一次到位。（但免不了的，當服務穩定上線後，subject pool 要定期更新）
找不到使用者
我其實常常被問到找不到使用者，因為使用者是客戶的客戶，所以無法觸及。我想先說明一個觀念，受訪者分成三種：
非使用者→還沒有使用過服務的人，想要導入更多流量時找他們受訪。
使用者→持續使用服務的人，想要優化服務留住他們，就一定要找他們來問一問。
前使用者→使用過我們服務的人，但因為各種因素離開了，如果想要除錯就找他們。
（但是有例外，非定論）
通常非使用者是一定可以找到的，因為沒有使用過服務的人都是，問題可能是在於使用者與前使用者。這的確是個問題，但並不是沒有解法：我們只能去養使用者。找一群人來使用我們的服務，透過一些特殊的約定，觀察他們的使用狀況，最後進行觀察訪談。
這個方式雖然在找使用者的部分失真了，但是我們仍然是透過第三方的意見與實際的行為，進行後續的規劃，這會比跳過用戶研究來的可靠多了。
牽一髮動全身
如果優化了介面，讓原來的使用者不開心怎麼辦？這聽起來很像 PCHOME 詹先生的話，實際上在一些開發團隊或是營運團隊也有類似的聲音，不過這的確不是用戶研究與 Agile 的問題，我被問及其實也有點驚訝。這其實是種選擇。
「你要擁抱新流量，還是守住舊流量」？
我在交流的過程中，從一家公司裡的 IT 部門自己就提供了解答，其實技術上是可以做到，「先讓少部分的人看到優化的介面，沒有嚴重問題時，再放大使用的範圍」。過去合作過的客戶也有聽過我這個說法嘗試成功過。這個作法已經有實際案例，我想很多人在使用臉書的時後，也有類似的情況，有些人就是會使用最新的介面。另外我覺得特別值得一提的是，當我們抱怨臉書新介面不好用，想離開時，總是會被時間擊敗，回想一下，我們其實都罵過臉書好幾次，但現在還是在用，如果您也有類似的經驗，這個問題的答案，我想您我心中都早就知道了吧。（但這個方式不一定適合所有的電商）
一個服務開始前，資深的服務設計師都有能力思考，從研究到上線的過程中，整個開發流程應該要如何規劃，過程的關卡應該如何解，其中，可能不存在一個標準的流程，只要不失去敏捷的組織與思考就好。
而過去在使用者經驗設計的領域，前輩們一直在尋求的 UX 文化的組織，我在這次交流過程中，在一個新創小團隊中感受過，但他們的敏捷味更濃一些，我想無形的 UX 的確跟落地的敏捷開發，是可以無縫協作的兩種精神。
謝謝各路英雄的協助，在一年內，將自己升級成可以一個可以在兩個領域中相互溝通的通靈人（沒有更貼切的詞了），在一些顧問輔導工作上，功力的確是提升了，也希望每一次交流的過程中，我的回饋也能具體的協助每一個讓我去串門子的團隊。如果我九月份再來一次，大家願意讓我一一去交流嗎？我很想協助寫一份台灣敏捷開發文化的小記錄，等我趕上我的業績目標，我們再來一次好嗎?
我想我的 40 分鐘分享應該不會有影片上線，所以專文寫下整個分享的重點與思考方式，簡報如下： https://www.slideshare.net/NorChen/agile-summit-2018-103605461
授權來源：準備一場跨領域分享的思路：2018 Agile Summit
