Daniel Lee — Product & UX Lover
Daniel Lee — Product & UX Lover

部落格 Blog Post

原創文章

工具分享 Tools Sharing

Lark Minutes: 免費的訪談、會議錄影錄音轉逐字稿工具（中英文皆支援）Lark Minutes: 免費的訪談、會議錄影錄音轉逐字稿工具（中英文皆支援）
Lark Minutes: 免費的訪談、會議錄影錄音轉逐字稿工具（中英文皆支援）
如果不用開店平台或請人寫網站，要怎麼架超簡單的電商網站？如果不用開店平台或請人寫網站，要怎麼架超簡單的電商網站？
如果不用開店平台或請人寫網站，要怎麼架超簡單的電商網站？

PM 產品經理

Medium 文章

造訪我的 Medium →

管理 Side Project 設計團隊，如何讓成員能夠有學習也有產出

這是一篇近期管理 Productlife 團隊的心得。Productlife 的前身是 C-Camp，而 C-Camp 是 UX/UI 新手村希望能夠透過共創工作坊，幫助大家累積實作上線產品的經驗，總共有研究場與設計場各 4~6 週。而 Productlife 正是在設計場之後產出的設計概念，並交由目前固定的產品團隊進行設計與開發。 目前我們的團隊組成是 PM 一位（我）、Design Lead 2 位、Dev Lead 1 位，設計師 4 位，後端 2 位，App 前端 1 位。 從 C-Camp 到 Productlife 過程中，我一開始依照之前實習和工作坊的一些經驗規劃工作流程與節奏，卻遇到一些挑戰，因此了解到一般工作的團隊與 Side Project 的團隊差異，進而慢慢調整成目前的團隊協作模式。 如果你喜歡我的文章，可以按下面的拍手！用推薦 ID【daniellee2309】 免費註冊 LikeCoin 並在 帳號設定 中驗證手機號碼，我就能因為你的鼓勵獲得一些收入 在工作坊期間，我首先依據規劃的功能，產出細節的功能規格以描述使用者故事與互動方式，也給了幾個概念式的 Wireframe，但並未針對 UI 進行設計。對於大部分處於職場新人階段的工作坊成員，這造成了雙面刃： 優點：讓成員學會分析規格，進而專注在產生對應的資訊架構與 UI 設計 缺點：成員被 Wireframe 限制，難以跳脫既定印象，成為只是產出視覺的工具 因此在工作坊結束後，我決定調整指派設計任務的方式： 一樣給定明確目標，包含產品目標與設計目標，讓設計師知道如何評估他們最終的設計 調整規格顆粒度：只給一定要有的規格，其餘全部不講讓設計師有更大的發揮空間 提前 Review：我們每兩週一次 Sprint Review 和 Planning，但不把所有該 Review 的東西丟到 Sprint Review 才討論，而是在此之前就必需完成 Design Lead 或是 PM 的 Review。Sprint Review 的目的除了讓各個設計師 Sync，也是讓其他彼此的回饋能透過一個正式場合表達出來，在正式進到開發之前還有一個微調的緩衝。 一切都是假的，只有產品上線才是真的。在與開發團隊討論過後，我們評估在年中只能開發出一項最核心的機制。 我回頭與設計團隊多次討論了我們該怎麼在最精簡的產品規模下提供最核心的體驗，然而設計團隊的想法擅長發散卻難以收斂。當時我們已經設計了社群討論以及協助分享者增加影響力的功能，但最後一一被我刪減，設為 Pending。 Productlife 的願景是「讓每個產品知識學習者能因找到共同學習的夥伴而成長」，希望打造社交優先的學習體驗。當我回過頭來檢視我們核心的目標，就發現一對一的配對就可以實現最精簡的社交功能，但還是能保有透過社交來學習的體驗。所以我們接下來只專注把一對一的配對體驗做到最好，別的需求和功能可以稍微想想，但暫時都不會進行設計。

daniel-lee.medium.com

管理 Side Project 設計團隊，如何讓成員能夠有學習也有產出
我在 BotBonnie 做 UI/UX 設計實習的 3 個 Takeaways

BotBonnie 是一個設計聊天機器人的平台，在本質上是一個 B2B 產品，我們幫助企業用更低成本、更平易近人的方式增長用戶與維護客戶關係。當然我們不乏個體戶選擇使用我們的免費機器人，但要在個體戶建立變現漏斗在這個產業中是個很有挑戰性的事，因此，無論是商業模式，或是在內部運營決策時，都還是以偏向 2B 的思維進行規劃與決策。 在我進來 BotBonnie 以前，取得質性用戶回饋的方式只有客服、成功案例訪談，以及客戶教學的過程中會被問到，即使這些的確能夠幫助點出設計上的盲點，但因為沒有去深入了解問題背後的原因，較常是問題出現頻繁或是客戶比較重要的時候才會被考慮排進優化時程。 重點不是用了什麼方法或做了多少研究，而是洞察能否發揮影響力 不去做進一步質性研究的原因可以有很多，但對 BotBonnie 而言，我覺得挑戰主要有二： 許多人期望使用者研究的結果是能幫助產出一個有效的設計，但實際上使用者研究能給的「研究發現」。一個有效的設計還需要經過設計師將研究發現轉化、測試、迭代，才有機會落地。因此真正的問題在於， 老闆不一定知道什麼樣的問題與時機適合由研究員介入找出答案 。 我舉我在 BotBonnie 曾經做過算接近使用者研究的專案為例。 BotBonnie 編輯機器人對話的操作流程有著許多已知問題，但是這些問題都是碎片式地搜集來的，缺乏論述將它們串起以讓人理解前因後果 。而我在執行易用性測試後找到了當前設計與使用者認知衝突之處，因此後續某個套件的設計就依據測試後的發現做了新的 Component。 另一個是我設計的註冊流程，一直都蒐集到使用者會害怕點擊按鈕、不知道輸入的資料會怎麼被運用的回饋，有些步驟甚至完全沒有收過使用者回饋卻有著 40% 的流失。因為內部討論改了一版文案後數據還是不見起色，於是我便執行了一輪測試，以便從訪談中了解問題發生的原因 。這次的測試因為已知不是易用性的問題，我便使用開放式的測試而不給予任何任務，並蒐集到了所需的回饋。 對於兩週一個 Sprint，每週上一版的 BotBonnie 而言，每個開發或設計的 Story 都能在 1~2 個禮拜以內產出一個「可接受且能上線」的解法，因此當使需要多花 1~2 週的時間和受測費來找 6、7 個人完成研究，就是一件不符合開發文化與主觀感受的事。再加上由於是 2B 產品，對於 UX 問題的容忍度本來就比較高，是否投入資源進行研究的問號就越來越大。 以客觀上而言目前 Chatbot 設計平台正處於「開始搶佔細分市場」的階段，有的主打能更簡單自建 AI Bot，有的主打整合 IoT 創造生態系，有的主打各式各樣的行銷功能協助導流轉單。也就是說快速規模化以往客製化的功能，並且推出各式成功案例在目標客群建立「當我要做_____類的機器人我就要找_____平台」的認知，是目前各家機器人設計平台正在做的事。而這件事因為關乎時間，所以佔用時間的使用者研究，就變得比較不利公司發展。 其實這邊目前就我所知沒有非常好的解答，要在低資源或甚至沒有資源的情況下完成使用者研究有三個方向： 以我的測試為例，我以「免費 1 對 1 教學」為由成功邀請到 3 位不用支付受測費的受測者，是因為這些受測者真的需要快速理解聊天機器人如何建立與運用，而我也真的針對個人情境進行了一些客製教學。 另外我也在加入 BotBonnie 的初期，額外花了很多時間從社群中找潛在使用者當面或是線上聊天，來了解大家使用聊天機器人的目的以及期望中的使用情境，只是為了建立對使用者樣貌的基礎認知。 當然，這些替代方案都不如嚴謹規劃過後的一場場使用者研究，但是做產品並不要求一步到位，而是心裡要知道還有哪些改善空間，並且確保能在迭代中逐步改善。 由於是中小型新創，目前我們只有一位正職 UI/UX 設計師，因此設計師除了需要兼顧 UI 與視覺美感，還要能夠釐清狀態邏輯與良好的使用者操作流程。 在一開始的時候，我的 Wireframe 只用來展示基礎流程與概念，Review 過了開始畫 UI 之後才會把所有情境列出來。由於我的專案多數是從 0~1 的設計而不是單純改動現有 UI，因此有許多無法用現有機制與 Components 執行的設計，導致最後安排開發 Story 的時候，都會有所取捨，先留下核心流程，再來看看是否開發其他設計。 盡早列完可能的情境與頁面，協助評估與縮減專案時程 後來我起 Soking 在〈 我的產品設計文件演進史 〉一文提到他如何使用 Wireframe： UI 設計師要實作的畫面數量，在 Wireframe 上都應該要可以查詢到對應的規劃。盡量在UX規劃階段消除專案的不確定性，以及辨別需求凍結之後產生的變更。 因此如果 Wireframe ...

medium.com

我在 BotBonnie 做 UI/UX 設計實習的 3 個 Takeaways
5 分鐘申請 Miro 教育版！遠端教學必備的線上白板，同步編輯人數無上限

Miro (幾年前叫做 Realtimeboard) 是一個線上白板工具，對於生活中總是少不了便利貼和手繪流程圖的 UX 設計師而言是非常方便的替代工具。事實上這幾年 Miro 已經逐步發展成一個全方位的線上工作坊與會議工具，除了便利貼、手繪圖、心智圖與商業框架模板以外，還具備了投票、計時、共編會議記錄、聊天室、線上視訊等等進階功能。 這麼方便的工具原本就已經有免費方案，能夠讓 5 個人加入團隊進行即時編輯，超出 5 位的話，其他人就只具備檢視的權限。在疫情高峰時，也有許多 UX 設計師因為他的方便性，願意付費使用這項工具舉辦線上工作坊。 完整的教育版方案基本上就是團隊 (Team) 方案的改版，不過只有在大專院校就讀或工作的人可以申請，只要申請成功就可以擁有： 無限制的白板數 單一白板不限制團隊協作者＋Guest 協作者數量 高品質的圖片下載，且不會有浮水印 支持手動備份 投票 計時 如果你是教育人士，那麼這個教育帳號： 沒有期限 最多可以加入 100 人到 Team 裡面 如果你是學生： 每兩年需要重新申請一次 最多可以加入 10 人到 Team 裡面 完整的各式方案比較可以看這裡： 我是在使用時看到 4/30 的更新通知中看到 Education Plan 這個字，才發現原來 Miro 終於針對教育情境推出新方案，然而點擊了 Upgrade 按鈕，跳出來的方案卻沒有教育方案的選項。

medium.com

5 分鐘申請 Miro 教育版！遠端教學必備的線上白板，同步編輯人數無上限
一個人的聊天機器人設計衝刺 One-Person Chatbots Sprint

多人活動進行方法 (30min) 1. 每個人先花1分鐘各自安靜地列出任何想得到的顧客類型2. 唸出來後由 Facilitator 列在白板上3. 所有人安靜地閱讀全部的顧客類型，並寫下自認最重要的2個類型4. 唸出來後由 Facilitator 將投票結果記在白板上5. 花5分鐘討論6. 由決定者投票選出前2重要的顧客類型7. 每個人先各自安靜地寫下2個類型顧客會經過的10個步驟，一張便利貼一個步驟8. 依顧客類型分類並依序貼出來，各自在覺得重要並會影響顧客體驗的步驟貼上貼紙9. 拿掉沒有貼紙的便利貼10. 聚合成一個大地圖，並在不同類型人物之間畫上可能的互動 在了解顧客在 Onboarding 上的需求後，便可以決定應該要在機器人內規劃哪些功能，以及可能的互動流程，此時便可以應用資訊架構的觀念來初步進行設計。 傳統在設計資訊架構時會使用卡片排列( Card Sorting ) 的方式，邀請 15 位以上的顧客進行認知研究，來決定架構的設計方向。然而在資源不足的條件下，僅能使用手中有的資訊來建立足夠好的假設。這些僅有的使用者資訊資訊可以來自產品本身或官網已經設計過的資訊架構，或是顧客旅程地圖等等。 簡單分類好任務情境之後，可能的型態會是如下圖： 而如果對於結合流程有更多想法，可以利用類似心智圖 (我是用 Miro，比 Xmind 好看很多) 的方法長出更多的任務細節步驟： 先建立要達成目標的條件下所需的架構，其餘想法等下個 Sprint 再討論。簡單來說，就是一個排序、分版本的概念。 在建立 BotBonnie 教學 Bot 的時候，我原本想把所有教學都在機器人內完成 (完全忘記前面的定位宣告了)，然而我只建了兩個流程就發現太耗時，會趕不上時程。 也是在這邊我就自己定義了一個準則：「如果引導教學要超過 3 步驟才能講完，就改為引導到 Medium」。這個準則能夠幫我避免過多的重工，並讓 Chatbot 和 Medium 發揮各自的優勢。不過這個準則不一定適用每一個機器人，每個機器人要追求的長期目標與設計問題以及所處的工作環境和參與的工作流程，都會影響排序的標準，因此在這邊我只提出一個概念，大家可以彈性的修改與應用。 多人活動進行方法 (30min) 1.

medium.com

一個人的聊天機器人設計衝刺 One-Person Chatbots Sprint
如何設計客服聊天機器人 - 理論篇：探索顧客體驗導向的設計準則

客服一直是聊天機器人的主要應用領域之一，然而對於如何建立一個客服機器人，以及如何設計好的客服機器人體驗，似乎還沒有一個夠完整、夠精確的準則與流程可以遵循。因此我在 BotBonnie 所接到的第一個任務，就是嘗試以顧客體驗的角度出發，探索何謂好的客服機器人設計，並發展出設計準則與流程。 有關聊天機器人的設計工具，推薦大家試試 BotBonnie 的免費版，BotBonnie 的一大特色在於拖拉式的視覺化腳本流程設計，而不是一般難以上手的卡片式介面，免費版沒有限制使用期限，只有在功能與用量上與付費版做區隔。 與客服聯繫代表了使用者體驗產生問題，而我們發現這在中度複雜的顧客旅程中，有高達 64% 的機會會發生 - Nielsen Norman Group (NN/g) 使用者體驗作為現代產品與服務留存顧客的關鍵，當顧客進入了客服流程，客服就成為了留住顧客的最後關卡，因此如果客服的體驗再產生問題，潛在的損失就難以忽視。 NN/g 是美國最知名的使用者體驗顧問之一，創辦人包含了創造 UX 一詞的Don Norman 以及以「只要測試5個人就足夠發現85%易用性問題」研究聞名的 Jakob Nielsen。在 NN/g 對電商網頁客服的研究中，他們提出了以 Hub-and-Spoke Model 遞送客戶服務的建議，Hub 指的是「匯集點」，而 Spoke 是一個「軸」。 NN/g 以此模型發展出一些網頁設計上的行動方針： 以「客戶服務/客服協助 Customer Service/Assistance」作為主要匯集點 (入口) 的名稱，「常見問題 FAQ」或是「聯繫我們 Contact Us」作為次要匯集點 (入口)，或者不一定需要成為匯集點 匯集點之間必須能夠彼此連結 其他與客戶服務相關的頁面就屬於軸，每個軸都必須與匯集點連結 雖然這些建議是針對電商網頁提出，但只要能辨識不同的產品與服務中，使用者與顧客最常活動的地點以及認知中客服應該出現的地方在哪，一樣能夠以此模型進行客服遞送設計來提升客服體驗。 由於對話式介面已經成了現代人生活中不可缺乏的介面之一，以一個自動化代理人作為客戶與企業之間的橋樑的想法應運而生。客服機器人就是在企業與顧客之間，以對話互動的方式承擔部分真人客服工作的聊天機器人。機器人的優勢在於能夠每天24小時都隨時上線工作，而且不需任何的等待時間，因此擁有留住顧客的潛力。 以往我們常常把客服機器人當作「真人」客服設計，希望能取代真人客服的人力，並會使用「機器人畫像 Chatbot Persona」來形塑機器人在顧客心中的形象，以提升互動體驗。然而近期一篇於 CUI 2019 發布的研究 (Følstad, & Skjuve, 2019) 指出，由於使用者幾乎能夠在數秒內就辨識出與其對話的對象是機器人，因此機器人的角色設定對於互動體驗其實沒有太明顯的正面影響；而另一篇於 TaiCHI 2019 發布的研究 (昝亭瑜，董芳武，民108) 同樣指出機器人的個性化對於使用意願的提升沒有影響。 在與多個客服機器人互動過後，我整理出了數個機器人的互動流程與資訊架構，並且找到了一些共通模式： 現在的客服機器人已經不再只是客服，其涵蓋的服務接觸點已經從「使用中」的解決使用問題，延伸至「使用前」的了解產品與「使用後」的與品牌互動，透過良好體驗與導引讓行為循環，持續留在品牌服務內。 在這個部分，客服機器人會介紹功能、費用、特色，以及進行使用上的引導教學。 這是傳統客服會處理的部分，一些常見的問題包含了功能操作、收費付款、建置設定，若沒有好好設計，常常會馬上轉往真人客服。 客服機器人同時扮演了行銷的角色，不論是線上或線上 Campaign，都可以在機器人內建置入口，根據目標進行轉化流程設計。 接下來我想透過 NN/g 去年發布的〈The User Experience of Chatbots〉這篇文章與大家簡介目前 Chatbot 的一些限制和在設計上應該注意的地方。 我們的使用者研究說明了，當使用者脫離聊天機器人預先規劃好的線性引導流程，往往會遭遇困難，現今的聊天機器人，離「智慧化 (intelligent)」還有很長一段路要走 NN/g 將 Chatbot 分成「客服機器人」與「互動機器人」兩種類別，並且特別提出「 通常大家認為客服機器人比真人客服更沒用 」的一個大挑戰。尤其有些企業不願意揭露自己的客服是機器人，當顧客遇到機器人沒辦法應付的問題時，往往造成更差的體驗。 如果你用的是真人，代表你夠在乎客服，但如果你是用機器人，你最好確保你有一個很好的機器人 根據 NN/g ...

medium.com

如何設計客服聊天機器人 - 理論篇：探索顧客體驗導向的設計準則
實習面試經驗分享：UI/UX設計、UX研究、產品經理、資料應用專案管理

有關履歷的內容，網路上有許多資源可以參考，但是有一點我想可能許多做過 UI/UX 設計專案的同學們會有點困擾： 沒有增長的數據可以說明設計或研究的影響力 。這點我其實也卡了很久，總不能掰數字出來吧，有些有過實習經驗的人可能因為碰過真的產品就會有數據可以說，但我剛好就都沒有啊是想怎樣啦(兇)！於是我就把過程中的產出數量寫出來，比如「歸納出 2 個設計人物誌」、「規劃 3 項設計策略」之類的，至少能讓人理解你做了多少事。有人有辦活動的經驗但沒有具體效益可以寫(很多就是為辦而辦辦爽的啦，或者當時根本沒想到要評估效益)，也可以透過如「為 100 人規模的 6 日工作坊規劃 8 場講座，並邀請 18 位業師與教授擔任講者與評審」等規格取向的數據(而非增長取向)，讓閱讀者自行解讀規劃與公關的難度。 6月的時候因為剛好結束跨界超越競賽的專案，於是我開始整理閒置許久的網頁作品集。說整理是因為更新的幅度實在不大，我更新了 2 個完整的專案經歷，還有 3 個到目前都只完成了 Brief，不過我的想法是： 那麼多的專案，其實只要有2～3個足夠呈現我所具備能力即可 ，事實也證明這種策略沒有問題。 作品集的內容寫法我不會仔細說明，因為我也還在探索有沒有更好的呈現方式。不過目前來說，我可以提供我的架構給大家參考： 總覽 Overview 描述專案目的、目標族群、需求、解方，以及成果效益，並且附上專案時程、團隊配置與擔任的角色、主要職責 簡介 Introduction 包含專案背景、二手資料概述、執行專案的動機與目的、成品概述與影響力 挑戰 Challenge 說明這個專案的難度與限制，後面內容應說明如何克服挑戰 研究 Research 研究規劃、目標、問題、流程、方法、洞察、發現、人物誌、旅程圖、設計策略、行動方案，簡單來說該有的流程要有，該有的圖也要有 設計 Design 功能架構、資訊架構、使用者流程、線框圖、互動流程與原型、設計規格，簡單來說該有的流程要有，該有的圖也要有 評估 Evaluation 規劃、目標、問題、流程、方法、發現、改善策略、行動方案 迭代改善設計方案 Iteration 同設計，著重闡述改善處 結論 Conclusion 與

medium.com

實習面試經驗分享：UI/UX設計、UX研究、產品經理、資料應用專案管理