l

2014年1月7日 星期二

從舉辦活動單位的角度談線上報名系統的用戶體驗設計

Jan. 06 19:38~21:26

螢幕快照 2014-01-06 下午9.05.37

客服電話勒…找不到人開罵XD。

 

原本這一集是要歸類在「麥甲我蓋布袋」系列文章,但後來想一想大過年的不要一天到晚都在罵人,還是正面思考,提點有建設性的意見。

沒看過〈千拜萬拜,不如整箱國農拿來拜〉 的鄉民們可以先去了解一下,算是這一集的「前傳」。話說Teddy將課程的報名系統換到registrano沒幾個月,registrano就被KKBox收購了,改名為KKTIX。今年一月五日突然收到KKTIX寄來的一封信:

***

您好,

感謝您對 KKTIX 服務的支持。

您在 KKTIX 上曾經購買過 10 個點數,目前還剩餘 4 點。因為新版網站直接提供單場活動升級,以及組織年費方案,既有點數機制將不再繼續使用。您原本的點數我們會發送 4 張單場活動升級兌換券給您。

您的兌換券號碼為:

…. (以下省略)

***

這封信有點無俚頭,Teddy完全不知道信中所言代表什麼意思,也沒去理它。今天(一月六日)想要在KKTIX上新增今年三月份的「Design Patterns這樣學就會了:入門實作班」的報名網頁,才發現原來KKTIX系統改版了…什麼,系統改版了,心中隱隱有著一種不祥的預感。重新登入之後果然沒錯,這次改版改得有點大,使用介面覺得沒有以前直覺,使用上覺得有點不方便。

好吧,這可能是Teddy個人的偏見,也許習慣之後就好了。先撇開「個人觀感」不談,怎麼原本有的很多功能,在新的版本裡面反而不見了?!像是Teddy經常使用的「手動修改繳費狀態」的功能,就找不到,而且還發現幾個bug。正想打電話去客服 罵人 反應,什麼,算你狠,KKTIX根本沒有提供客服電話,只能透過網路(e-mail、FB、Twitter)跟他們聯繫。

當客戶正在氣頭上的時候,沒有一通可以直接打去「幹譙」的電話,這種「有氣沒地方發洩的用戶體驗」,真的會讓人得內傷挑眉質疑

先透過FB留言反應,但等不到即時的回答,只好厚著臉皮直接去找KKTIX的負責人(因為他剛好在Teddy的好友名單之中,只是之前沒有直接與他本人聯繫過)。

和負責人反應問題之後,對方解釋了為什麼拿掉某些功能的原因,也很「阿沙力」的表示願意將「手動設定繳費狀態」這個功能加回來,還把「地下版客服電話(他的手機 )」告訴Teddy。Teddy也順便利用這個機會,向對方回報目前所發現的幾個bug。

***

軟體升級之用戶體驗守則第一條:不應在未溝通的情況下違反與用戶所約定的合約

對於一個線上報名系統,在規劃每次升級時,從「用戶體驗」的角度來看,Teddy覺得最重要的因素只有一點,那就是應該儘量遵守之前和用戶所約定的合約,通俗一點的就是說:要維持「向下相容性」。

軟體設計領域有一種設計的方法,叫做Design by Contract(DBC,依合約設計)。在DBC的精神中,子類別(subclass)不可以破壞超類別(superclass)所訂定的合約(superclass的介面所規範的pre-condition、post-condition、class invariant)。簡而言之subclass的pre-condition只能相等於superclass或是更弱(對caller的要求更少),subclass的post-condition只能相等於superclass或是更強(對caller提供的服務更多)。Subclass的class invariant則是需要加上superclass的class invariant。也就是說,新版軟體(相等於subclass)不可以破壞舊版軟體和客戶所簽訂的合約。那些合約?例如:

  • 原本的收費與服務條件,在已經預付費用的情況下,只可以更優惠,不能更嚴苛(subclass對於pre-condition的要求不可強過於superclass的要求。對於post-condition所承諾提供的服務,不可以少於superclass的承諾)。至於新的收費條件,則屬於另訂合約的範疇,subclass可重新設定。
  • 原本有的功能不應該任意消失,如果真的逼不得已要移除,也應事先通知與溝通,事後列出change log,讓用戶知道每一個版本的異動狀況。不然每次改版找不到原本的功能,Teddy都搞不清楚這到底是bug,還是「功能調整」挑眉質疑
  • 原本可以動的功能,不應該在改版之後出問題。系統的穩定度,絕對是影響用戶體驗的重大因素,沒有人喜歡不穩定的升級或改版。千萬不要為了趕著釋出,而提供低品質的昇級版產品。

以上三點做得到,說真的就已經很了不起了。很遺憾,目前台灣市面上兩個比較知名的報名系統,針對以上三點都還有努力的空間。

***

也許規劃新版軟體的人會覺得:「手動修改繳費狀況這個功能應該沒有人會用,那就從下一版移除吧。不是都說要簡單設計、減法原則、少即是多嗎…」

可是這個功能Teddy經常使用,而且實務上有很「正當」的使用理由。什麼理由?因為以下兩點原因:

  • KKTIX系統設定五日之內沒繳費就會被自動取消報名。因為參加Teddy活動的人有些是由公司付費,雖然學員為了幫公司省錢提早報名早鳥票,但是公司的行政流程卻要等到開課前幾天(甚至是開課後拿到發票)才方便轉帳付款,因此幾乎不可能在報名之後的五日之內完成繳費。因為系統沒有支援上述的狀況,所以Teddy只好手動將這些人的繳費紀錄改成「已繳費」或是「等待繳費」,以免他們的報名紀錄被刪除,然後再請對方公司的會計「有空的時候」直接把費用轉到泰迪軟體的帳號。
  • 第二個情況是出現在公司團報,因為KKTIX沒有支援團報的功能,因此假設有同公司四個人一起團報,必須要填寫四份獨立的報名資料,然後分別轉帳四次。但是很多公司的會計會打電話問Teddy:分多次轉帳很麻煩,能不能一次轉帳就好了?在這種情況之下,Teddy也只能先將報名者的繳費狀態改成「已繳費」或是「等待繳費」,然後請對方公司的會計直接把費用一次轉帳到泰迪軟體的帳號。

系統不支援的功能,只好靠人工方式解決。但是現在系統要把人工解決的途徑也拿掉,就真的是變的很不方便了。

***

寫到這裡突然想到〈給UX設計師和程式設計師的一句話〉和〈說說Persona的壞話〉這兩篇,軟體開發人員真的應該要稍微了解一下HCI/UX設計的基本觀念。昨天才在〈說說Persona的壞話〉提到user-centered design和activity-centered design這兩個簡單的觀念,Product Owner也好,HCI/UX設計師或開發人員也罷,在規劃系統操作流程的時候應該要稍微站在使用者的角度考慮一下使用情境。

這樣應該不算是罵人吧…XD。

***

友藏內心獨白:寫完之後還是想說…麥甲我蓋布袋嚎啕大哭

沒有留言:

張貼留言