敘事設計是一種比較少見的設計方法， 不藉助常用的設計軟件、設計師也可完全以只用文字來描述方案。當設計方案與視覺元素完全剝離，或許反而能引導我們更加專注地去探索與構建核心流程。
設計師的工作是為難題提出優雅的解決方案，我們從廣泛的想法中探索出可能性，再逐步深入、完善細節。但如何才能恰當地平衡我們在探索設計方向和推敲方案細節上所花的時間？我們所用的設計工具會在很大程度上影響我們思考的細緻程度。
設計師往往通過手繪、草圖來進行初期的設計探索，然而草圖對於用戶和其他團隊成員來說卻難以理解，他們也無法將草圖與實際產品聯繫起來。當然，由 Sketch 或 Figma 一類的設計軟件所完成的高度細節化的設計是很易懂的，但這些高保真原型製作耗時，這也意味着設計師通常無法嘗試太多不同的設計方向。此外，當這一類像素級完美的設計圖被展示給潛在用戶時，人們往往傾向於批評小細節，例如按鈕的間距或顏色，反而會花更少的時間考慮整體流程。缺失樣式細節時，用戶才更容易從整體設計方向上提供更高維度的意見。
更複雜的是，現代應用程序要為多個終端、多個系統設計。在草圖上工作時，我們通常只是被困在其中一個形式里，我們所探索的解決方案也很可能冒着只是針對單一終端優化的風險。
真正理想的情況是，有一種設計方法比草圖更快，且維度足夠高，以至於我們不會把設計方案與任何特定的樣式細節綁定，且這種方式足夠落地，能便於我們分享和展示設計方案，與用戶進行快速驗證。
這些標藍的詞語其實就是「言語行為」，每個詞語都代表了一種獨特的互動類型。
例如，「選擇」是從一組選項中進行選擇，而「指定」對應的是開放性輸入，這些相同的言語行為在不同的系統上有不同的實現方式。在網站上，選項可能被展示在「選擇」按鈕里；在手機上，它可能出現在彈窗列表中；甚至在語音助手上，他可能會從一系列編號列表里被讀出。
然而這些行為本身是一致的，無論在哪種平台上，執行這些特定言語行為所需的認知負荷也是相同的。這種固定的複雜性使我們能簡單快速地評估一個敘事設計的複雜程度。在用戶界面里，每一個 UI 元素最終都是為了實現某種「言語行為」，這些也可以被歸納總結為確認、同意、警告、提醒、道歉、建議、通知等一系列固定詞彙。
因此，選擇合適的「言語行為」，是幫助我們改進設計的第一步。
以從銀行的 ATM 機取款為例，我們知道紙幣的面額是有限的，用戶其實也並不會在意取的錢要具體到幾元。那麼我們只需要讓用戶從不同的常用數額中選擇（輕觸一次即可），而不必讓用戶指定他們想要的具體金額（使用數字鍵盤輸入）。我們也可以把這兩者合併，以「用戶可以從 5 個常用金額中選擇，或者選擇『其他』來自定義金額」來敘述這件事。
用戶理解了支付、賬戶、付款、收件人、地址簿、電子郵件地址、電話號碼和金額，我們設計的整套流程才能夠被使用。明確地列舉出概念可以確保在設計師能清楚地追蹤到自己引入的所有新概念，這些概念也可以通過被識別和歸納屬性來開發，比如，對於一個帳戶來說，它只會對應一個所有者、一個帳號和一個餘額。列舉並提取概念後可以找到用戶進行概念驗證，看他們是否能理解，以確保所有內容有效、易懂。
理清楚概念其實就是在構建產品內容所構成的核心術語詞典。作為設計師，我們要小心地控制我們所設計的「概念空間」。儘量重複利用用戶已知的詞彙，限制並謹慎地引入新概念，是保持設計簡單易用的最佳方法之一。在使用圖形化的工具進行設計時，我們很容易在無意中引入新概念，但在敘事設計中，這些卻很容易識別。
梳理完敘事以後可以把它展示給用戶，快速收集意見與反饋，以迭代更合適的版本。敘事設計對用戶來說很好理解，你可以讓他們瀏覽不同的敘事，詢問他們更傾向於哪個；也可以讓他們自己寫一份敘述，以此與設計團隊所創作的敘述進行比較。
例如，在我們的銀行付款案例中，我們發現，大多數用戶談論付款時，首先指定的是人，其次指定金額，最後才考慮賬戶（除了收款人有多個帳戶的情況）。基於此，我們可能會改變我們設計的流程，調整敘事框架中第 2、3、4 項的順序：
與其他設計呈現方式相比，敘事修改起來要更加高效，因為它提供了一個簡單的框架以評判設計中的風險點和滿意點，並把這些與實際界面樣式所引發的問題分離開。在敘事設計中，我們可以逐字逐句地打磨文案，尋找威脅。
例如，在目前的敘事中，我們的希望讓「用戶指定收款方」，這裡可能就會出現問題：
如果用戶不知道他們應該使用電子郵件還是電話號碼，該怎麼辦？
如果用戶知道電話號碼，但輸錯了怎麼辦？
如果收款方不想提供給匯款人他們的電話號碼，但仍然想得到付款，該怎麼辦？
這些都是可以用敘事來評估和應對的風險。我們可以通過讓用戶從通訊錄中調取號碼、檢查郵箱和電話號碼是否有效、提示用戶他正在向一個不在通訊錄里的新對象匯款等方式來降低風險。這樣一來，整個敘事可能就會被調整為：
當然，並不是所有的風險點都需要被解決的。即使有些用戶可能不想提供他們的電話號碼來接受轉賬，但只要大多數人都能同意，我們就不會特地再調整敘事來滿足這個邊緣案例。相反，如果我們認為這是一件重要的事，我們也可以設計新的敘事來處理這個問題，比如讓收款人訪問一個特殊網站，在那裡生成一次性收款碼，再分享給轉賬發起人。歸根結底，設計師需要在這個過程中判斷風險的嚴重性，以此決定對風險點的處理方式。
類似地，我們也可能從用戶的轉賬行為中發現他們常對同一個人進行相同金額的轉賬，例如給孩子的零花錢、給園丁每周的酬勞，這些內容也可以作為滿意點，被添加到敘述中。
敘事設計的另一個大優勢是，它對開發團隊驗證和預估工作量非常有用。如果設計師只描述我們正在設計轉賬功能，開發者可能認為他們只需要一個簡單的支付 API。但是看到上面的敘述，他們會立即明白這背後還需要更多的後端支持。要判斷用戶以前是否有付款記錄，就需要在用戶付款時存儲信息，並支持快速檢索。要能展示出給某個收款人的默認轉賬金額，就需要能先存儲這個信息。清晰的敘述可以讓工程師了解主要需求，並在團隊沿着某條設計小路走得太遠之前把大家拽回來（例如存儲付款信息太昂貴、難以負擔，甚至可能出於法律原因而受到限制）。
此外，其他團隊也可以為構建敘事做出貢獻。假設安全團隊提出了「用戶可能會上當受騙，向不法分子付款」的風險，而他們已經實現了一種安全驗證服務，可以根據金額和收款人身份來判斷轉賬是否可疑，但該服務可能需要 5 秒或更長時間才能執行。那麼基於這一點，以及不法分子在轉賬中的小體量占比，我們可以將這項安全驗證服務也添加到敘事中，並放在用戶更願意等待的最後一步。
那麼最終的敘事可能是這樣的：
在有很多合規審查的、受監管的工作領域內，例如銀行或醫療，敘事設計會起到很大作用。這些團隊可以在敘事階段就進行審查並提供反饋，以便於有效意見被更早地採納，而不是等到設計終稿完成才介入。
一旦完成並驗證了敘事，它就可以被用來構建各個終端上的具體設計方案。相同的敘述可以在 APP、網站、自動取款機、甚至聊天助手上使用。他們共用一套言語行為和概念，具備了同樣的風險點和滿意點，在無需特殊設計工具的情況下，敘事設計確保了用戶在各個平台上的一致性體驗，讓每個平台能以最有效的原生方式實現我們設計好的「言語行為」。
如在閱讀過程中發現錯誤與疏漏之處，歡迎不吝指出。如需轉載，請註明來自WeDesign。
Miao
留言列表