哈囉，朋友

我在成為數位領域的產品設計者之後，最大的發現就是自己經常處於無知與茫然的狀態。

​

我們要理解手上開發產品的商業邏輯，這樣才能提出符合策略的產品設計提案。

我們要洞察產品服務的使用者情境，搞懂現場的用途以及願意產生行為的動機。

我們還要設計產品服務流程，在商業目的、使用者需求與技術可行性之間取得平衡。

​

最後我們還要持續的評估是否還有改善的可能性。

產品真的有滿足使用者需求嗎？

產品有滿足商業目標上的期待嗎？

​

這些林林總總的議題，就沒有一個是簡單的，也別期待標準答案。

那麼，我們該如何在這一片混沌之中找到立足點，建立自己認知的地圖呢？

​

我想分享以下幾個方向，提供你作為參考：

• 理解利害關係人的商業目標與需求
• 洞察使用者情境與動機
• 設計產品服務流程
• 評估持續改善的可能性

​

▋理解利害關係人的商業目標與需求

我們曾經在訪談一位 UX 主管時，聽到一段很有意思的感嘆，他說：「我們遇到的設計師大多數在學習期間，都有被訓練，或者很有意識的知道要關心使用者，去同理用戶的需求。然而，大多數的設計師卻很難去意識到，要去同理利害關係人的需求。」

「利害關係人也是人，他們也是產品要服務的一環，沒有這些人的參與以及理解，產品是不可能成功的。」

這就像一個軟體平台經常會分為前後台，人們經常只注意到光鮮亮麗的前台，但很少有人在意後台的設計規劃。

理解利害關係人的需求，更多的是軟技能以及領域知識的展現。

這邊羅列幾篇先前文章作為參考：

• 需求訪談的三個階段性（https://subscribe.soking.cc/posts/soking-75）
• 如何對大忙人進行需求訪談？（https://subscribe.soking.cc/posts/soking-99）
• 關於用戶增長的五個 UX 策略觀點（https://subscribe.soking.cc/posts/soking-ux-33）
• 在需求訪談中辨認多方利害關係人的類型（https://subscribe.soking.cc/posts/soking-83）

​

▋洞察使用者情境與動機

洞察使用者情境這件事情就像是廚師要懂得如何辨認好食材。

當然，我知道如果是在速食店廚房打工的人，根本不需要搞懂薯條跟漢堡肉的來源。

但如果我們以黑白大廚那樣子可以獨當一面的大廚為目標，主動去探尋與辨識各種食材，就是大廚之路的基本功了。

身為產品設計者，我們是為了讓自己的設計有所本，為了解決真實存在的問題而去進行研究。

如果我們還相信設計的本質是解決問題，那麼了解問題的長相，就是第一步。

​

參考文章：

• 一個產品人的極限，同理心是我們專業的瓶頸（https://subscribe.soking.cc/posts/soking-95）
• 訪談技術中的語言模式（https://subscribe.soking.cc/posts/soking-97）
• 如何認識目標受眾？我推薦從專家與小白開始（https://subscribe.soking.cc/posts/soking-84）
• 低成本的消費者市場研究方式 –「游擊訪談」（https://subscribe.soking.cc/posts/soking-80）

​

▋設計產品服務流程

設計產品的服務流程是傳統意義上我們對於設計師工作的理解。

這包含了以設計思考為骨幹，透過發散與收斂的過程，有意識的去洞察情境、識別問題、規劃原型、測試與評估。

​

我很喜歡致遠體驗設計的卓致遠設計師（江湖人稱卓學長，廣為人知的案例是台灣報稅系統改善的推手），將設計思考轉化為東方風味的：見、識、謀、斷。

​

設計思考常常被忽略的一個核心精神，就是將利害關係人的共識納入設計流程。

在《我們的行為是怎樣被設計》一書中提到，發明設計思考的 IDEO 公司，當年所強調的是「設計不再仰賴天才的直覺」。

​

IDEO 共同創辦人蘇瑞說：「老一輩藝術學院出身的設計師不太喜歡與人交流，藝術學院總是挑選靦腆、有創意的人當學生，討厭去觀察真實生活裡的人，也不喜歡賣力摸索日常生活的小細節。」

​

在將利害關係人納入設計流程這件事情上，數位領域的產品設計師，最艱鉅的挑戰之一就是與程式設計師的合作了。

要怎麼樣讓不會寫程式的人，設計出要用程式來實現的產品服務呢？

​

關鍵在於資訊架構的規劃。

軟體任務的本質是滿足資訊需求，而不是介面的美觀。

​

根據產品服務的情境，定義出可結構化的資訊，並且設計出讓使用者與這些資訊內容互動的流程。

千萬別搞錯了，使用者並不是想要跟音樂播放器的介面互動，使用者想要的是點播喜歡的歌單，用來點綴他的生活。

​

參考文章：

• 軟體任務的本質是滿足資訊需求（https://subscribe.soking.cc/posts/soking-85）
• 撰寫產品需求文件 PRD 時的閱讀體驗七宗罪（https://subscribe.soking.cc/posts/soking-prd-2）
• 8個產品設計文件 PRD 的 SPEC 書寫原則小技巧（https://soking.cc/blog/prd-write-8principles）
• 如何畫出爛爛沒人看的 UserFlow？（https://subscribe.soking.cc/posts/soking-userflow）

​

▋評估持續改善的可能性

我曾經在一場新創團隊的內部工作坊當中，與開發團隊的PM、設計師、RD 們討論，怎麼樣算是「需求的終點」呢？

大家很有共識的得出結論：當我們解決使用者問題時。

不是需求被變成設計稿、不是需求被開發、不是新功能推上線。

而是當初我們定義了一個問題，這個問題在新版本更新之後，有沒有真的被解決了？

你會發現，如果一開始定義需求時，只談論了很表面的「功能性需求」。

例如我要一個投票功能。

那我們根本不知道這個投票功能推上線之後，到底有沒有發揮效益。

所以我們需要「清晰的目的」、「可驗證的方法」以及「持續改善的行動」。

​

參考文章：

• 不確定性的三種成因（https://subscribe.soking.cc/posts/soking-76）
• 定義一個好問題，問題就解決了一半（https://subscribe.soking.cc/posts/soking-69）
• 怎麼樣算是產品服務的使用者體驗不佳呢？六大常見原因（https://subscribe.soking.cc/posts/soking-116）
• 系統化洞察顧客服務體驗的三個檢查清單（https://subscribe.soking.cc/posts/soking-115）

​

▋結語

成為數位產品領域的產品設計師，是一個多元且複雜的職業道路。

網路與軟體的行業不像餐飲、醫療、金融、製造等等行業，動輒百年甚至千年以上的歷史。

有句話是這樣說的：「軟體正在吃掉全世界。」

長期而言，軟體不是一個行業，而是成為各行各業的一部分。

分工曖昧不明、各個行業招募標準不一、管理不成熟、能力要求又深且廣，這些都是我們面對的日常。

所以我們會看見，每一個在產業中獨當一面的人，都有各自的機運，很難說怎麼樣的成長路徑就是標準答案。

為了好好與你分享這個議題，我預計舉辦一場直播講座。

​

打造你的UX 學習地圖：從入門到專業的實踐之旅

12/27（五）晚上七點

講座大綱：

1. 什麼是 UX？為什麼它是如今數位產品的重要設計精神？
2. 業界常用的使用者研究方法有哪些？
3. 無經驗的 UX 自學者應該如何累積？
4. 從初學者到專業人士的實踐路徑
5. QA 時間：解答你的所有學習疑問

報名連結：https://www.accupass.com/event/2412051422271211928690​

講座會提供回放，當天來不及參與的朋友也可以參考。

​

by Soking