編輯導語：在進行服務設計的過程中，服務藍圖是一個有效工具，只是，服務藍圖這一工具并非一成不變，在實際業(yè)務和場景實踐中，業(yè)務人員可以靈活地應用服務藍圖。本篇文章里，作者結合就服務藍圖這一工具進行了總結，一起來看。

谷歌“服務藍圖”，你很可能會看到NN/g 的這張例圖：

來自于NNGroup.com.

在本文中，我不會嘗試教授服務設計或如何創(chuàng)建服務藍圖。相反，我將告訴你，我如何擴展這份通用文檔，以使其更有意義、更具操作性且更有幫助。

雖然目前常規(guī)的服務藍圖模版已經(jīng)很不錯了！但是，如果它可以講述更多的故事，然后使我們能夠解決更多的問題，這樣豈不是會更好？

藍圖上的一切都順利嗎？可能不是。然而，當你看到它被繪制成這樣時，很容易假設人們“完成了”并且進展順利。

哪里出了問題？怎么辦？

如果查看和接收此文檔的團隊成員對端到端旅程有更完整的了解會怎么樣？

如果額外的細節(jié)可以幫助我們理解這個旅程需要徹底的改造而不是漸進式改進怎么辦？

一、這是我的新服務藍圖模板 v1.0，以及它是如何得到的

我知道這張圖看起來有點大……我們會在后面具體談到……

用 UXPressia 制作 你可以用任何你喜歡的工具來做這個！

二、首先，我為你在其他地圖上看到的常見事物添加了泳道

度量指標：圍繞流程的這一步，我們看到了哪些指標？這些是否可以滿足用戶或業(yè)務目標？對于未來的狀態(tài)，服務藍圖，這可能是我們計劃在旅程對應階段衡量改進的方式。KPI 和 OKR，以用戶為中心和以業(yè)務為中心。

風險、政策和注意事項：我認為這一點可以作為默認的 [1]服務藍圖泳道。究其原因在于體驗的這一階段，客戶、我們的產(chǎn)品或公司面臨哪些風險？在這個接觸點是否有我們必須考慮的政策或合法性？

（[1] 泳道圖：泳道圖也稱跨職能結構圖，由多條“泳道”框架與相應的流程內(nèi)容構成?？芍庇^體現(xiàn)流程環(huán)節(jié)發(fā)生在某職能群體，從而區(qū)分事件主體并反映各職能群體的關系。）

機會和建議：這些是我們的見解、機會和高級想法（不是解決方案）。這些通常在客戶旅程地圖上。

我將這些添加到 服務藍圖底部的支持過程下。

UXPressia 有一條用于“流程”的 泳道，顯示此步驟是否趨于線性、略微的曲折、抑或是周期性等。我想我也會對此進行試驗，但我不確定我是否會保留的。

我還添加了“渠道”以顯示此 步驟或接觸點發(fā)生的位置。店鋪？電話？計算機？或 別的地方。這是一個全渠道的世界，所以我想知道這是否會有所幫助。

三、然后，我問自己我可以從任務分析和優(yōu)化任務流中得到什么

自從學習任務分析和優(yōu)化任務流程以來，我更喜歡客戶旅程地圖或待完成工作（JTBD）。在觀察研究之后正確地進行任務分析，可以讓我們看到端到端用戶體驗的所有方面。

這包括：

問題、麻煩和障礙：在這一步發(fā)生了什么可能阻止了我們的用戶或造成了障礙？客戶在這里可能有什么問題？到底是在哪個流程出了體驗問題以及問題是如何發(fā)生的？

工具、知識、變通方法：這是我從 Larry Marine 學到的任務分析方法之一。在觀察研究期間，觀察人們在哪里引入外部工具，創(chuàng)建他們自己的工作區(qū)以試圖使他們的任務更好，或者缺乏我們的產(chǎn)品或服務所需的知識。

例如：人們需要一個計算器（工具）。他們使用了備忘單（解決方法）。他們不得不去查找供應商編號或他們的帳號，因為我們的系統(tǒng)需要它，但他們不知道（知識）。

MI、EP、CD、KD：這些代表手動密集型（大量手動工作或步驟）、容易出錯（可能會犯錯誤）、認知要求高（不要讓我思考）和知識依賴（系統(tǒng) 假設用戶知道或記得他們可能不知道的事情）。

這些就是有時會被忽視的問題和痛點，因為“人們會弄清楚的”。即使他們最終弄明白了，用戶也討厭這一點。你也會討厭這樣。識別這些問題及其細節(jié)是減少（如果不解決）問題的第一步。

有時，我們的團隊成員、領導者或客戶會看到一個旅程地圖，并假設每個步驟都輕松完成或“足夠好”，我們就不會費心去嘗試使這一步或整個過程變得更好。如果我們開始將痛點、障礙和干擾的細節(jié)帶入服務藍圖，我們就可以更詳細地講述故事。細節(jié)非常重要！

任務分析和優(yōu)化任務流 對于 CX/UX（客戶體驗/用戶體驗） 團隊來說是很棒的地圖和文檔，但它們的缺點也很明顯，它們有時對其他人來說是壓倒性的，即他們不確定如何或在哪里采取行動。它們指導 CX/UX，是 UCD 的重要組成部分。

而我則希望將其中的一些內(nèi)容引入服務藍圖中，可以讓我們的隊友和領導者以更易于理解的格式更容易訪問和獲取這些細節(jié)。我們?nèi)匀豢梢赃M行任務分析和優(yōu)化任務流，但可能將它們保留為“內(nèi)部”文檔。

四、嘿，人們的感受或情緒水平在哪里？

我沒有這些感受或情緒內(nèi)容，因為去假想我們真的知道人們的感受是非常自負的。如果用戶沒有說，“現(xiàn)在，我覺得_____”，我不想對他們的感受做出任何假設。

如果什么東西使某一步驟有疑問、問題、障礙、認知強度、可能的錯誤等問題，而且這種狀態(tài)下也無法幫助參與者理解人們在此步驟中可能“感覺”的內(nèi)容，你當然可以在客戶行動泳道中添加笑臉、中性臉和悲傷的面孔。

我添加了“思想/行情”泳道。如果我們有確切的研究引述，請使用它！這總是比編造的引述或關于人們感受的假設要好。如果你一遍又一遍地聽到相同的情緒，你可以將其匯總為示例表述，我將其稱為想法。再說一次，我真的不知道人們在想什么，除非他們大聲告訴我他們在想什么。

讓我們確保我們沒有編造這個（或服務藍圖上的任何東西）。這一切都必須來自觀察性研究。

五、這個模板看起來真的很大

服務藍圖通常用于根據(jù)客戶體驗以及我們的內(nèi)部流程、人員等來繪制和解決更大的挑戰(zhàn)。這里的目標不應該是我們可以制作的最小或最高級別的地圖。你可以這樣做，但問問自己你可能會錯過什么，以及這會如何影響項目、目標和風險。

所以……真的是太大了。如果你有一些不需要查看所有內(nèi)容的觀眾，UXPressia 可以讓我創(chuàng)建隱藏某些泳道的視圖。我仍在試驗這個，但我可能會給人們完整的文檔而不是精簡的版本。

六、我可以與利益相關者和團隊成員討論這個問題嗎？

NN/g 為研討會提出了兩種選擇：

預先對此進行討論，并讓人們對其進行猜測。然后，你可以進行適當?shù)难芯浚⑸院笙蛩麄冋故灸男┙Y果正確，哪些結果不正確。

進行適當?shù)难芯?，自己（或在你?CX/UX 團隊中）進行研究，然后舉行研討會。向所有人展示你在研究中學到的東西，向他們展示你在這里描述的東西，看看人們可能想要添加什么，但不要讓他們添加任何猜測或假設的東西。這一切都必須來自研究。

我的觀點是，只有 第二種 才真正有意義。我想不出一個很好的理由來浪費人們的時間猜測某事只是為了以后證明它是錯誤的。這可能會傷害某些人的自負或感情，并使你看起來像是在證明別人是錯誤的。

NN/g 明白，有些人如果不先做 1，就無法獲得研究支持，然后說研究將驗證/無效/填補缺失的部分。所以如果你必須這樣做，你也可以用第一種方式，但上面的選項 2 是最好的方法。節(jié)省時間、金錢、自負，以及以后的“嘿，我在研討會上添加的東西怎么了？！”

七、最后，在未來的狀態(tài)上工作

我還不會參加研討會，但正如你們許多人所知，我對研討會并不感興趣。:) 我會讓我的團隊在 服務藍圖的未來狀態(tài)上工作，優(yōu)化用戶的旅程并簡化內(nèi)部和后端流程、人員、支持和技術。

我會記錄 CX （客戶體驗）戰(zhàn)略的北極星，以及我們未來幾個季度或發(fā)布的優(yōu)先事項。

然后我會討論未來狀態(tài)，讓每個人都對它保持一致。一旦我們讓每個人都在場并且他們提出了自己的觀點，我們就可以重新考慮優(yōu)先級……比如產(chǎn)品的觀點，工程研究什么是可行的，等等。

我們必須確保我們不會犧牲客戶或用戶體驗。營銷人員可能想要更多的郵件列表注冊，但網(wǎng)站訪問者想要嗎？銷售人員可能想給人們打電話 12 次，但潛在客戶想要嗎？隨著我們向以客戶為中心的轉(zhuǎn)變，我們將不得不開始根據(jù)潛在客戶和當前客戶是誰、他們的任務和需求做出更多決策。

這意味著團隊成員必須相信，當我們創(chuàng)造更好的產(chǎn)品和服務并提高客戶滿意度時，我們將實現(xiàn)我們的業(yè)務和財務目標。我們不需要技巧、黑暗模式和彈出窗口來讓人們忠誠和快樂。我們將達到或超出他們的期望，使他們自然忠誠和快樂。

八、這是1.0

這是我實驗的第 1 版。我希望以后會有其他文章介紹我如何改進它！你會對此有何改變？如果目標是帶來更多細節(jié)以使其更具可操作性，你會添加或刪除任何內(nèi)容嗎？

本文翻譯已獲得作者的正式授權（授權截圖如下）

原文作者：Debbie Levitt

原文地址：https://rbefored.com/experimenting-with-expanded-service-blueprints-3d22c724ca25

譯者：孫晨宇；編輯：李莉好；微信公眾號：TCC翻譯情報局（ID：TCC-design）；連接知識，了解全球精選設計干貨

本文由@TCC翻譯情報局 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議