5 個有效步驟：讓利害關係人的想法更以用戶為中心
這裡的目的，是希望大家在實戰中，在業務方的強大壓力下，不忘 Design Thinking 的操作。
在現實中，你有沒有發現十分困難去實行學習到的 Design Thinking？
為甚麼經常都像被業務方帶著走？
其他設計團隊又是怎樣做到以用戶為中心，做到設計出解決用戶問題的方案？
現實中大部份情況的設計團隊都沒有走完 Design Thinking 中的五個階段，他們又是用了甚麼方法做到以用戶為中心？
這篇文章為大家介紹其中一個我常用的方法：
5 個有效步驟，讓利害關係人的想法更以用戶為中心（實踐 Design Thinking）：
1. 深入理解利害關係人的想法
2. 將他們的初部想法轉化為假設
3. 先不反對也不讚成所有想法，建議進行慨念測試或研究
4. 收集更多想法，變成以用戶為中心的假設列表
5. 進行慨念測試和迭代
1. 深入理解利害關係人的想法
在我和利害關係人的定期 1:1 Coffee Chat 中，很多時候會聽到他們一些『有趣』、甚至乎是『新奇』的想法，有可能是一些直觀地想解決業務問題所產出的想法。
這不是他們的錯，他們是業務方，提出設計方案的應該是我們設計師。
我會去做兩件事，『積極傾聽』和『理解他們的 OKR / KPI』：
i. 積極傾聽：
先了解一下他們提出想法背後的原因是甚麼？如果你並不清楚他的原意的話，可以提出問題，例如：
好奇想知道，這個想法背後的主要目標是什麼？
如果可以的話，就嘗試替他說出來。變成：👇🏻
你這個想法背後，是否想（達到某個效果或目標）？
另外一些參考的問題，這個可以試探一下對方有沒有曾以用戶角度去想：
如果這項變更/想法完成了，您認為對用戶或業務會帶來什麼樣的影響？
ii. 理解他們的 OKR / KPI：
如果你在不太了解業務方的 OKR / KPI 的話，可以考慮這樣問：
請問目前您的團隊 OKR 是什麼？我問的目的，是想看我（或我的團隊）可以怎樣幫忙。
我們希望透過這個項目，達到哪些具體的績效指標或 KPI？
您會如何衡量這項變更的成功？
2. 將他們的初部想法轉化為假設
案例：利害關係人想在一個 B2C 的網頁平台上，加上即時聊天的 CHATBOT 功能
利害關係人：「我們應該新增即時聊天的 CHATBOT 功能。」
這時候可以再追問，問一些他關心的話題，比如說業務指標：
對於這個想法，您心目中有甚麼具體的業務指標？是否您之前提到的節省客服時間？
利害關係人：「對。如果我們在網頁上新增即時聊天的 CHATBOT 功能，我期望我們將能夠節省 20% 客服的時間。」
聽到這裡，有經驗的設計師便會知道，這根本不是從解決最終用戶的問題，因為指標是純粹節省成本（在業務來說沒有錯。），解決『內部用戶』問題。
大部份的情況，『內部用戶』不會是 B2C 產品的最終用家。
當然也會有這情況，我之前也曾經幫忙研發一些內部平台，它的用戶真的只供那十多個的內部同事去用。
我舉的這個例子，是利害關係人想在一個 B2C 的網頁平台上，加上即時聊天的 CHATBOT 功能。 而 B2C 的網頁平台的最終用戶，一般是大眾消費者。
作為團隊中的 UX 設計師，面對上面只有『方案』和『業務指標』的描述，你便需要跳出來，替他重新表述。
如果你本身已經對平台用戶的問題有一定了解，你可能之前已經從觀察得知一些用戶問題，你便可以主動替對方完成一個『假設』。
在原來的『假設』裡，加入『用戶痛點』和『預期的用戶行為』：
如果你手上沒有用戶資料，可能是將對方說的先『方案』和『業務指標』記錄下來，之後再去尋找相關的用戶洞察，可以是透過後台數據，客服同事訪談，網上客戶反饋，以前的使用者研究。
當得到一些用戶洞察後，便可以將他的想法變成一個有陳述『用戶痛點』和『預期的用戶行為』的『假設』。
「如果我們即時聊天的 CHATBOT 功能，那麼我們將會節省 20% 客服的時間，那我們也期望用戶也會因此較容易找到『如何取消信用咭年費』的方法，不用『在綫等候太久』。
這樣，一個較完整的『假設』已經完成，並且包括了業務指標、用戶痛點和預期的用戶行為。
當然 ，真實的對話和過程一定會比上面的要複雜和艱難，但上面的是一些參考的步驟，讓利害關係人的想法，通過你的提問和幫助之下，一步步成為一個較理想的假設。
之後便要找機會向這利害關係人論述以上的『假設』，看他的反饋如何，並強調這到現在只是一個假設，你需要分享你之後的計劃：
3. 先不反對也不讚成所有想法，建議進行慨念測試或研究
這是經常發生的情況，很多時候，我們（包括設計師）都會有一些想法，並且強烈認為一定會成功。
通常的情況是：我們沒有時間做太多測試，完整的 Design Thinking 過程並不常發生，也就是說，Design Thinking 中的 Phase 1: Empathy，通常在團隊裡沒有通過研究來產生共情。
我們接下來要做的便是將所有相關的想法變成假設，最好混入自己或設計團隊的一些想法，然後拿去做一次性的測試。
這裡有一個心態很重要：
我們並不是要去證明利害關係人的想法是錯
事實上，有時他們的想法可以是極好的主意。我們的職責是讓團隊跟用戶洞察接上，讓『以用戶為中心』的思維在團隊裡漸漸培養起來。
反過來說，我自己即使有多年產品設計經驗，熟悉各種設計原則，但由於『我始終不是用戶』，最終的方案也試過失敗。所以到底我們的『假設』有沒有效，還需要用戶來告訴我們。
而對於要安排做測試，相信大家最常遇到的挑戰，便是沒有時間做測試：
可以用以下的 3 個方法，來讓大家創造『時間』出來。
i. 傳達價值：
清楚表達測試想法的好處，例如降低風險、驗證假設，並最終在長期內節省時間和資源。使用數據或案例研究來強調用戶測試如何帶來更好的產品結果。
如果功能規模較大和複雜，且不是每一個競爭對手都有的功能，我的一個想用的方法：
便先向產品經理清晰表達你的擔憂，及其後果。
如：『我不確定用戶會否使用，萬一開發了要改便太遲了。我需要只是多兩星期左右做一個測試，而之後我們便會知道我們的想法有多信心。如果強行開發，我擔心開發那邊不久後便要花幾個月時間，將功能改回來。』
產品經驗和開發那邊最害怕的，便是開發了沒有用處或用處不大的功能。這樣的話，產品和開發便會站在你那邊。
ii. 提出快速且有效的測試方法
建議 Low / Mid Fidelity Testing：推薦快速且低成本的測試方法，這些方法可以在不需要投入大量時間的情況下提供寶貴的見解。這種方式可以快速收集反饋，同時保持項目進度。
使用 Concept Testing 而並不是 Usability Testing：建議與潛在用戶進行概念測試，以在開發前驗證想法。意意就是不用每個頁面和細節都設計出來，並在測試時用口述讓使用者明白慨念，然後看其觀念是否有用 。（不是完整的易用性測試）
iii. 制定測試時間表
制定清晰的計劃：呈現一個包含測試、分析和實施階段的結構化時間表。通過向利害關係人展示測試可以融入整體項目時間表中，可以減輕他們對延誤的擔憂。
設置里程碑：將測試過程分解為可管理的里程碑，並設定具體的截止日期。這樣一來，利害關係人可以看到項目進展，而不會覺得項目無限延長。
4. 收集更多想法，變成以用戶為中心的假設列表
當你成功創造了足夠時間後，別忘了要用合適方法收集相關人士的想法。
在之前的案例中，單靠會議或 1:1 對話並不足以收集所有的想法。大家可能還有其他想法，這時候可以做一件事：
建立線上或線下工作坊，收集想法並轉化做『假設』
這裡有一個以用戶為中心的『假設』模板，是經過我多年來改進和一直使用的框架。
我使用這模板去收集大家的想法，並轉化做以用戶為中心的『假設』。
它包括：
用戶是誰 (Users)
用戶目標 (Goals)
用戶遇到的問題 (Problems)
他們今天如何解決相關的JTBD (What they do today)
想法 (By…[Your Ideas])
你期望在該想法下，用戶會產生出來的新行為 (Users will be able to…)
我們會知道到底這是對的，當⋯⋯[指標] (We will know it’s true while…)[Successful Metrics]
這個模板有別於其他的，它能夠：
讓你和團隊反覆思考，為何新的方案比用戶現在的行為要好？
通過上面的反覆思考，讓『假設』變得更可靠
創造了讓利害關係人從用戶角度思考的過程
保留利害關係人關心的業務指標，和他們最愛的想法
如何使用模板？
方法1: Ideation 工作坊
你可以選擇進行 1 個小時的 Ideation 工作坊，向團隊解釋為何要做這工作坊，借機會向團隊解釋一下你收集了的用戶問題。
用戶問題可以是觀察所得的，可以是假設的，可以是從之前的研究得來的。
方法2: 線下收集想法
之前我試過，實在沒有時間去舉辦工作坊，唯有發文件到團隊訊息群裡去，或再在 1:1 的會議裡替他們寫下他們的想法。
5. 進行慨念測試和迭代
進行概念測試和迭代可以幫助利害關係人更好地理解他們的想法其實是「假設」。
這意味著這些想法有時可能是正確的，但也有可能是錯誤的。
通過概念測試，我們可以快速驗證這些假設是否符合實際的用戶需求和行為，從而避免在開發過程中浪費資源。
如果測試結果顯示用戶反應不如預期，我們可以在測試其間嘗試迭代和調整這些想法。
這樣的過程不僅能幫助利害關係人看到真實的用戶問題，還能讓他們意識到，在產品設計中，想法在讓用戶測試前，一切都只是假設，必須透過測試和迭代才能找到真正的最佳解決方案。
當然，如果『假設』涉及是比較分散和細小的項目，還可以考慮用 AB TESTING 去驗證想法。
今天就分享到這裡。
謝謝你耐心閱讀！
下星期日見，
Kogi