哈囉，朋友

我最近在幫一些參與產品設計比賽的朋友 review 設計構想，整個過程中發現，許多朋友不擅長表達自己的設計交付成果，而這是非常可惜的事情。

通常大家會踩到的陷阱，就是認為我已經把設計稿展示出來了，你應該一看就懂，好像沒什麼好說的？

有沒有發現，這跟平常工作上，需求方期待我們自己可以通靈，捕捉到他腦袋裡面飄忽不定的想法，有異曲同工之妙呢？

千萬不要在展示設計交付的時候，放任其他人漫無目的的 review 你的作業成果！因為你需要的是有意義的回饋，而不是隨機蔓延的無效率意見！

有三種你可以嘗試看看的溝通方式，用來展示你的設計交付：

1. 展示 before / after

2. 描述問題解決歷程的資訊需求

3. 講解行為設計的使用者認知

​

▋展示 before / after ▋

展示 before / after 最大的好處是前後對照，讓參與設計 review 的人可以很直觀的看著你想解決的問題，並且感受你的解決方案是否有清楚的處理問題。

​

此時我們需要的回饋重點，就是評估新的解決方案是否具備可行性？有沒有衍生出預期外的問題？

​

如果你展示給認知程度比你低的人看，通常不是為了請他評估可行性，而是為了給對方安全感。

​

如果你展示給認知程度比你深的人看，是希望借用他聰明的腦袋，幫你再次評估新的解決方案有沒有潛在風險是你沒有想到的？

​

▋描述問題解決歷程的資訊需求 ▋

描述問題解決歷程的資訊需求，最常發生於大型 B2B 或專業領域的企業內應用中，因為此時軟體的設計目的，通常是協助專業工作者完成某個任務流程。

​

此時的說明重點在於流程如何設計，並且清晰的定義每一個任務步驟。

​

通常我們在這類設計 review 中會遇到的麻煩，是各種數不清的業務邏輯細節，一個流程可能跨越好幾個不同職能的利害關係人，而這些人對於流程的想像通常侷限於自己的角色職責。

​

因此，切分任務步驟，就是為了讓多如牛毛的業務邏輯細節，可以找到自己的歸屬，你必須先有分類的依據，才能處理看似雜亂無章的工作細則。

​

同樣的道理，可能除了你以外，許多利害關係人對於整條流程會發生哪些事情並沒有清晰的概念，甚至沒有興趣理解範圍之外的議題。

​

帶著對方先快速的認識整體，然後根據對方的注意力的重點，餵食他希望聽懂的局部，讓他看見他的在乎。

​

▋講解行為設計的使用者認知 ▋

在探索未知的過程中，我們通常沒辦法在設計 review 時就證明想法保證可行，是好是壞，總是需要上線之後實際驗證使用者行為，才能對答案。

​

即使是在處理未知程度高的設計議題，我們依然要針對使用者行為做出清楚的構想，這是為了作為定錨，當你有了錨點，才會知道實際行為偏離的多遠，才有辦法進行後續的改善。

​

例如今天商業上的目的是「擴大使用者族群」，但我們常常會遇到設計上的解決方案，在討論過程中為了追求具體可行，因此都聚焦在討論原本的使用者的不方便，因而提出新的設計改善方案。

​

這就是典型的太快進入細節，為了手段而忘記目的，甚至會轉身去擦掉原本的設計目的，為了手段而改寫目的。

​

稍微好一點的狀況，是提出「讓使用者可以分享」，用來擴大使用者族群，但實際情況只是放了一個分享的 icon，就期望使用者的分享行為會自己發生。

​

設計師在這個時候，有必要提出的設計論述，包括以下三個層次遞進的轉換漏斗：

1. 什麼原因會讓使用者產生分享的動機？

2. 什麼樣的分享會觸及本來不會使用我們產品的族群？

3. 如何讓新的族群更容易接受我們的產品？

上述三個問題通常沒有標準答案，必須具備充分的使用者洞察，取材自目標族群的實際工作與生活中所發生的情境問題。

​

比起在介面中放了分享的功能（解決方案），為什麼使用者可能會去點擊分享功能（行為動機）才是更重要的事情。

​

▋結論

透過這篇文章，與你分享三種我經常在設計 review 的時候使用的溝通策略，整理重點如下：

1. 展示 before / after，讓別人明確理解對照關係，產生安全感，給予可行性的回饋。
2. 描述問題解決歷程的資訊需求，幫助對方理解整體流程，並看見他想看見的議題。
3. 講解行為設計的使用者認知是為了探索未知，比起解決方案，更重要的是使用者動機的洞察。

希望這些分享，可以給你一些幫助，讓你在展示設計交付時更有說服力。

謝謝

by Soking