服務設計要專注在使用者身上
對使用者需求的深刻理解,是建設一個成功數位化服務的關鍵。
定義使用者需求
有關服務的任何想法,無論是線上還是線下,必須從最簡單的問題開始:什麼是使用者需求?
定義使用者需求,必須嚴格和誠實。對於GDS,這需求是人們能擁有政府,而非政府傳遞重要資訊給人們。
這是一個非常重要的差別,因為這意味著你將能夠更準確地衡量服務的成功和反覆改善它們,以滿足使用者的需求。
我們如何定義使用者需求
收集證據
你應該能夠提供使用者需求真實存在的證據。從潛在需求出發建立使用者需求列表可能是個很好的方法。
良好的證據可能包括:
- 現有的內容。利用網路技術分析來證明,使用者定期拜訪、使用已經存在的內容
- 搜尋結果。使用網站的搜尋軌跡記錄(logs)證明人們對於內容或功能的需求。
- 第一線員工。跟在服務台或客服部門工作的人聊聊。這些人定期跟使用者互動,他們能夠告訴你最迫切和實際的使用需求是什麼。
- 使用者研究。可能有先前的使用者研究,可以幫助你了解使用者的需求是什麼。你也可以委任你的研究團隊進行一項快速的使用者研究,這將有助於你有小樣本的使用者直接對話,了解他們以及驗證使用者需求。
正確地架構需求
如何描述每個使用者的需求可以對你最終是否成功的滿足了實際需求有很大的影響。尤其是對你最重要的使用者需求,確保你已經正確理解是相當重要的。 —-也就是你必須要有能夠實際形容它,透過它來反映使用者嘗試要做的事情。而不是只是鬆散地描述你認為他們可能需要什麼樣的內容。
例如,當考慮稅收法規,考慮可能會為此需求設計的解決方案:“作為一個使用者,需要教導我如何去計算稅務的資訊”。現在考慮你可能會針對這個需求設計出來的解決方案:“作為一個使用者,我想知道我是否在正確的稅務條目頁”。
單獨藉由分析數據資料,建構正確的架構(形容)模式可能相當困難。尤其是對你最重要的需求,一定要做一些定性研究(直接和使用者對話),並跟前線員工溝通,以確保使用適當的措辭反映真實的需求。
訂定你的標準
你不能期待一次就完成
你應該對於你的服務可以做什麼以及應該提供什麼做出邊界,防止自己被無止境的使用者需求淹沒。
對於一個像是GOV.UK這樣的政府網站等尤其如此 。在我們辨認出使用者的需求同時,我們也定義出什麼是一個政府必須要回答的問題。這導致了“這是如果……”的標準:
- 這是只有政府在做的一些東西
- 這些是明確的需求(透過搜尋記錄或是流量日誌證明),或政府在法律上有義務向其提供
- 在用來處理政府提供/或是相關事情時,人們可以直接拿來使用,或是在做這些事情前人們可以使用的東西。
- 這些事情是由政府來做,提供,或是付費打造的。
- 這是個人或組織固有的的權利和義務
- 這是簡單的建議,幫助人們遵守其法定義務(比如記錄你應該保持你的稅務及海關總署申報表什麼樣的記錄),或提供某些種類的諮詢和對企業的支持,但不包括一般生活或由第三方提供的商業建議
類似的標準可以幫助你確定哪些需求可協助你構建一個服務來滿足。
使用者故事
呈現使用者需求並不意味著提供解決方案。需求應該以使用者故事呈現,讓服務團隊可以討論,並探討可能的解決方案。
- 定義使用者需求
- 從使用者的角度寫出他的故事
- 訂定可以接受的標準
- 解決方案由服務的團隊進行探討以及提供
延伸閱讀
翻譯:林恆生
校稿:Amy Hsu, James Chu
原始出處:https://www.gov.uk/service-manual/user-centered-design/user-needs.html