今天 AgileCommunity.tw 分享的主題是有關於 Agile UX 的. 之前對這個主題研究不少, 也看過不少人的分享, 或者是自己團隊也有在進行. 但是還是想知道, 是否有更高明的做法, 或者是自己的認識否走在對的方向. 所以很期待今日的分享.
 
 
今天的講者, 是來自於微軟做 UX 的人. 小時候在中國長大, 13 歲後到美國唸書, 在微軟工作了 6-7 個年頭. 他在微軟都是飛來飛去的, 需要和各地的人一起合作. 並且需要負責訓練開發人員 UX 的觀念. 此外, 他也會利用 UX 的方法, 在開發 NGO 的專案上面. 能夠有這麼多元經驗的人, 還真的不容易遇到.
 

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

很多人在用了 story mapping,  列出了產品要提供的功能後, 接下來很多人就會想開工去寫程式了. 這樣做的話, 還是太快了些, 如果在此之前先做的驗證, 可以讓你少走些冤枉路.
 
有的人會說, 那我們來選出 MVP, 找出最有價值的部分, 先來驗證看看. 這是一個很好的開始. 但是, MVP 要做出來也是要花時間的, 因此我們還需要更簡單, 更省錢的方法, 再做出 MVP 之前再確認一下.
 
那天在上用戶訪談那門課時, 老師提到一個分鏡圖的方法, 覺得還不錯, 整理下來給大家聽聽.
 

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

在我們推廣敏捷時, 最重要的文是化和思維的轉變. 因此, 好的引導方式, 以及團隊凝聚, 都是很迫切的工具. 但是這些都無法速成, 需要一段時間的培養和實施, 才能看到效果.
 
那有沒有比較快的方法嗎? 老實說, 沒有絕招. 但是有個方法, 是可以讓你省點力氣. 那就是打造一個敏捷工作環境.
 
環境重要嗎? 如果不重要, 當年孟母就不用三遷了. 在天龍國的熱門學區的房價, 也不用如此貴桑桑的.
 

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

在敏捷需求探索時, 一開始會用 impact mapping, 描述要產生什麼影響, 以及會什麼要做這功能. 然後使用 story mapping, 依著時間順序, 來述說產品的功能.
 
這一切看起來都很完美, 不是嗎? 可惜, 天下的事情太複雜, 不太可能用一招, 就可以解決所有問題. 例如: 防毒軟體. 使用者根本不知何時有毒要進來, 不知道他什麼時候已經中了毒, 也不知道中了以後要怎麼辦. 因此, 以時間軸為主的 story mapping 完全無用武之地. 
 
那怎麼辦? 沒有時間順序觀念的產品, 還能使用 story mapping 來進行嗎? 相信有不少人會有這類的問題.
 

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

在上次敏捷需求探索工作坊中, 還被問到一個問題, 有人提到是否可以單獨來教 user story mapping, impact mapping 和 客戶訪談. 也有人提到 persona, storyboard 這些, 每個都是一門學問, 每個都需要花好多時間學習. 
 
是的, 這些東西拆開來看, 都是很複雜, 都是一門不得了的學問. 需要花時間學習, 才能夠精通. 
 
但是, 我並沒有想分開討論他們, 或者花時間討論每個 practice. 我想要做的, 不是要告訴你, 每個劍招要使到哪個位置. 而是要讓你清楚, 這整個獨孤九劍的劍意為何.
 

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

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼