系統性設計工具|為複雜的服務而設計

近十年來,透過研究和不斷地實踐創新,系統設計已經發展成為一門學科。本篇文章將介紹一種系統性設計工具,它連線了系統思維、以人為本的設計和服務設計方法,以應對複雜的系統環境,為設計師提供了唯一完整的系統方法,快來看看吧。

系統性設計工具|為複雜的服務而設計

本文將介紹了一種系統性設計工具,即Systemic Design Toolkit ,它為設計師提供了唯一完整的系統方法,為參與式工作坊設計了 30 多個系統建模畫布。透過數十個app、學術培訓和研討會的驗證,該工具包

連線了系統思維、以人為本的設計和服務設計方法,以應對複雜的系統環境。

一、系統視角的服務設計

近十年來,透過研究和不斷地實踐創新,系統設計已經發展成為一門學科。

在服務設計中,我們經常發現與更大系統互動的挑戰內容,通常被認為是服務基礎設施的最佳化與改善。

當服務設計挑戰的規模和複雜性擴充套件到“系統級別”時,以使用者為中心的設計方法無法滿足所需的複雜性。

角色、旅程和藍圖雖然非常適合複雜的組織流程和數字服務,

但是,當組織挑戰與複雜系統的邊界重疊時,包括公共服務、基礎設施、政策和自然生態系統,設計的挑戰空間就會從複雜轉向複雜。傳統的設計實踐缺乏工具來描述和建模足以應對高複雜性的可行解決方案。

越來越多的設計師被要求解決我們幾乎沒有接受過學術或實踐培訓的轉型挑戰。作為從事大型服務或數字平臺的創意設計公司,我們在為複雜的組織或系統進行設計時可能會表現出“初學者的信心”。

大多數服務設計專案透過服務交付、多種渠道、互動和技術系統為組織向客戶提供的產品建立流程。系統設計擴充套件了設計的環境,使用系統方法讓多個組織和利益相關者參與進來,使服務系統能夠跨多個層次和規模進行設計和定義。

我們將系統視為高度互聯的社會和技術組合,它們作為一個整體發揮作用——不是作為交付過程,而是通常包含提供直接價值的服務。與服務不同,系統沒有單一的“所有者”,客戶的責任可能不明確。沒有人擁有氣候、交通,甚至經濟。複雜的醫療保健超出了醫院的界限,一個完整的系統解決方案可能會涉及多個提供者和過渡。

系統設計工具包使服務和戰略設計人員能夠促進利益相關者有效地共同建立複雜系統。該工具包獨特地解決了複雜的系統挑戰:

提供的工具可以對映整個系統、語境、系統內的人類行為,以及連線系統內的服務。

企業服務設計需要定義與系統的關係的工具,以識別相關係統中服務互動的風險和潛力。

系統設計超越了“使用者”,以來自許多系統利益相關者的包容性貢獻的知識和經驗為基礎。

這些工具有助於定義包含許多複雜任務的社會技術系統(例如醫療實踐,其中專業裝置、培訓和資訊學緊密結合)。通用設計工具不足以持續、迭代地開發大型社會技術系統所需的專家知識。

一些客戶和組織在運營、技術和服務交付方面面臨著日益複雜的問題。組織、服務和商業模式在其系統環境中變得更加糾纏(例如大型醫療保健提供者),

使用“線性”設計方法無法揭示這種矛盾和糾纏。如果我們不能將這些糾纏不清的政策和管理觀點納入服務設計,那麼系統變革的潛力肯定會受到限制。

Systemic Design Toolkit 提供了一系列工具和視角,用於跨多個社會系統對映和協調提案,支援團隊讓更多利益相關者作為共同設計者參與進來,以代表所有服務提供商。

二、服務和系統邏輯的差異

我們現在正面臨每個功能級別,也正在處理更高的複雜性問題。組織在流程和服務管理方面面臨更高的複雜性(連通性),並且必須信任許多不受其控制的平臺。跨境供應商網路、雲服務和不斷變化的監管流程需要適應性。我們設計的服務可能位於日益脆弱的系統中,並被無形的相互依賴和隱藏的技術複雜性所強化。

服務主導邏輯(Service-dominant logic)是服務設計中的一個關鍵概念,即將客戶視為服務提供中價值實現的共同生產者。當客戶表示滿意時,企業傳遞的價值就被認可,並且客戶是價值鏈中存在真正的終點。

在系統邏輯中,客戶和供應商不僅是提供服務和互動的參與者,而且他們還積極地與其他利益相關者聯絡起來,形成一個包含過程。價值傳遞是多個系統互動和反饋的共同結果。我們可以針對該價值進行規劃和設計,但它的實現是一個隨著時間的推移的集體過程。

如果我們採用以使用者為中心的設計來增強複雜系統中的服務體驗,我們就有可能降低整個系統的效率。

考慮一個小規模的例子,我們可能會改善醫療辦公室的“候診室體驗”,但無法減少因排程過程和醫院系統延遲而導致的等待時間。在更大範圍內,由於在政策層面設定的排程優先順序,可能會出現危及生命的癌症手術排程延遲。

在這種情況下,如果我們不能解決根本原因問題,我們只能改善患者的本地體驗。此外,透過不挑戰根本原因,我們可以長期避免根本問題。

我們經常為客戶提供商或其服務交付平臺設計服務,但系統沒有單一所有者,有時還會交叉衝突的利益相關者。產生有效服務建議的方法、模型和對話可能無法擴充套件到複雜的系統。它們不僅是規模差異,而且是型別、知識、模型、參與者和治理的差異。

由於系統級決策可能會對底層管理組合中的所有服務產生相應的影響,因此設計需要訪問整個系統的許可權和參與者,超出一個服務的邊界。雖然服務商業模式透過收入提供價值回報,但全球健康、國家醫療保健或移民政策等系統必須在眾多所有者、眾多參與者、平臺甚至政府之間共同創造共享價值。

政策平臺的服務設計通常位於現有的基礎設施和社會技術系統 (STS) 中。STS 是相互關聯的工作流程,其中集成了技術以實現編纂完善的流程,例如藥物輸送網路(在全球健康領域)或電子健康記錄(在國家醫療保健領域)。醫院可以被視為多尺度 STS 的複雜組織。

三、系統化設計拓展服務邊界

服務專案什麼時候進入一種系統級別?服務是一個有邊界的過程,通常包含在一個更大的系統中。單一醫療保健提供者的服務商業模式不能改變管理所有醫療服務的系統(例如付款人或保險系統)。

服務設計可以利用系統工具來構建系統模型,這些模型為更有效的通用特性提出論據,以便為服務和包含系統中的利益相關者提供服務。

所有設計方法都可以用於定義服務和系統價值之間的這種關係。我們看到了互動、服務和系統設計之間的關係,如圖 1 所示,每個具體的功能相互關聯。互動設計是一種深入的、基於證據的實踐,對於定義使用者互動、資訊使用和服務接觸點中出現的體驗是必要的。它不是設計階段,而是貫穿所有服務流程。

系統性設計工具|為複雜的服務而設計

圖1。Systemic design extends service design to the system

一般來說,服務設計為提供商開發綜合解決方案,以共同創造非凡的服務體驗,同時隱藏複雜的背景互動。系統設計不會重複這些或使方法變得多餘。其具體目的是在利益相關者驅動的設計決策的推動下,為政策和多組織系統創造系統價值。

圖 1 顯示了系統設計的幾個顯著特徵。這些是與工具包中的實踐相匹配的系統功能,處理系統定義(框架、建模)、多組織環境中的利益相關者發現、系統變更的設計干預和系統價值主張。

四、系統設計工具包

系統設計作為一個領域已經發展了十多年,沒有推廣任何標準的方法規範。系統設計工具包是從系統設計理論和實踐認可的共識方法中選擇的工具平臺。

比利時設計公司 Namahn 領導了工具包的設計(繼他們成功的服務設計工具包之後)。Namahn 和設計合作伙伴 shiftN 在 RSD5 Symposium(多倫多,2016 年)的研討會上對原始工具進行了測試。與多倫多的 MaRS 解決方案實驗室和系統設計協會建立了合作伙伴關係,以啟動和維持該工具包。

透過教育和客戶實踐,該工具包已演變成一種系統方法,將服務明確連線為複雜系統中的干預措施。

該工具包是系統設計中唯一可公開獲得的參考方法來源,並提供支援和培訓。與其說代表一種確定的方法論,我們將工具包視為一種使用各種系統方法開發的不斷髮展的過程模型。

透過七步方法(見圖 2),該工具包為設計主導的團隊提供了一個系統,用於讓利益相關者參與框架和願景、繪製趨勢和系統動態、定義價值和干預措施以及規劃過渡戰略。繪製的地圖用作最終形式視覺效果的輸入,供客戶和利益相關者團隊用於設計規劃,以跨服務和系統共同創造價值。

系統性設計工具|為複雜的服務而設計

圖2。Systemic Design Toolkit methodology (systemicdesigntoolkit。org)

五、系統的設計方法

這七個步驟整合了系統和設計方法,在系統思維和設計思維(底部步驟)之間交替。與每個步驟相關的關鍵方法顯示了工具包的廣度和方法:

構建系統:邊界、上下文和參與者/利益相關者對映

傾聽系統:隱喻、設計研究

理解系統:系統對映、反饋迴路、綜合對映

定義理想的未來:價值主張、遠見模型

探索可能性空間:干預策略,悖論

設計干預模型:干預、組織

促進轉型:轉型戰略

雖然大多數 Toolkit 方法直接由經典系統參考提供資訊,但我們已經創新了一些作為實踐實驗(例如隱喻和悖論)。Toolkit 方法很靈活。根據我們的經驗,沒有專案會使用所有工具,在工作坊中,可以將步驟安排為分階段的會議。根據專案階段以及設計範圍、時間和知識可用性,這些工具可能會根據專案進行調整,以促進專案定義階段之後的設計。

系統性的設計工具最終賦能於複雜性系統語境和解決複雜性系統問題,大家可以透過檢視系統設計工具相關的官網獲得系統設計工具模版,可以借鑑和學習。

原文作者:Dr Peter Jones,Kristel Van Ael

譯者:Yeutz CHEN,陳昱志Yeutz;微信公眾號:YeutzDesign(ID:Yeutzsheji),專注於服務設計領域,致力於服務設計創新轉型研究。

本文由@Yeutz CHEN 翻譯釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部