Background
我們需要 enhance 一個類似內聯網的App。公司可以通過這個App發放消息、公司的員工優惠等等。現在加上一個義工/活動報名的feature，讓同事可以使用這個App對自己感興趣的活動進行報名。
Userflow
- Activity list page 看活動
- Activity detail 看活動的詳細內容
- 如果感興趣，apply
- 如果想修改時間/其他內容，可以edit
- 如果想回收申請，可以withdraw
Problem
在submitted的activity detail page有兩個action可以讓user做的。一個是edit，另一個是withdraw。
由於這兩個action並沒有輕重之分，所以我們建議兩個button用一樣的style。
Vendor 給的design是這樣子的
經過討論之後我們認為 button style inconsistent，因此在開會的時候request兩個按鈕要大小和style一樣，也就是說如果 edit 是有icon的話，那withdraw也要加上一個icon，並且兩個都是用border style。
Vendor side 的designer解釋說，如果兩個按鈕用一樣的style的話很難區分兩個按鈕，所以他們的設計是要不就兩個都是border style但是一大一小，要麼就是一個border style另一個是沒有border的。
Solution
由於對於design的說法各有各的道理，無法說誰對誰錯，只能選擇最適合user用的做法。
因此，我打算用一個小小的usability testing來測試一下
- 這兩個button如果用一樣的style，user在使用上會不會覺得有問題
- 以及測試一下如果用不同style的話，會不會影響user的選擇
Preparation
1. Research Plan
沒有。😂
由於時間太緊迫，並沒有將research plan詳細寫下來，但是最主要的是想清楚有多少種情況要test。我的計畫大概是要用3個version，設計不同的task去測試
- 兩個button一樣的style ——設計task讓幾個user去做edit，讓幾個user去做withdraw，看成功/失敗的情況如何
- Edit button用filled style ——設計task讓user去做withdraw，看成功/失敗的情況如何
- Withdraw button用filled style —— 設計task讓user去做edit，看成功/失敗的情況如何
2. Clarify my confusion
其實這是我第一次做usability testing來尋找答案，因此我在一個設計師群組裡面問了師兄的意見。
師兄的的意見是
- “畫面整體同個flow 會影響咗你個問題嘅答案”
- 如果可以的話或許收起一個更好，而不是無緣無故highlight某一個button
- 兩個button一樣的style已經沒什麼問題，但如果要highlight其中一個的話，他會選擇highlight withdraw，因為withdraw是一個不能回頭的決定，就好像cancel something一樣
- “所以簡單少少講, 就係
~你想知個button係呢個情況下需唔需要分2種明顯既輕重。
~依家你覺得唔洗, 但有人覺得要
~你需要有實際既comment去幫你做呢個決定
~所以你需要係黎緊既testing入面搵到呢個答案
~結論
請SET好一個/多過一個TASK去搵到針對呢個問題既答案”
- 3個test的setting很有機會3個都100%成功
- “e.g. 你個TEST要SET到係會有機會出錯, 所以先可以知道USER既理解。 你只係叫佢按一個制, 佢係好低好低機會出錯。你如果TEST5個人，好易出現100% 正確”
- “諗下點令個USER係個個位要思考LO，思考唔係錯，因為你做緊TEST”
— — — — — — — — — — — — — — — — — — — — — —
聽完之後我在想，我是不是需要把整個完整的prototype都做出來，然後把task弄d得比較複雜一點再做usability testing？由於要設計一些task讓受訪者做的時候會有可能出現出錯的機會，那麼這些task就要設計得複雜一點？如果受訪者在做task的時候出現不必要的分支怎麼辦？也就是說如果他想點擊的地方其實沒有連結的話，那會不會影響整個testing的效果？
腦子還是有很多疑問😂，但是沒辦法問得太仔細問清楚。所以，我決定先做了再說！先試試看，拿了經驗之後再改進！
3. Prototype
由於時間關係，我只能用vendor給的圖拼拼接接。做了三種情況：
- 兩個button一樣的style
- Edit button用filled style
- Withdraw button用filled style
4. Task & Questions
Task 1 —— 參加活動： 讓participant看活動頁面，假設他們有興趣參加，讓做參加活動的action
Task 2.1 —— 修改活動：假設participants在之前選的那天突然沒空，要換另外一個日子
Task 2.2 —— 取消活動：假設participants突然不想參加了，要取消這個申請
Followup Questions:
- 你在使用的時候有沒有困難？
- button style與你平時使用的app有什麼不同？
- 有顏色的button給你什麼感覺？
- prefer哪一個version？為什麼？
5. Logistic
- 首先，簡短地講解這是一個小小的usability testing，我會錄影下來
- 再者，解釋這個公司一個app的一個新的feature，user可以通過這個feature來參加自己感興趣的活動
- 然後，讓participants完成對應的tasks，每個人有2個tasks要完成
- 問followup question，了解他們的看法
- 給他們展示3個version，跟他們講解design concept，然後了解他們對這3個version的設計的看法
- 感謝他們的參加，他們的意見非常珍貴
Run the test
尋找participants
由於A/B team的關係，找不到足夠的participants😂
- 2個同事做version 1，做task 1 + task 2.1
- 2個同事做version 2，做task 1 + task 2.2
- 2個同事做version 3，做task 1 + task 2.1
測試期間
- 跟預測的logistics差不多，每個同事只用了大概5分鐘就完成了😄
- 每做完一個participants就簡單地把result和feedback記下來
Result
我把整個testing的思路，最後的結果，以及participants的feedback都present給stakeholders。
最後我們的決定是用最初的idea —— balanced version 兩個button用一樣的style with icon and text。
原因跟我們的設想類似：
- 因為這兩個button沒有哪一個更加重要
- 不想用兩個filled style因為這樣感覺太重了
- user會在選擇之前看button的text再做決定
Lessons
- 一定要測試好整個prototype無誤才可以做測試😂 在做user3的時候，我就是沒有留意有沒有回到最初的頁面，導致喪失了一個研究者的名額！那就太可惜了
- prototype要儘量用real data，那才可以讓受訪者更投入。有一個受訪者在途中關注到了要參加活動的那個日期已經過期了😂；另外，這次因為時間的關係，我並沒有將表格的每一項都讓用戶去輸入，而是已經pre-fill了，這樣也會影響受訪者的投入程度，因為他們覺得這個是假的而已
- 由於時間的關係我並沒有嚴謹地篩選受訪者，因為全公司的同事都會用這個app，所以我就在IT department找了一些同事來做測試，有時間的話，或許可以找一些不同年齡，不同崗位的同事做測試，例如前線工作的auntie
- 真的要不斷地訓練。even到了最後一個受訪者，我在描述以及問問題的時候都會出現不小心問出一些有bias的問題，或者描述的時候講出一些可引導/可誤導的關鍵字。例如：有一次我描述第二個task的時候說，假設你突然沒空參加這個活動了，那麼你要怎麼去withdraw呢？問完之後我立刻就覺得自己是錯了😂
- 在測試過程中，會有可能出現很多不同的情況出現。例如，會有一些受訪者不跟著你描述的task一步一步做，他會一直滾動看其他的內容，那就會出現他提前看到了按鈕😂，那這樣子的結果可能會有偏差
- 用戶的feedback的價值比完成task的結果更大。由於這幾次testing的結果，不出師兄所料，全部都是100%成功，受訪者在做的過程中也沒有因為是任何一個version而覺得有困難/問題/不順利。但是他們表達對button顏色的insight更加有趣。有一個同事認為，用不同style的button會讓user記得填充顏色的button是什麼用途的，下次他再用的時候會記得，這是一個學習的過程；也有同事認為，如果加上顏色的按鈕就會誤導人更加趨向按下去，各有說法。
雖然是一次小小的usability testing，但是學到了有趣的東西。雖然不知道結果是不是最好，但是我們通過討論之後，認為這是目前最好的設計。
期待下一次新的research/testing體驗！UX真的蠻有趣的
後記
後來我請教了我的design mentor關於這次usability testing的疑問。順便記下來一些分享給大家
- 問：My tasks set up, are they correct? How to be better?
→ Task 不要太descriptive
→ 只能暗示多點
→ 給受訪者一張卡片，裡面寫task background，scenario，有可能有到的信息
→ 如果prototype的頁數不夠，可以口述，描述會去到什麼頁面，要做什麼，也可以問user會在這裡填什麼，會怎麼做怎麼填
- 問：Do we need to set up the whole/full prototype to execute the usability testing?
→ 要整一個journey的prototype做出來, in this case, it would be the new function module prototype
- Usability Testing 不一定要得到 quantitative result, 得到 qualitative result 也可以。因此，你這個是得到qualitative result
- 因為設計的task很清晰，所以都有可能是100%正確，只是看哪個更好
- 關於按鈕選哪種，應該看看App本身的standard，問vendor要design guidelines，所以不能只看一版決定用哪個design → design management
- 面對面做testing最好，也要看你找到的user是通過什麼途徑。
