哈囉,朋友
我最近在幫一些參與產品設計比賽的朋友 review 設計構想,整個過程中發現,許多朋友不擅長表達自己的設計交付成果,而這是非常可惜的事情。
通常大家會踩到的陷阱,就是認為我已經把設計稿展示出來了,你應該一看就懂,好像沒什麼好說的?
有沒有發現,這跟平常工作上,需求方期待我們自己可以通靈,捕捉到他腦袋裡面飄忽不定的想法,有異曲同工之妙呢?
千萬不要在展示設計交付的時候,放任其他人漫無目的的 review 你的作業成果!因為你需要的是有意義的回饋,而不是隨機蔓延的無效率意見!
有三種你可以嘗試看看的溝通方式,用來展示你的設計交付:
1. 展示 before / after
2. 描述問題解決歷程的資訊需求
3. 講解行為設計的使用者認知
▋展示 before / after ▋
展示 before / after 最大的好處是前後對照,讓參與設計 review 的人可以很直觀的看著你想解決的問題,並且感受你的解決方案是否有清楚的處理問題。
此時我們需要的回饋重點,就是評估新的解決方案是否具備可行性?有沒有衍生出預期外的問題?
如果你展示給認知程度比你低的人看,通常不是為了請他評估可行性,而是為了給對方安全感。
如果你展示給認知程度比你深的人看,是希望借用他聰明的腦袋,幫你再次評估新的解決方案有沒有潛在風險是你沒有想到的?
▋描述問題解決歷程的資訊需求 ▋
描述問題解決歷程的資訊需求,最常發生於大型 B2B 或專業領域的企業內應用中,因為此時軟體的設計目的,通常是協助專業工作者完成某個任務流程。
此時的說明重點在於流程如何設計,並且清晰的定義每一個任務步驟。
通常我們在這類設計 review 中會遇到的麻煩,是各種數不清的業務邏輯細節,一個流程可能跨越好幾個不同職能的利害關係人,而這些人對於流程的想像通常侷限於自己的角色職責。
因此,切分任務步驟,就是為了讓多如牛毛的業務邏輯細節,可以找到自己的歸屬,你必須先有分類的依據,才能處理看似雜亂無章的工作細則。
同樣的道理,可能除了你以外,許多利害關係人對於整條流程會發生哪些事情並沒有清晰的概念,甚至沒有興趣理解範圍之外的議題。
帶著對方先快速的認識整體,然後根據對方的注意力的重點,餵食他希望聽懂的局部,讓他看見他的在乎。
▋講解行為設計的使用者認知 ▋
在探索未知的過程中,我們通常沒辦法在設計 review 時就證明想法保證可行,是好是壞,總是需要上線之後實際驗證使用者行為,才能對答案。
即使是在處理未知程度高的設計議題,我們依然要針對使用者行為做出清楚的構想,這是為了作為定錨,當你有了錨點,才會知道實際行為偏離的多遠,才有辦法進行後續的改善。
例如今天商業上的目的是「擴大使用者族群」,但我們常常會遇到設計上的解決方案,在討論過程中為了追求具體可行,因此都聚焦在討論原本的使用者的不方便,因而提出新的設計改善方案。
這就是典型的太快進入細節,為了手段而忘記目的,甚至會轉身去擦掉原本的設計目的,為了手段而改寫目的。
稍微好一點的狀況,是提出「讓使用者可以分享」,用來擴大使用者族群,但實際情況只是放了一個分享的 icon,就期望使用者的分享行為會自己發生。
設計師在這個時候,有必要提出的設計論述,包括以下三個層次遞進的轉換漏斗:
1. 什麼原因會讓使用者產生分享的動機?
2. 什麼樣的分享會觸及本來不會使用我們產品的族群?
3. 如何讓新的族群更容易接受我們的產品?
上述三個問題通常沒有標準答案,必須具備充分的使用者洞察,取材自目標族群的實際工作與生活中所發生的情境問題。
比起在介面中放了分享的功能(解決方案),為什麼使用者可能會去點擊分享功能(行為動機)才是更重要的事情。
▋結論
透過這篇文章,與你分享三種我經常在設計 review 的時候使用的溝通策略,整理重點如下:
- 展示 before / after,讓別人明確理解對照關係,產生安全感,給予可行性的回饋。
- 描述問題解決歷程的資訊需求,幫助對方理解整體流程,並看見他想看見的議題。
- 講解行為設計的使用者認知是為了探索未知,比起解決方案,更重要的是使用者動機的洞察。
希望這些分享,可以給你一些幫助,讓你在展示設計交付時更有說服力。
謝謝
by Soking