為什麼大多數UX 只能是思考局部問題的專家，或許體驗還有更多可能？
一、前言
二、體驗邏輯、產品敏感度
三、重點總結：重擬思考使自己的體驗更有價值
四、務實的落地能力：定位自己嘗試更多可能適合讀者
1.想要增加產品力的朋友
2.想了解體驗可能性的朋友
3.正在職涯糾結的朋友前言
有幸面試了一些求職者獲得感想與收穫與各位小小分享。
Portfolio這塊很多人談過怎麼做一份好的Portfolio與怎麼闡述自己在這產品中定位與產出價值，卻很少人在討論體驗職位怎麼判別insight及取捨，最後落實並創造最好效益的可能，讓UX很多時候淪為一個保險或sop，如果以體驗驅動增長這目標似乎還有很多可以討論空間與可能性….
忽略了這三件事，可能會讓體驗少了些可能
- 體驗細緻度 - 從宏觀到微觀
- 產品服務與公司願景 - 體驗指北針
- 務實的落地能力
以下詳細解釋這3點：
1. 體驗細緻度 - 從宏觀到微觀
這是一個邏輯思考，也是設計背景升上來的UX最難克服的痛，以環境來談很少文章在討論與著墨….
(一)設計思考如何具象化落實在產品設計上面
(二)資訊架構與流程關係怎麼連結到服務需求上面並回推證明設計體驗上是有滿足的，不是喊口號發散Idea用戶為中心這空話、而是真正以體驗與增長為核心
分享一下最近例子：某個應徵者做了個類似Google Map的side-product，有個頁面是店家資訊有營業時間欄位，介面顯示AM:08:00~17:00，問他為何這樣做？AM與PM界線怎麼定義是後台使用者自己選擇？在介面上有思考怎麼處理麼？應徵者回說後台先設定AM與PM再去設定時間，感覺可能沒有謹慎思考這問題而硬是回答….因為像是臺灣很多店家賣到下午2點才閉店休息到晚上5點後開始營業，那這種情況對於大眾認定AM與PM界線的主觀定義就明顯不符，用戶無法獲取正確資訊指引，還是說…產品在定義服務上是要放棄這類店家與用戶？或者體驗上需要優化思考除了AM與PM以外處理方式？
想了想或許還有些其他特質是沒發掘部分，打開Google Map選了個店家，綠字部分問他說既然你做Google的redesign有觀察過店家會有幾種狀態嗎？認為一間店會有幾種情境狀況呢？回答是….
1.營業中
2.公休中
3.歇業
4.休息
問他說只有這樣的可能麼？再挖深一點談…如果給你機會優化此使用體驗該怎麼給予使用者決策性訊息與狀態上是以什麼方式去判定更換狀態？…此時他的口氣越來越小聲了…說會在後台加欄位去讓用戶設定細節….
後話…筆者覺得用戶體驗上面不是只有流程與易用性還存在者很多邏輯與對應體驗定義深度的細節，Google Map絕對不只有這樣，還有24H不打烊的處理方式，與營業即將結束的通知狀態，體驗絕不是碰到問題就開新規格處理需求，而是在於邏輯與思考細緻度，有沒有想過每天搖旗吶喊要做用戶訪談、要做以用戶為中心設計，那在這些基礎架構與細節當中…
是否真有落實做好基本功，增加體驗的邏輯與深度呢？還是只是用戶的應聲蟲？或者造成邏輯矛盾增加團隊困擾？
從這些架構與細節當中越磨越有經驗，那你就會越來越有自信
2. 產品服務與公司願景 - 體驗指北針
很多時候體驗職被賦予任務是改善這頁面或功能的Layout或者易用性等很局限目標，這些問題坦白說都很Focus，有很多解法與旁門左道，很好學習也容易被後浪所超越。
更不能讓體驗職從問題導向變成同理人導向，達成重擬過程、進而去思考自己的優化小小涓流是否符合貼切公司願景與產品戰略目標？還是只是發散、天女散花？就能知道該從什麼觀點出發與問題重要度排序，讓體驗變成產品導向，知道企業Ｍaster深刻理解與感知、知道怎麼下放同理心，知道怎麼做出體驗層次與競品差別，不是一味抄襲功能而沒有想法。
在設計思考有個很重要概念「重擬」是設計師最重要思維，告訴我們不要從問題開始，從人開始、從同理心開始，去深度思考公司願景與產品服務目標是什麼？
舉例來說：回到應徵者那問題，今天做地圖產品是為了改善什麼生活體驗？
1.讓用戶有需求時更容易查找到心儀店家：找得到下決策
2.提供交通導航決策資訊 ：解決交通問題
3.認識城市：增加區域認知度
這3件事情可以變成3個產品也可以是1個產品，但所有產品中一定有MVP功能，解決最重要的價值核心，覺得是哪件事呢？
Google 的使命在於匯整全球資訊，供大眾使用，使人人受惠，如果這是願景，那2005年推出的Google地圖，猜測會側重的會是這三者的哪一個呢？先2、3、1，還是1、2、3？
產品敏感度會決定要把第一顆體驗種子種在哪裡？從哪深耕？從而茁壯！
3. 務實的落地能力
在產品開發中很重邏輯與思考深度就像圍棋一樣，我們不能預測對弈的結果，但我們可以使每一步都是下一步的薪火。
產品設計中不僅有探索更多的是收斂。在這裡引用用戶體驗要素作者Jesse James Garrett定義的體驗架構模型，各自對應不同職務…
5.Visual Design、Interface Design 對應UI職
4.Navigation Design、Information Design、Interaction Design 對應體驗職(但滿多PM身兼這塊的)
3.Information Architecture 對應體驗職(但滿多PM身兼這塊的)
2.Functional Specifications、Content Requirements 對應一般PM職(其實這才是PM主要工作，理解第一層並給予明確Task使團隊高效輸出)
1.User Needs、 Site Objectives 對應老闆或客戶還有戰略型產品經理(真正的產品經理是要能定義北極星指標並能夠驅動團隊實現公司目標)
從這模型可以看出體驗職位還有很多可以落實滲透的方向與空間
如果套用到產品開發情境裡面會有這五種對象並對應五種層級：
1.商業邏輯&目標KPI
對象：戰略PM、老闆、客戶
想什麼：思考是怎麼階段達成目的與年度目標2.功能需求、對象、狀況
對象：一般PM
想什麼：這目標衍生什麼商業流程需要梳理，各自對應什麼對象與Spec3.操作流程
對象：可能是PM或UX
想什麼：體驗與銜結怎麼在產品內具象化符合落實需求4.資料流程
對象：軟體工程師
想什麼：這些畫面資料怎麼跑，API怎麼開、功能的各種狀態與情境5.資料庫系統架構
對象：資料工程師、資料架構師
想什麼：DB怎麼存取，需不需要額外暫存等等
用戶模型有五層架構在產品開發當中也有五層架構，那目前你的體驗有往上下層次滲透擴展了麼？
從以下這張圖就可以發現，UI/UX是產品開發當中很重要銜接點，如果都是以畫面思考流程會很難與其他層級關係人溝通清楚，容易Miss掉很多情境與邏輯，適時拋棄設計思維用他們的語言去溝通，以流程、細節定義交付體驗，會更有價值。
完善的組織更會因此規劃產出完整交互的Design Requirement Document去與PM的Product Requirement Document相輔相成，產品測試上也可以有很好的方向去做AC文件與討論。
最後….仿間課程都在教方法論，但如果沒有產品力以及認知架構定錨能力，方法論就會像是個機器，沒有心法是無法玩得轉、玩的好。
方法論都是把一件事中理性部分抽出來為你呈現，但若完全按照它去做，極大概率會失敗。
畢竟合理的部分是理性，不合理部分是人性
因為在教材裡學到的是理性，做事情時卻要處理的全是人性，也包括要安放好自己的人性～～不糾結、不徬徨等。
期待與大家一同成為有中心思考的產品人，明白什麼眉角是不需要做研究的，什麼時候該用Flow Chart去溝通、什麼時候PM跟你講目標時你可以下很好體驗的選擇去輔佐目標(捉大放小)，這些都會變成你的Domain knowhow，盼這些挫折與傷口、使你的經驗越擴越廣，到最後你會了解…
「所有苦難，其實都是偽裝的祝福」
希望這篇文章可以讓你不在像我以前一樣徬徨，可以在不確定人生當中，建立自己的確定性，並與人彼此依賴，重心開始(重擬自己)像這世界交付價值並獲得回報。