Matrix 首頁推薦

文章代表作者個人觀點，少數派僅對標題和排版略作修改。

但是由於這個旅程圖是 Airtable 上的 Custom App ，如果要使用必須得是 Airtable 的付費會員，且需要一定程度複雜的前置安裝操作與配置，所以這個使用者旅程地圖雖然看上去和體驗起來都還不錯，但是上手的門檻實在有點高。

另外，從開發層面來看，這個元件的開發體驗並不理想。原因有兩點：

和 Airtable 強耦合

：由於這是一個 Airtable App，所以使用了很多 Airtable 自有的元件，無法脫離 Airtable 複用到其他端（例如網頁）；

開發不太靈活：

如果要開發這個元件時，必須要開啟 Airtable 才能進行開發，導致整個開發鏈路過長，體驗較差；

這也使得我在完成這個 demo 後，就丟在那邊沒有新增新功能和別的優化了。（當然另外一個重要原因也是我之前缺少相關的業務場景）

在最近一週左右的時間裡，由於某些契機，我將這個使用者旅程地圖進行了一遍重構和一定程度的視覺最佳化，並將其提取成了一個元件，進而可以在網頁、Airtable、甚至 Sketch 外掛中作為模組引入，靈活性也大大增強。

在這個過程中，

我無意間探索出一種有意思的工具開發與資產沉澱的模式，

在這分享出來，和大家做個探討

。

使用者旅程圖簡介

首先按照國際慣例簡單介紹一下這個新鮮出爐的東西。說實話我無法用傳統的「元件」、「產品」或者「應用」、「工具」來完美描述我做的這個玩意，可能比較合適的說法是「方法」、「流程」或者「服務」？

歡迎在看完後為它下定義，不過為了方便起見，在本文裡還是用「應用」這個詞吧。

是什麼？

這是一種用文字語言來書寫使用者旅程地圖的（如下圖所示）應用，你可以透過書寫結構化與語義化的文字，輕鬆地實時生成使用者旅程地圖。

為什麼？

我做的這件事情最早的緣起應該是在我之前實習時的一次週會。組裡一位同學在完成一個衝刺專案的設計閉關後，和大家分享了一張在設計前期與多名 PD 同步時製作的產品流程圖，在分享完畢後，大家交流起來。

我主管問：「問個有意思的問題，你這張圖在從第一次做完之後，還有在迭代嗎？」

同學回答說：「做了一些視覺上的微調，後面就沒動了。」

在得到否定的回答後，他就提了一個很有意思的問題：「大家可以想想，

如何使得我們在設計前期做的各種圖（產品流程圖、使用者旅程地圖、服務藍圖等等）在做完之後不變成一張死圖？」

然後大家討論了各自的一些思路，比較經典的應該是利用語雀的表格來進行繪製，但是限制也相對較大。到最後我們也沒有討論出一個非常完美的方案，就乾脆進入了下一個話題。

我相信用 Sketch 畫過這些流程圖的設計師應該深有體會，這種圖的繪製往往費時費力，而且一旦需要修改，往往非常費力，心智負擔很大。這也就導致很多時候除了展示（寫文章、晉升述職）以外，就不會再去迭代更新這些做出來的圖，而隨著時間流逝，專案可能發生了變化，而我們又並沒有及時更新，最後當時花了大量時間製作的圖就變成了死圖。

作為一名 「懶癌晚期患者」，我對於這類問題非常感興趣。因為我及其厭惡所有工作效率低下的繁瑣流程和操作，所以我會竭盡自己所能最佳化自己的工作流，提升效率。針對他提出來的這個問題，當時也沒有想出什麼好的辦法來，所以暫時作罷。

在去年遇到 Airtable 時，我驚奇地發現利用 Airtable 和它的 App 可以非常完美地解決上述場景下的這個問題，並將它分享了出來。但這個完美的前提，則是需要會使用 Airtable，且開通 Airtable 的付費會員。在上週將其元件化與重構的過程中，我萌生了能否讓該元件脫離 Airtable 也可單獨使用的想法。在進行了相關的探索後，就有了現在的這個模樣。

怎麼用？

快速上手

修改文字

在該應用的左側編輯器中修改所有綠色文字和黃色數字時，右側的介面會實時自動重新整理。

新增某個行為

然後也可以透過複製文字來快速建立一個使用者行為。（圖中的快捷鍵是 + + ，代表向上快速複製選中的文字）

隱藏階段

也可以透過註釋掉某一階段，將其在圖中隱藏。（快捷鍵 + ）

自定義顯示區塊

針對一些個性化需求，我也提供了一些配置選項，例如可以在 sections 下面調整顯示的區塊。（移動文字的快捷鍵為 + 或 ）

也可以透過 配置項自定義某些區塊的高度。

與文件平臺整合

文件平臺在某意義上是就是旅程圖的「終端」。在 CodeSandbox 渲染出來的圖整合到文件平臺時，才可以發揮出這個圖的最大價值。（如下所示）

關於如何嵌入到文件平臺，請查閱：

從元件到「元件應用」

簡單介紹完這個應用後，來聊聊這個應用背後整個的思考過程，個人認為這才是這個應用背後最有意思的環節。

CodeSandbox 引發的思考

在這項工作開始之初，我只是想把之前在 airtable 中的 app 提取成一個元件，這樣就可以提高開發效率和體驗。在我完成初步元件化之後，只需要從外部傳入 JSON 資料，就可以渲染出相應的旅程圖，如下圖所示。

需要傳入的資料示例如下：

由於我使用了dumi作為元件開發的文件框架，因此在我釋出完元件包後，經常會用 CodeSandbox 來確認元件是否可以被正常使用。

CodeSandbox

是一個線上的程式碼編輯器，主要聚焦於建立 Web 應用專案。

支援主流的前端相關檔案的編輯：JavaScript、TypeScript、CSS、Less、Sass、Scss、HTML、PNG 等。支援自動程式碼提示。

當在 CodeSandbox 中開啟上述示例時，我突然意識到：

如果依託於 CodeSandbox，將 JSON 資料以文字的形式記錄下來，那麼這個旅程圖就可以與 Airtable 完全解耦！

而一旦解耦之後，使用該旅程圖的門檻就會大大降低，進而真正有潛力變成生產力工具。

圖片畫廊元件

當我腦子有了這個念頭之後，我突然又想到了之前實習時做的一個小東西——圖片畫廊（太小了以至都沒單獨為它寫文章）。

這個元件希望嘗試解決的問題是，圖片類素材在團隊中如何有效地分發、管理和使用。

而這個元件的資料來源也和使用者旅程圖也非常類似，也是採用 JSON 的形式，將資料儲存到文字中。

這個元件的設計加開發用時差不多 兩三小時，至於程式碼也就短短百行左右，但是結合內部的一個程式碼託管平臺，就可以嵌入到語雀中，作為圖片素材的管理中心文件，恰到好處地解決了痛點問題。

結合之前做到一半的Mindflow，把這三個東西放在一起時，我突然意識到了一種潛在的

「資料文件」 搭配 「可視元件」的「元件應用」

。

元件應用，顧名思義，就是應用的主體就只包含一個元件。由於只包含有一個元件，所以開發成本比起完整 App 要低很多很多（甚至在大部分時候可能只需要完成檢視的展示即可），同時透過該元件又滿足了該場景下絕大部分需求。

資料文件：JSON 與 YAML

但是我們知道，只有元件是沒法對資料持久化的。那資料的儲存該怎麼辦呢？這就要交給前面所提到的「資料文件」了。「資料文件」指的是將之前存到資料庫裡的資料（一般為 JSON），以文件的形式進行儲存。這樣一來，所有對資料增刪改查的互動操作，則全部由文字編輯器來兜底。

這裡還有個小問題：在前端元件中，資料透過 JSON 進行儲存，但是 JSON 是一種機器化的資料結構，非常不易於人類閱讀與書寫（如下圖左側所示）。如果資料文件用 JSON 儲存，那麼對人類來說會非常不友好。

所以這就引入了資料文件的主角：YAML。

YAML 在開發中是專門用來寫配置檔案的語言，非常簡潔和強大。透過非常簡單的語法，就可以寫出豐富的文件結構。

同一資料內容的 JSON 與 YAML 的對比

在 JSON 中需要用大量的引號、大括號、中括號和逗號才能表達的資料，在 YAML 透過縮排和 就可以表達，因此 YAML 是一種非常易於使用者書寫和閱讀的語言。（如果你瞭解 Markdown，那麼你就能理解 YAML 與 JSON 的關係 ——YAML 相當於 Markdown ，而 JSON 相當於 HTML）

寫 YAML 文件在很大程度上和書寫普通的文件沒有太大的區別，只是需要注意一定的結構規範（即 YAML 的語法和使用者旅程圖相應的語法），例如：

雖然上述示例好像存在一些看不懂的英文，但事實上將它們簡單翻譯一下（stages：階段、name：名稱、actions：行為、emotion：情緒值、thoughts：想法、painPoints：痛點），就會發現其實是就是一些人話：

我相信這樣的資料文件，是任何一名設計師都可以輕鬆學會的。

而事實上，在我看來，使用 YAML 書寫使用者旅程地圖的資料文件，和我們寫普通的 Markdown 沒有什麼太大區別，只需要遵循一定的語法規範即可。這樣一來，我們就可以使用這種符合規範的「資料文件」，在「元件應用」中得到相應的使用者旅程地圖。

文字編輯器兜底

文字編輯的互動是最自由的手段。而基於 VSCode 編輯器框架開發的 CodeSandbox 包含了大量文字編輯的高效互動。 雖然可能的確不如視覺化編輯器那麼直觀，但是一旦上手後效率奇高無比，一些在傳統應用中無法做到的調整需求，都可以用文字編輯器快速達成。因為 CodeSandbox 集成了 VSCode 的編輯器框架，因此大部分使用 VSCode 的編輯技巧都可以用在 CodeSandbox 中，下面就舉了兩個例子。（感興趣的小夥伴可以自行查閱相關技巧，我在這裡就不寫了）

註釋

採用文字編輯的很大的好處就是可以利用註釋（標記符 ）來承載資料之外的資訊，例如這張圖是在，則可以在頂部加入與會人員、時間等資訊，針對某些具體的階段，也可以補充必要的相關資訊。而這在傳統的旅程圖工具、或者其他各種非文字類的工具中可能都沒有非常好的備註方案。

程式碼塊摺疊

YAML 可以算是一種語言，因此 CodeSandbox 會將我們書寫的文件當成程式碼來著色，譬如關鍵字是紅色，註釋是灰色，字串是綠色、數值是橙黃色。同時這樣一個文件也具有了摺疊與展開能力（如下圖所示）。這樣一來，哪怕文件多長，我們都可以用程式碼摺疊的方式將注意力聚焦到關注的文件塊中。

同時，CodeSandbox 提供了 10+ 關於摺疊與展開的快捷鍵，幫助我們提效（紅色框出來的是算比較常用的）

元件應用 VS 傳統應用

在傳統的雲端應用（例如 Figma 等）中，我們往往需要將資料儲存到後端資料庫中，資料的展示介面是一個完整的應用產品，包含登入註冊等區分使用者的基本流程。而在傳統的桌面端應用中（例如 Sketch），該應用往往會自定義一種檔案字尾形式，將其與應用進行關聯繫結，檔案的讀取、修改、儲存都由軟體來控制。

「資料文件」搭配 「元件」的「元件應用」，則是介於兩者之間，是一種適合低頻、小眾場景的應用解決方案。簡單對比如下：

還可以幹什麼？

在完成使用者旅程地圖這個「元件應用」後，我還進一步探索和思考了一下使用者旅程圖元件的應用可能性：

與 Git/Github 整合

：如果我們希望將旅程圖可以成為專案資產，那麼用工程化的方式進行管理非常重要。由於每張旅程圖本質上就是一個 YAML 檔案，那麼我們就可以用 Git 和 Github 的方式做到工程化管理。甚至結合我之前做的Gitmoji Commit Workflow，就可以自動進行更新日誌生成與版本管理。（具體咋做展示不展開了，不過感覺會這麼做的人應該還比較少，就放一個模板供參考吧。

檢視樣式切換

：在完成初版旅程圖時，我將這個工具發給了我周圍的小夥伴進行體驗，就有小夥伴給我提出，是否能夠在檢視上顯示一些重點行為，例如情緒值比最高和最低的幾個行為修改顏色，這樣一來可以幫助我們快速聚焦需要最佳化的產品環節。如果把這個功能完成了，我相信這個旅程圖元件將不再僅僅是一個展示圖，甚至還可以變成輔助分析的效率工具。

動態使用者旅程地圖：

如果我們能夠基於 Git、Github 完成旅程圖的工程化管理，那麼我們是否就可以獲得不同版本號的旅程圖？這樣一來我們是否可以把這樣一個旅程圖變成一個專案監控工具？例如在情緒地圖上觀察 v1。0 版本和 v2。0 版本的差異，有哪些環節的使用者體驗情緒提升了，哪些環節使用者體驗情緒降低了，進而判斷產品迭代的狀況。如此一來，使用者旅程圖就不再變成死圖，而是有實用價值的監控圖。

對於這樣一個「元件應用」，大家有什麼想法呢？歡迎在評論區 「做夢」，說不定我哪天就把它們實現了呢~

最後的一點點感想

你的下一個應用，未必是「應用」

前段時間看到《你的下一個應用，未必是程式》，其中有一段話讓我深有共鳴：

因此，與其關注應用是什麼，不如關注應用能做到什麼、是如何做到的、有沒有尊重我們的選擇和權利。與其關注一個應用是工具還是服務、原生還是「套殼」、買斷還是訂閱，不如關注它能否滿足需求、提高效率、創造價值。

抽象意義上來說，「應用」是對特定場景的一組功能集合，來滿足該場景下的需求、提升效率、創造價值。而在各種應用、SaaS 服務大行其道的今天，多少應用開始主動或被動地偏離這種初衷。畢竟一個完整的應用無法完全聚焦在功能本身。為了提供相應的服務，往往還需要使用者體系、資料儲存等各種其他功能模組。這一方面提高了自身的開發成本，又在另一方面在資訊流動的過程中不自覺地豎起了一堵堵高牆，一點點阻礙了多種應用間協作的可能性。而我現在探索的「元件應用」，說不定就是一種「應用」新方向了，對於足夠輕量化和小眾的場景，也許可以試試這樣的模式。

說不定在未來，

你的下一個應用，就未必是現在的「應用」了。

創造資本

《小島經濟學》裡中有個非常打動我的故事：

從前，有三個人一艾伯、貝克和查理住在一座島上。島上的生活艱苦，他們三個人只能每天打漁，然後吃魚。一開始的時候，每個人用一天的時間只能打到一條魚，而填飽肚子，也正好需要一條魚。

有一天，艾伯突然有個靈感，想做個捕魚器，這樣就可以嘗試捕魚的新方法，有了這個捕魚器，捕魚的時間就能縮短，這樣再也不會餓了。但是為了織這個漁網，艾伯需要挨一天餓。

查理得知艾伯的想法後，驚得眼珠直轉，他想自己的朋友肯定是瘋了。「你瘋了，這樣做，我告訴你，要是你這捕魚器不好使，可別哭著來跟我要魚吃，一片也別想。我頭腦清醒，但這並不表示我會為你的瘋狂做法埋單。」

艾伯沒有被査理的話嚇倒，仍然繼續織網。到這一天結束時，艾伯終於織完了自己的漁網。

而第二天，其他人還是隻能打到一條魚，而艾伯打到了好幾條魚。

作者講完這個故事後做了一個提綱挈領的總結：

透過自我犧牲（也就是捱餓），艾伯創造了資本。

現在普遍的觀點認為都「去上班就是在出賣自己的勞動力，就是被資本持續地剝削」，而這種觀點雖然沒有什麼大問題，但是可能過於消極了。可能由於我們已經過了生產力極度貧乏的階段，所以大家漸漸將資本直接等同於金錢，進而忽略掉了資本最初誕生時的模樣。

小島經濟學用非常生動形象的故事告訴我們，我們任何提高效率的嘗試和努力，所形成的「效率工具」、「工作流」或者「方法」，其實都是在「創造資本」。雖然它們不是真金白銀，但是這其實才是資本原來的模樣。

哪怕到現在為止，我依舊保持著對效率的極度追求，在這個追求的過程中也不斷創造著新的「資本」，這個使用者旅程地圖就是如此。這麼多年無數積累下來的資本，讓我具有了很高的工作效率和產出，讓我有足夠的底氣面對任何工作，我想這說不定也是當下的一種破局之法吧。