此为历史版本和 IPFS 入口查阅区,回到作品页
Melody
IPFS 指纹 这是什么

作品指纹

讓服務更貼近使用者-福利雲

Melody
·
·

什麼是福利雲?

福利雲,顧名思義是「福利」和「雲端」的結合,希望藉由整合各方社會資源,應用雲端科技傳播,消弭資訊不對等,讓真正需要接收補助的弱勢族群,得到應有的補助。

藉由架設雲端網站與社工積極介入,改變弱勢族群對於申請補助的認知。利用網站的客製化身分條件篩選,梳理出能申請的補助,並附上白話解釋申請條文,輔助以視覺化圖像和語音,後續為個案轉介需求,填寫簡單易懂的線上表單,自動化轉介個案給適合的機構。

目的

福利雲希望解決弱勢族群資訊不對等、不識字、無法申請補助的困擾。透過E化平台,結合社工的力量,減低申請補助過程的阻礙,並協助獲得補助者優化後續運用資源的方式。

當初主要運用商業顧問的思維與方法論進行福利雲專案規劃,本次希望藉由服務設計的理念,審視福利雲規劃過程,提升專案的深度和廣度。

回顧原有方法論

本段落將針對原有方法論進行概述,後續再輔以服務設計方法論精進整體專案規劃過程。

A. 從「同理心」出發,思考社會創新的議題

運用MECE分析法架構社會議題,並針對各議題做深入的研究與案例分析。在挑選想要著手的議題時,從同理心出發,並且反思自身對議題的有感程度,而後就所挑選的關注議題,收集相關事實,深刻了解台灣目前的情境。

B. 就目前掌握的事實,進行任務發想的過程

研究統計數據後,發現台灣的法定低收入戶遠低於他國,就日本與韓國來說,平均低收入人口比例為16%,但台灣卻只有1.5%(1),在這些社會福利制度相對完善的國家中,日韓的比例遠高於台灣,這樣的不合理差距引起我們的好奇。

C. 定義真正需要解決的命題、核心議題是甚麼

法定低收入戶只認列有領取到之人口補助,許多生活在貧窮線以下的人口因未能申請到補助而被排除,使得法定低收入戶被低估。因此我們決定整合補助資訊,針對艱澀難懂的條文進行有架構性的整理與白話解釋,希望消弭這樣不合理的差距。

D. 擬定行動計畫,多方驗證計劃的可能性

經過成功案例分析與服務相關人訪談後,擬定了完整的行動計劃。並就以下四個面向去驗證計畫的可行性:「價值震撼性」、「可能性的創造」、「經濟可支撐性」、「刻骨銘心的共鳴」。

E. 實際進行「苦主」訪談與問題實證

將議題相關人分成四類並進行訪談:當事人(苦主)、與此議題相關的專家、與此議題相關的意見領袖、與此議題相關的現存組織。訪談架構如下:

F. 訪談整理階段性事實

我們發現落差來自於供需雙方的條件不對等,多數需求方未主動尋求救助,而供給方則因為諸多原因未能提供有效的協助。以下矩陣表示各種情境,並帶入我們所訪談到的事實,分析出我們能夠進行解決的核心問題點:

G. 針對核心問題設計解決方案

從供給端解決問題牽涉龐雜的公部門系統且不易下手,因此本方案主要針對需求方進行由下而上的計畫:增加資訊傳達率、改變申請補助認知、彙整申請資訊並建立雲端平台、白話解釋申請過程、語音輔助。此外和里長、社工、民間基金會進行網絡連結,若有特殊個案進行轉介。

H. 實際進行小規模實作

階段性目標,以粉絲專業呈現主題式文章每周一篇,藉此測試所得到的前期成果,亦可作為中後期發展基礎,並著手進行資料分析與雲端資料庫建立。終極目標為完成一站式補助篩選網,藉條件篩選功能客製化申請補助流程;同時希望串聯社工和民間資源,提供個案轉介與輔導服務。

服務設計如何增進專案規劃?

福利雲是個具有社會意義的專案,原有的提案已從同理心、用戶脈絡訪查出發,若基於原有的計畫加入服務設計的概念,將能使專案具備邏輯時間性以及整合全觀性。

A. 什麼是服務設計? 服務設計通常會運用哪些工具審視專案?

參考「這就是服務設計思考」(2) 一書的內容,服務設計身是以使用者為中心出發,納入各方利益關係人進入思考,並將服務視為一系列相互關聯的行動或事件,深度理解用戶與服務接觸的過程。

我們將用利益關係人地圖盤點所需要考量的分群、用工作活動親合圖表分析訪談並判斷設計議題、整合目標客群成為代表使用者盤點顧客旅程以了解顧客在服務中所發生的故事、規劃服務藍圖讓服務可以被具體化的溝通、最後建立初步原型以利後續測試迭代。

B. Stakeholder Map 利益人關係圖的應用

利益關係人地圖幫助思考哪些角色會影響服務系統,且能精進風險分析、找出有助於服務系統的關鍵人物。以此專案為例,我們曾訪談街友、基金會與社工,根據訪談結果,梳理出目前補助申請所需要經歷的角色與組織:

C. WAAD Analysis (work activity affinity diagram)(3)

訪談後將收穫整理成便利貼為活動做筆記,每張活動盡量客觀的陳述事實,一個事實一張,梳理出設計重點與結論。歸類活動筆記後,能依照此基礎快速討論各種可能性,進而發想設計。

D. Persona 代表使用者之應用

Persona針對不同用戶進行分類並篩選出具有代表性的使用者特性側寫。用戶側寫能讓我們更貼近服務設計的對象,也幫助設計師檢視設計的發展是否是以使用者為核心出發。

E. User Journey Map 用戶旅程地圖的應用

用戶旅程地圖協助我們視覺化呈現服務流程,從使用者對服務的開始產生認知、到真正使用服務、以及使用服務後的後續配套措施,通常會使用視覺化方式盤點服務旅程中的痛點,以及對於服務流程中的情緒起伏或滿意度等。四種 Persona 中以第四型為數最多:

F. Service Blueprint 服務藍圖的應用

服務藍圖協助分析提供服務之流程,其中的重要角色通常包含使用者、服務提供者、以及其他服務相關對象等,並依照服務流程列出所需要注意的細節。服務所涉及的相關角色對服務有不同面向的影響力,因此服務藍圖通常需要由各方共同討論。

以下服務藍圖針對「主要使用者 — 弱勢族群」,以及「次要使用者 — 通常為第三方協助者(例如:親友、里長、社工)」進行說明和解釋:

G. Prototype

原型協助我們快速驗證整體服務設計,能讓目標更具體清楚,並邀請目標用戶做簡單的測試訪談。洞察設計與實際的落差,梳理這些洞察後,便導引出供設計改版的方向。經過數次的訪談、原型測試、使用者體驗的校準,設計將會趨於完善。

結語

我們在過程中發現,服務設計需要因專案屬性、階段、地區、領域等諸多因素客製化方法論。就領域和屬性上解釋:福利雲這樣社會創新的專案,其實在用戶旅程上不是去看滿意度,而去是了解,針對這麼差的現況,如何去改善或者減輕用戶的痛苦,如此一來在整體工具使用與訪談上的方向就會非常不同。而就階段上來說,我們算是個從0到1的開創性階段,不同於大部分的服務設計是建立在已有的一定基礎上,再進行精進和調整,這些因素使我們需要更靈活的運用工具,甚至可以將不同方法取各家之長集大成。

服務設計是個跨領域的學科:在福利雲個案中,存在著許多難以撼動、短時間內不易調整的部分,如政府態度、政策走向…等,這些都需要深入理解與學習。服務以人為本,跨領域、跨專業(如社會學、人類學、心裡學…等)也需同時納入考量、理解與權衡。而我們在疏理出這些人後,便能展開訪談研究,歸納分析不同利益關係人所考量的觀點。

質性研究與量化研究有許多不同之處,如何將兩項方法互相結合也是一個需要琢磨的議題。量化研究依憑著數據,能利用數字分析趨勢、脈絡、與市場方向,質化研究則在意現象背後的原因,能深入挖掘用戶所作所為背後的成因脈絡。

綜上所述,我們認為在專案的方法論上帶入服務設計作探討,有利於在訪談、服務創立、以及服務執行的部分更有系統化去做分析,並同時增加深度與廣度。但因為實質上並還未能開始執行,所以目前僅停留在初步訪談的假說建立階段,希望有機會能夠實際去驗證和落地,相信在實際開始執行,會發現更多未曾研究過的問題和想法。

資料來源

(1) BuzzOrange:臺灣的貧窮人口居然世界最低──政府用什麼黑魔法把台灣的窮人藏起來了?
(2) 《This is Service Design Thinking》- Jakob Schneider and Marc Stickdorn
(3) 《The UX Book》 — Rex Hartson & Pardha Pyla

CC BY-NC-ND 2.0 授权