David Ko的學習之旅

最近看到一位 project manager 所做的簡報, 他是在描速我們安裝流程如何被改善. 我們的產品是一個 hardware appliance, 安裝時間要 1 個多小時, 並且中間要輸入一堆高深的網路設定, 不是一般常人能容易了解. 因此要把這件事情描述清楚並不是件輕鬆的事情.
可是在簡報中你不會感受個那些神奇的技術, 但是你卻可以很清楚知道它的原理是什麼. 再加上他本身背景是 UX engineer 出身的, 利用了一些流程圖和合適的圖示, 就能達到 21 天學會java 的效果 XDDD. 
這過程中他做了什麼事情呢? 他消化了整個安裝過程, 並且體會到顧客的需求(想知道重點是什麼)和痛處(太多細節很難了解), 利用四格漫畫的技巧(經過設計), 清楚地解釋安裝流程如何被改善.
這裡讓我想到很多時候開發人員背景出生的人, 常常會誤解 UX engineer 就是把會面做得漂漂亮亮, 或是用得比較好用這樣就可以了. user experience 就會很好, 這就是 design thinking, 我想這真的是很大的誤解. 
個人認為 UX Design 是著重在了解和找出使用者痛苦的地方在哪裡, 然後設計出方法來解決它. 
這中間無關畫面漂不漂亮. 會扯到漂不漂亮, 可能是這個解法根本無法解決你的痛苦, 你只好欣賞它的”漂亮”
當然也可能是開發人員輕視了 UX engineer, 認為他們只能處理漂不漂亮的事情, 但是他們無法設計出 solution.
之前在設計手機上 app 的 workshop, 很多工程師討論了半天, 常常結論是我們要做一個 LBS 的 app, 根據他現在所在的地方提出合適的服務. 基本上很合理, 但是這比較像是工程師在推銷 LBS 技術, 而不是在幫使用者解決問題. 那時候有位設計師就建議我們說, 我們是否再退回去想想, 他們背後心裡真的想要是什麼? 是要你介紹附近的東西給你, 還是介紹他"心裡想要的"東西給他?
最後他們這組討論出說要做一個"意若思鏡"的系統, 他們不會對每個到這個位置的人, 都推薦相同的東西. 反而是觀察之前的購物習慣, 或是常去的地方, 來思考他可能會要什麼, 才推薦東西給使用者. 這樣就和其他組別有很大的差別.就像"意若思鏡"一樣, 每個人去照時,鏡子內所呈現的東西都不一樣

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

公司內有個團隊, 集合了PM, sales, SME 和開發團隊, 在進行跨功能小組的創新.
他們在拜訪了十幾家客戶後, 帶回來了許多客戶的做事的流程, 以及遭遇到的問題. 整理下來, 我們大約列出了400~500個項目. 接著我們便開始思考如何解決他們的問題.

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

最近終於有機會, 去上牧民老師的脈絡訪查. 這門課可是讓我等了快一年, 好不容易今年讓我達成這個願望.
http://userxper.com/blog/archives/3091
這門課上起來, 真的不是普通的忙. 每個人需要去訪查一個人, 回來之後便要和同組同學進行brain dump session. 所以這周真的是忙碌的不得了.
一開始時, 大家問的問題還不是很兇悍, 因此前面兩個人capture的張數只有50 張左右, 接著兩個人都飆到了80 張左右. 好害怕再接下來, 是否會破百.
今天讓我印象最深刻的, 就是有圖有真相. 這照片中的媽媽, 雖然揹著環保袋, 可是卻沒有將手中的砂糖放入袋子, 而是一直拿在手中. 可是訪查者卻是無法解釋這點, 只好被記點一次, 殘念!!
此外, 今天得到印象最深刻的一句武功心法: 對受訪者有做的行為, 去詢問為什麼; 而不要對受訪者沒有做的行為, 去詢問為什麼不這樣做. 前者有機會會得到使用者做件事的原因, 但是後者可能會得到假設性的回答. 因為你請受訪者, 回答一件他沒做的事情, 他可能會受你訪查的影響, 回答出你想聽的答案.
最後, 牧民老師還引用了倚天屠龍記的內容: "太極拳只重其義，不重其招，你忘記所有招式，就練成太極拳了！" 告訴我們詢問受訪者的準則只是告訴你方向和範圍, 但不是教你要原封不動的遵守. 有時候招式上犯點小錯, 可能會讓你得到更多的收穫, 只要你知道你問的問題, 是犯了甚麼毛病就好.

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

我想許多UX researcher最洩氣的地方, 是訪談後的結果, 沒有人用力看. 常常是自己嘔心瀝血的整理一大分報告, 可是卻是束之高閣, 或者沒有被發幾頁, 就放在一邊.
因此常見的作法, 是邀請開發團隊, 以及經理們, 來聽UX researcher的簡報. 可是在怎麼濃縮, 也無法在 1-2 小時內, 把精采的內容講完. 此外, 若是演講的時間在下午, 來聽講的人很容易的昏昏欲睡, 效果更是有限.
我們家的researcher 討論了一個新的做法: 利用 workshop 的方式, 讓參與者動腦筋來認識客戶的問題.
一開始還是花了 1-2 小時, 讓大家對訪談結果有個簡單的認識.接著一周後, 我們開始進行 workshop. 首先, 我們美麗的researcher 用力講解今天的流程是甚麼
大家一邊聽流程講解, 一邊好奇看著卡片內容. 在卡片上我們把每個客戶觀察到重點, 記錄在上面.
在主持人講完之後, 大家便開始要用affinity diagram的方式, 來 group 這些重點.這時候大家便要用力研究卡片上的內容, 便不是可以聽聽就了事, 分類是需要動腦筋的. 哈哈
當大家手忙腳亂地分好類後, 便開始小組分享. 順便請長官 comment 每組的結果. 我想大家一定戰戰兢兢的 XD
故事當然不會到此結束, 哪有這麼容易放過大家, 當然繼續ㄠ死大家. 接著, 請大家針對一些high priority 的 group, 討論其可能的解法. 因此下半場的煎熬又再開始.
在大家熱烈討論後, 同樣地, 我們也是請每個小組分享他們的解法. 我想經過這幾回的討論和腦力激盪, 應該可以讓開發團隊對客戶的痛處, 有更深入的了解
Retro:
1. 卡片太多, 大家無法在有限時間內充分討論和分組
2. 雞排太邪惡了, 下次可以換別的嗎?

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

User Story Mapping 的好處
在使用 agile 方式來開發軟體時, 我們常常使用 user story 來描述我們在sprint中要處理的東西. 因此我們一開始會根據 MRD  or PRD or SRS, 來列出100-200 個 user story, 然後我們會對他們來排出要處理的優先順序, 以方便之後 sprint 的進行.
可是問題來了, 當要處理的項目很多時, 我們便會有以下問題:
1. 這 100-200 個彼此之間的關係是甚麼?
2. 若是能把他們分群, 會幫助我們記憶. 試問記憶100-200個容易, 還是記憶幾個有關聯的群組容易呢?
3. 有了群組會讓我們容易檢查是否有遺漏的項目, 否則我們無法對100-200個項目檢查是否有不足之處
4. 我們無法知道這個系統大約有那些大項目要處理
5. 有時候很難對所有項目排出優先順序, 只能分出 high, mid, low
因此, 使用user story mapping 便可以幫助我們以下事情
1. 讓我們知道系統的工作流程或是價值鏈為何 (從橫軸的 activites 可以得知)
2. 可以知道大的user story 和小的 user story 之間的關係
3. 提供一個脈絡, 讓你知道要如何排列優先順序
4. 容易確認 user story 的完整性

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Designing Ahead: The Good, The Bad, and The Ugly
by Anders on August 22, 2010
http://www.andersramsay.com/2010/08/22/designing-ahead-the-good-the-bad-and-the-ugly
在agile UX的流程中, 我們通常須要求某些design的工作, 會在 iteration 之前開始進行. 但是這不是意味設計人員單獨進行設計, 而不需要開發人員的加入. 而是需要整個團隊
一起來進行.
但是有些設計人員會說, 有些開發人員正忙於目前 iteration 的工作, 他們怎麼會有空同時進行開發的工作和設計的工作. 這個想法其實是有問題的.
但 Mike Cohn 在 "Succeeding with Agile" 一書中提到, iteration 內要進行事情, 並不是只包含這個 iteration 要 deliver 的功能. 還需要包含下個 iteration 的規劃和準備工作, 也就是要包含 UX design 的工作項目.
因此所有成員不只要做這個 iteration 的工作, 還要設計下個 iteration 所需要東西. 當然啦, 設計人員是要比開發人員要花跟多時間去處理. 但是, 開發人員也要持續和主動地參與檢視 mockups 和提供回饋. 讓設計的工作可以完成, 以提供下個 iteration 來使用.
所以開發人員在 agile 中, 除了要著重於程式碼的品質外, 還要擴大到要著重產品的品質. 在這件事情上, 使用者經驗便扮演重要的角色
另外一個常見的錯誤是, 在 iteration N 一開始之前, 企圖去完成詳細的介面設計. 你只需要指出大方向上, 或是概念上的想法. 像是操作流程, 或是一些使用者介面的
patterns 等等. 然後讓在細節設計的部分, 在 iteration N 中才真正去處理.

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

A day in life of an AgileUX Practitioner: Personas
http://www.agile-ux.com/2011/03/08/a-day-in-life-of-an-agileux-practitioner-personas/
Posted by jc-Qualitystreet
Persona 的觀念
- Persona 是一個使用者的原型, 是目標族群的虛構代表. 它可以幫助你在產品功能或是視覺設計時做出決定
- Persona 可以讓團隊對於使用者想要的產品或是功能, 有共同的瞭解. 使得 product owner, 開發人員和設計師藉由 user story, 把 user experience 和 software development 連結起來
如何和敏捷團隊建立personas
在專案開始之前, 我們要來建立 persona. 時間點會是在 sprint 1之前或是 sprint 0. 並且要招集整個團隊來進行, 大家一起合作來想像 user story 有哪些
A. 事前準備
- 招集 product owner 以及相關的利害關係人, 利用一至兩次的 workshop 來確保大家對於目標和做事的流程有相同的認知.
- 並且找出可能的資料來源, 和決定要訪談的對象的族群
- 從資料來源來收集資料, 包括利用訪談的方式
B. 集體構思
- 利用親和圖(affinity diagram)的方法, 大家集體來找出不同和相同的地方
- 建立 persona 的架構
- 使用你喜歡的方式來產生 persona, storytelling 或是 virtual design
- 找不同的利害關係人來驗證你的產出是否正確
C. 溝通和使用
- 把 persona 當作是一種資訊發射器(Information Radiator), 放在團隊的工作環境中, 提供了目標族群的資訊
- 把 persona 和 user story 結合在一起
- 把 persona 當作是輔助排優先順序(在排product backlog時使用)和設計(在設計些user story時使用)的工作
- 可以用來當作和 marketing 和 sales 溝通的資料

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

 

Persona driven user stories for Agile UX
http://www.disambiguity.com/persona-driven-user-stories-for-agile-ux/
Author: Leisa Reichelt

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Persona 二三事
Personas vs. Use Cases in Requirements Documentation
http://zenagile.wordpress.com/2009/09/20/personas-vs-use-cases-in-requirements-documentation/

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(0) 人氣()

kojenchieh 發表在 痞客邦 留言(0) 人氣()