文/Ivan Wei 最近在產品推進上發…
Browsing: 組織溝通
91APP 透過數位力量提供 UX 服務，同時突破購物體驗、銷售服務、零售管理三大斷點。「我們花非常大的力氣與時間投入到門市端做使用者研究。」李昆謀表示，「店員通常很抗拒數位工具，第一關就卡住。」嫌操作麻煩是表面原因，往下探究，「業績歸屬」時常牽動 OMO 能不能真落地。
能讓做大型工具機的業主接受這麼活潑的提案，她不諱言客戶內部起初也有很多聲音，但她的態度並非賣設計，而是站在合夥人立場，痛點、願景並陳，最後達成共識。關於溝通，她說：「設計是溝通的累積。作為一個設計者，說故事要有邏輯。沒有邏輯就會歪來歪去，說服力會比較弱。」
了解需求是一回事，落到執行又是另一回事。宏碁 ADS 資深經理翁汝嫻舉例，Predator 21 X 為了貼近玩家期待，從技術規格到外殼顏色，內部經過無數次溝通，辛苦不足為外人道。她認為，一條產品線要能成，設計能力是其中之一而非唯一，結合多方資源，有利讓自己的產品走出去。
他接手後比對數據發現網路流量、點擊數與來電數三者比例有點怪，往下挖掘發現 B 顧問有用機器人灌水的可能，此時固然保持推論，但不需花心力細究到底有沒有灌水、怎麼灌的，而是回到 A 客戶的終極目標：提升點擊數與來電數以增加業績。最後，透過視覺設計與 UX writing 排列組合的 A/B testing，扎扎實實幫客戶達成目的。
身為一個產品經理必須要打從心裡熱愛自己的產品，台上的講者們講起自己的產品或執行過的專案，總是充滿熱情，產品經理的初衷是想要把產品做好，因此會衍生出許多獲得答案的渴望與需求。
近期國外的趨勢，除了A/B Testing之外，更在乎的是進行一個完整的UX策略思考。它們會把使用者使用這個服務的完整過程都納入考量。A/B Testing已經整合在最佳化轉化率（Conversion Rate Optimization）之中，要能從巨觀上結合商業思維，接著從細節中找到使用者真正在乎的痛點，如此，才能進一步地提升服務的品質。
唯有參與，掌握更多資訊，你才有可能扭轉局勢，拒絕參與，你就只能被他人要求做事。
原則上勇於接受挑戰或各種要求是個很不錯的態度，但當 PM 必須要有勇於說 NO 的勇氣，對不合理的時程，不合理的需求，讓人不舒服的溝通方式，你必須要有不一樣的態度，不能只懂得說 YES。
在改版專案進行前後，也需檢視既有數據資料、並視需要安排各種使用者研究。而在進行大改版之前，如果時間充裕狀況下，有時我會建議幾個重要頁面或使用流程先做幾輪小優化、將數據調至滿意後，再以此為基礎進行大改版。
但對於新手 PM 而言，使用者是個相對模糊的詞，而且在思維 mindset 上要有非常大的轉變。因此我在訓練新手產品經理時，會建議他們從最簡單的 IA 架構著手：去拆解市面上知名的網站 APP，從中學習架構邏輯、UX 與流程設計，以及功能比較等。
在台灣管理專案，通常人來了就開始埋頭下去進行、或者花一大堆時間製作文件往來，（例如花很多時間撰寫完美的會議紀錄）。前者往往沒有預先釐清所有人的權責、思考最有效率的溝通運作方法，可能導致專案運作混亂。後者花費太多時間在文件製作上，浪費人力成本。
就我這些年碰專案的經驗，我看過 9 成 9 緊急的專案大多是有討論的空間，務必要先跟老闆溝通他的目標，而不要盲目的啟動專案，以免到頭來老闆要的東西交不出來，把專案成員搞得疲憊不堪，你自己的 credit 也掉光光，還被說是個不稱職的 PM，豈不冤枉。
敏捷開發的組織精神，主要是營造一個扁平去中心化的自組織，每一個人都應該對組織主動貢獻心力，這也包含了對於產品功能的決斷上。本著用戶體驗的精神，任何關於解法的討論，都必須回到真實的生活情境，如果直接進行功能面的討論，很有可能會產生一個現象：任何的意見都是個人經驗的投射，而非來自使用者需求。在沒有用戶研究的情況下，至少，我們要能夠知道一個真實用戶的使用情境，即使是周遭親友也可以，每個開發成員都應該這麼做，提出真實的情境會形成有效的功能討論，所以每個團隊成員都應該在日常生活中，對周遭人事物保持關心，就有機會觀察到自己產品服務的使用情境。
以前聽到要改稿，心底總是千百個不甘願，不能理解怎麼這麼好的設計對方就是吞不下去。現在的我經過歲月這把殺豬刀的磨練後，聽到要改稿，已不再像聽到要去看牙醫一樣充滿負面情緒。以下為大家整理五個常見的改稿原因與建議，這些都是我在工作時親身實踐的原則（註：這篇文章把提出需求者暫時通稱為客戶）。
我們發現有許多人都在問：「同事／主管／老闆不重視使用者體驗，我要怎麼說服他們？」
文/ Goodpatch Taipei …
文/ 女人迷網站 設計師 Merci 設…
在 Booking.com 的前兩個月，我感受到很不一樣的「問問題」文化，在這樣的氛圍，要隨時準備好「問問題」與「被問」。我理解到主動「聊天」建立關係的重要，與聊天前做功課的必要。關於「個人成長發展」，我再次思考自己的成長藍圖，透過「選擇產品」讓自己成長，同時，也積極在工作中「發揮影響力」。
這一次痞客邦 UX 成員們滿懷期待，特地選好黃道吉日要來開箱一款來頭不小的桌遊「UX in the JUNGLE」，是由大名鼎鼎的趨勢科技（Trend Micro） 所成立的趨勢教育基金會所發行的桌上遊戲。
設計師應該告訴其他團隊成員用戶的需求是什麼。設計師或許無法決定這個需求要如何平衡受益和成本，以及要分幾個階段實現，因為這更多是一些商業和成本決策，但是交互設計師必須要代表最終用戶發出聲音，這是交互設計師的基本職責。
所有的產業都會用到用戶體驗，進一步來說是用戶體驗在產品上能夠展現得多強，目前看起來比較有前景的是金融業，我覺得金融業還是比較有財力，並且他們可以改善的部分還是蠻多的。另外理論上還有資通訊產業，為什麼是理論上，因為資通訊產業不一定全部都重視用戶體驗，公司有用戶體驗的人跟重視用戶體驗還是兩件事，但我覺得現在資通訊產業競爭太強了，有好的用戶體驗但價差並不會太大。再者比如 AR、VR 目前沒有人知道該怎麼做，但如果這一塊做起來的話，應該是蠻有價值的。最後是軟體相關行業，像我們所看到的火車購票系統、報稅系統都很糟，其實可以做得更好，這些都是很好的機會。但相對來講，錢從哪裡來是個問題，就看相關單位會不會肯花這筆錢，我也希望政府能投資源在這一塊上，讓我們政府有更好的用戶體驗進而推動產業發展。
從研究設計，招募使用者，要招募誰，招募問卷怎麼設計研究大綱怎麼訂，實際訪談怎麼問問題，怎麼樣可以更深入地挖掘洞察，這些都是相關的 hard skills（實力），但是如果沒有溝通技巧，做得再多還是沒辦法創造影響力。
設計各領域重疊性非常高，沒有絕對楚河漢界劃分黑白，要做的事就那些，看是由誰去做而已。不要管職缺上開的條件寫什麼，稍微有點興趣就投履歷。對方的「熟悉」和你的「熟悉」是同個標準嗎？對方的「擅長」和你的「擅長」標準一樣？等到紙本過關通知面試，再來想要不要去，甚至被錄取了再來煩惱都不遲。
在決定要開發什麼新項目後，產品經理會完成產品規格；設計師根據此文件進行設計；工程部門動工前，會看產品規格來了解此項目的主旨。理想狀況下產品規格是固定不變的，但實際上隨時會因為內外部需求、資源限制、團隊變動而必須即時更新。
文 / Peter Su 這是一篇關於土…
Victor Papanek 曾說：「設計師的首要職能就是解決問題。」解決問題不是只限於產品或專案上，還包含工作流程。當對方質疑你的設計時，請反問他：「請問我做的哪些部份你覺得偏離專案目標？」同樣，當你覺得對方的提案很瞎時，想看看對方基於什麼原因提出很瞎的作法？是不是對方手上握有自己不知道的情報、在諸多條件限制、資源不足情況下只好選擇這種對策？
阿飛建議，從信任開始，不要只想著「我們在做的東西大家都不懂」或是急著要別人接受。要真正關心周遭的事物，試著反問自己「能不能從人的面向讓大家了解？ 」。再來，才開始做跟使用者有關的工作，UX team 的工作內容常常與其他部門重疊，所以 UX team 要作為部門與部門間的橋樑。所以他開始帶公司打破「有事情就進會議室的印象」，不是只有在自己部門內，而是和公司內部交流，也引導其他部門知道要到使用者場域去看。
Google一下，你可以發現各大科技公司皆有使用者經驗書寫者（UX writer）的招聘，綜合 Google 和 Spotify 對書寫者的期望，我們大概可以描繪出使用經驗書寫者所該具有的能力及責任：「使用經驗書寫者，在公司組織內部與使用者經驗相關人員合作，運用研究所得之資料，建立符合使用者在產品服務上的內容，並且樹立品牌與使用者溝通的語言、形象。」
將文字紀錄轉化成 task 的工作，成員可以透過團隊溝通出一個標準，分頭在線上完成；但要從 task 中找出規律，拼湊成有意義的模式，就是件相當人工的事了，像是：利用表格、按照訪綱分類排序 task、分類。
狩野分析主要是從顧客身上，找到品質是否到位以及滿意度高低的關聯，作為是否優化或是決定優化順序參考，倒不是作為服務項目保留與否的判定。
開會還在吵要不要做哪個功能嗎？工時這麼短、要做的事那麼多，卻不能決定哪個先哪個後嗎？狩野分析能用量化的方式幫你快速決定要或不要。只求真正有決策權的人在跑完狩野分析看到報告文件後能多考慮一下，產品不是功能越多越好用啊！
相不相信設計思考，相不相信 Fail early, success sooner（越早失敗、越快成功）非常重要，但在現實企業裡卻不見得有時間給你嘗試失敗。所以在一開始的摸索期，專案產出的點子可能在前期驗證的時候就失敗，大家的信心也會漸漸下降而致放棄。要克服這一點，最重要的是記牢一件事情：用最少的成本、最快的速度去失敗，儘管失敗了也千萬別放棄。
做 Prototype 的目的通常是測試和驗證，不管是給使用者操作看看、觀察使用者操作狀況做使用者測試，還是工程師套完程式上線前先測看看有沒有蟲或哪邊爆炸了。所以 Prototype 一定要可以被操作，不能被操作的都不是 Prototype。
由於沒有面子問題，大家可以坦白地把想法攤出來，「溝通是一件最困難的事，這是很多公司不論從 0 到 1 或從 1 到 N 的關鍵」，他看得很明白、體會得很深刻，表示「進步，來自於誠實的溝通。」包含他們四人和父母之間，都經歷過一段需要用力溝通的日子，幸好彼此開誠布公，家人逐漸理解以後，從起初反對逐漸轉為助力，比方現在新辦公室的地點，就是 Arnold 家裡幫忙找的。
UX 是創業本來就一定要注重的環節，現在網路創業門檻越來越低，idea 不值錢，最後做得好的，勝出的，第一個是品牌力，第二個就是你的使用者體驗。Hahow 好學校共同創辦人暨執行長江前緯（Arnold）指出，「互動」是 Hahow 非常在意的價值。「滿足學生體驗，我們就做出市場差異性。」「從募資到跟老師互動，都是體驗的一部分。」
「換位思考有一定的步驟，你要蒐集很多資料，才有辦法換位思考。你要可以知道、預測那個人的一舉一動，才是成功的換位思考。」人稱 David 龔的坎城廣告金獎導演龔友誠老師開玩笑說，詐騙集團會成功，就是因為懂得運用這些技巧。
在開始之前就應該要對於「插圖如何在介面裡運作」有想法，例如：你要怎麼使用插圖來引導使用者，或是你只是純粹想要在專案裡注入一些自我個性。
Open HCI 2017 第八屆人機互動工作坊今年於臺灣大學舉行，工作坊由臺大、臺科大、政大等校學生自治籌辦，旨在推廣人機互動學門與跨領域合作。來自不同領域的學員在經歷為期六天的講座與課後實作之後，在 7 月 2 日舉辦互動成果展覽，吸引滿場觀眾前來。
一位已做到首席的研究員則跟我說：「作為用戶研究員最重要的，便是將你在研究中獲得的 “Ah-ha moment” （指一瞬間的突然醒悟），融合你的信念，以說故事及譬喻的方式，來改變其他人的看法、讓他們對你提出的想法感到興奮」。
Conversion Lab 其中兩位創辦人：在中國唐碩體驗創新諮詢擔任資深體驗研究員的 Nelson，以及在美國微軟擔任用戶研究員的 Elsa ，帶讀者一窺企業端（甲方）與顧問端（乙方）體驗創新及用戶研究實際的工作狀況。
跨領域合作要的應該是在想法上的激發與延展，沒有花時間分享、討論、改變，那就只是分工，但是沒有合作，缺乏本質上的變化，也比較難產出創新的結果。我們成果豐碩的跨領域合作案，幾乎都是資工領導者具備設計的思維，願意花時間跟我們討論，願意承受因為設計而帶來的工作量增加，甚至帶著成員一起進入設計的歷程。
Balto 帶出了「Design Feedback Communication」這個概念，讓大家的回饋不再是單一針對抓蟲和錯誤指正，而是可以有更多彈性，包括稱讚或是針對設計和體驗上的回饋也可以在這個平台上討論。走到這個階段，產品大致的概念已經有譜了，但常常遇到的問題是提案遲遲無法得到上層的同感，但其實只要早期將決策者拉進溝通的圈子裡，就能更順利地前進。
2017 年主題為「轉型．向上 （Transformation）」，意為未來的創新設計將融合跨界專業，因此兩天議程，與台灣使用者經驗設計協會、台灣互動設計協會、智榮基金會龍吟研論、DITL、方略管理顧問、台北市電腦公會等友團聯手邀集 18 位來自台、美、德、中跨領域專家前來分享，總移動里程近四分之三個地球。
有決策就會產生結果。絕大多數的職場生態習慣用短時間內的產出論斷一個決策的對與錯，雖然合理但卻不甚公平，因此我們必須學習不斷的拿捏風險與利益之間的最佳平衡點，這需要時間的磨練，但如果你非常清楚為什麼你要做這件事，你要拿的產品價值是什麼，那麼你就相對不容易因為短暫的利損或是負面的批評而左右搖擺你的信念，甚至棄守戰場。
引導師的工作，不是告訴學員，哪個方向是對的，而是要讓學員知道，還有很多不同的方向。例如，學員發現顧客喜歡親切的互動，所以學員開始思考怎樣的點餐方式可以展現親切，但是卻卡住了，你可以試著跟學員說：「點餐一定是顧客點嗎?」，讓學員開始思考店家如何幫顧客決定餐點，看看學員能不能舉出例子。
在共創式思考時，我們不站在自己立場，亦不站在對方立場，而是讓對方跟我們站在同一立場，共同面對眼前的問題，而這樣的方式，往往會透過工作坊的形式，讓我方、對方、第三方，共同組成的小組，一起面對同樣的問題，思考共同解法。所以工作坊的設計與引導就極為重要，創意發想並不是主要的成果，而是融合三方想法，以及營造共識，這才是重點。
在目前的成功案例之中，我們很容易發現其實這些案例內，也有許多用戶體驗糟糕到不行，但團隊卻是順利的一輪一輪融下去。這些團隊都有共通點，他們的產品有觸及到用戶的需求，不管是不是透過補貼來的（補貼也是一種需求，像是叫車、叫外賣服務一直送紅包補貼用戶，讓用戶因為省錢，寧可多裝一個軟體）。當需求強烈到一個層度，用戶還是會願意跨過斷點去完成任務（例如：自然人憑證報稅、網路銀行），所以如果初創碰的題目是一個非常強烈的需求，用戶體驗在初期可以不是最優先的議題。
1.行程密而多，純管理者以短時間規劃行程。2.維持專注力，純創作者需要完整不間斷的時間規劃。3.集中零碎時間，身兼管理與創作者需要彈性規劃。
在非常早期的階段，隨性的對話中，最好專注在「這有可能落實嗎？」這類問題。如果答案是正面的，把錢分配為一個一個小項目，堆疊起來的具體規劃好多了，而不是草率了解一個沒有任何根據、虛構的龐大數字。這個過程我們稱為專案探索階段（project discovery session），有時候稱為「需求蒐集（requirement gathering）」或「產品藍圖規劃（roadmapping）」。