哈囉，朋友
我在成為數位領域的產品設計者之後，最大的發現就是自己經常處於無知與茫然的狀態。
我們要理解手上開發產品的商業邏輯，這樣才能提出符合策略的產品設計提案。
我們要洞察產品服務的使用者情境，搞懂現場的用途以及願意產生行為的動機。
我們還要設計產品服務流程，在商業目的、使用者需求與技術可行性之間取得平衡。
最後我們還要持續的評估是否還有改善的可能性。
產品真的有滿足使用者需求嗎？
產品有滿足商業目標上的期待嗎？
這些林林總總的議題，就沒有一個是簡單的，也別期待標準答案。
那麼，我們該如何在這一片混沌之中找到立足點，建立自己認知的地圖呢？
我想分享以下幾個方向，提供你作為參考：
理解利害關係人的商業目標與需求
洞察使用者情境與動機
設計產品服務流程
評估持續改善的可能性
我們曾經在訪談一位 UX 主管時，聽到一段很有意思的感嘆，他說：「我們遇到的設計師大多數在學習期間，都有被訓練，或者很有意識的知道要關心使用者，去同理用戶的需求。然而，大多數的設計師卻很難去意識到，要去同理利害關係人的需求。」
「利害關係人也是人，他們也是產品要服務的一環，沒有這些人的參與以及理解，產品是不可能成功的。」
這就像一個軟體平台經常會分為前後台，人們經常只注意到光鮮亮麗的前台，但很少有人在意後台的設計規劃。
理解利害關係人的需求，更多的是軟技能以及領域知識的展現。
這邊羅列幾篇先前文章作為參考：
需求訪談的三個階段性（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-75）
如何對大忙人進行需求訪談？（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-99-8）
關於用戶增長的五個 UX 策略觀點（https://lms.soking.cc/posts/servicedesign029）
在需求訪談中辨認多方利害關係人的類型（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-83）
洞察使用者情境這件事情就像是廚師要懂得如何辨認好食材。
當然，我知道如果是在速食店廚房打工的人，根本不需要搞懂薯條跟漢堡肉的來源。
但如果我們以黑白大廚那樣子可以獨當一面的大廚為目標，主動去探尋與辨識各種食材，就是大廚之路的基本功了。
身為產品設計者，我們是為了讓自己的設計有所本，為了解決真實存在的問題而去進行研究。
如果我們還相信設計的本質是解決問題，那麼了解問題的長相，就是第一步。
參考文章：
一個產品人的極限，同理心是我們專業的瓶頸（https://subscribe.soking.cc/posts/soking-95）
訪談技術中的語言模式（https://lms.soking.cc/posts/interviewskills005）
如何認識目標受眾？我推薦從專家與小白開始（https://lms.soking.cc/posts/servicedesign030）
低成本的消費者市場研究方式 –「游擊訪談」（https://lms.soking.cc/posts/interviewskills007）
設計產品的服務流程是傳統意義上我們對於設計師工作的理解。
這包含了以設計思考為骨幹，透過發散與收斂的過程，有意識的去洞察情境、識別問題、規劃原型、測試與評估。
我很喜歡致遠體驗設計的卓致遠設計師（江湖人稱卓學長，廣為人知的案例是台灣報稅系統改善的推手），將設計思考轉化為東方風味的：見、識、謀、斷。
設計思考常常被忽略的一個核心精神，就是將利害關係人的共識納入設計流程。
在《我們的行為是怎樣被設計》一書中提到，發明設計思考的 IDEO 公司，當年所強調的是「設計不再仰賴天才的直覺」。
IDEO 共同創辦人蘇瑞說：「老一輩藝術學院出身的設計師不太喜歡與人交流，藝術學院總是挑選靦腆、有創意的人當學生，討厭去觀察真實生活裡的人，也不喜歡賣力摸索日常生活的小細節。」
在將利害關係人納入設計流程這件事情上，數位領域的產品設計師，最艱鉅的挑戰之一就是與程式設計師的合作了。
要怎麼樣讓不會寫程式的人，設計出要用程式來實現的產品服務呢？
關鍵在於資訊架構的規劃。
軟體任務的本質是滿足資訊需求，而不是介面的美觀。
根據產品服務的情境，定義出可結構化的資訊，並且設計出讓使用者與這些資訊內容互動的流程。
千萬別搞錯了，使用者並不是想要跟音樂播放器的介面互動，使用者想要的是點播喜歡的歌單，用來點綴他的生活。
參考文章：
軟體任務的本質是滿足資訊需求（https://subscribe.soking.cc/posts/soking-85）
撰寫產品需求文件 PRD 時的閱讀體驗七宗罪（https://subscribe.soking.cc/posts/soking-prd-2）
8個產品設計文件 PRD 的 SPEC 書寫原則小技巧（https://subscribe.soking.cc/posts/soking-8-prd-spec）
如何畫出爛爛沒人看的 UserFlow？（https://lms.soking.cc/posts/servicedesign036）
我曾經在一場新創團隊的內部工作坊當中，與開發團隊的PM、設計師、RD 們討論，怎麼樣算是「需求的終點」呢？
大家很有共識的得出結論：當我們解決使用者問題時。
不是需求被變成設計稿、不是需求被開發、不是新功能推上線。
而是當初我們定義了一個問題，這個問題在新版本更新之後，有沒有真的被解決了？
你會發現，如果一開始定義需求時，只談論了很表面的「功能性需求」。
例如我要一個投票功能。
那我們根本不知道這個投票功能推上線之後，到底有沒有發揮效益。
所以我們需要「清晰的目的」、「可驗證的方法」以及「持續改善的行動」。
參考文章：
不確定性的三種成因（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-76）
定義一個好問題，問題就解決了一半（https://lms.soking.cc/posts/servicedesign042）
怎麼樣算是產品服務的使用者體驗不佳呢？六大常見原因（https://lms.soking.cc/posts/servicedesign021）
系統化洞察顧客服務體驗的三個檢查清單（https://lms.soking.cc/posts/servicedesign022）
成為數位產品領域的產品設計師，是一個多元且複雜的職業道路。
網路與軟體的行業不像餐飲、醫療、金融、製造等等行業，動輒百年甚至千年以上的歷史。
有句話是這樣說的：「軟體正在吃掉全世界。」
長期而言，軟體不是一個行業，而是成為各行各業的一部分。
分工曖昧不明、各個行業招募標準不一、管理不成熟、能力要求又深且廣，這些都是我們面對的日常。
所以我們會看見，每一個在產業中獨當一面的人，都有各自的機運，很難說怎麼樣的成長路徑就是標準答案。
為了好好與你分享這個議題，我預計舉辦一場直播講座。
by Soking
