隨著談UX工作的文章變多,先簡單整理一份目錄放著。

Hahow 線上課程《產品分析入門:UX 設計師的思考術》

設計交付

資訊架構

UX 寫作 (UX Writing)

工作想法

用戶訪談

讀書筆記

工作坊

最近在籌備新課程《需求訪談工作坊》,於是將想到的一些雜談記錄下來。

雖然聽起來很像玄學,但影響軟體開發過程最大的因素還是人心。

因為軟體開發的結果是許多人彼此交流之後的共識,當心態走鐘了,幾乎不可能得到理想的結果。

需求方最重要的職責就是扮演好那個「理想的初衷」。

從神經科學的研究結果,我們知道心態會影響生物機制,讓體內的神經傳導物質引起變化,簡單來說就是當我們心態趨於保守的時候,身體反應後的機制,會讓腦袋很難獲得新資訊。

再強調一次,保守心態會影響生理機制,讓腦袋很難吸收新資訊。

偏偏軟體開發的本質是要創造一些新東西,這一定會造成改變。

例如,要改變過去憑經驗與直覺作事的方式,必須要變成明確的條件以及規則。

心態過不去的人,希望留在原地,所以心思花在刁難軟體系統上,認為這麼多例外狀況,軟體根本幫不上忙,還是以前的作事方式比較靠譜有彈性。

心態過得去的人,才有機會看到新事物產生的可能性,因為腦袋的神經機制處於探索模式,可以幫助我們更容易想像事物之間的連結,啟發我們產生更多有用的想法。

更關鍵的是,心態過得去的人,會把錯誤當做成長的機會,他看到軟體系統發生錯誤或者不符合期待的狀況,會有機會聯想到更好的方向應該如何前進。

而心態過不去的人,看到軟體系統的錯誤或不符期待時,會陷入自我矛盾,浪費許多時間在原地打轉,並且充滿各種短期情緒的認知偏誤。

因為在心態過不去的人眼中,那些軟體的狀況是「我早就說過這樣不行」。

軟體開發不是物理世界的材料組合這麼具象事物,軟體開發是一大堆「我需要這些資訊的幫忙」的抽象事物與規則的集合體。

所以心態過不去的需求方,當他今天用固定心態希望軟體復刻的是此時此刻他所擁有的一切時,就像希望在同一條河上面撈兩盆水,但期望這是完全相同的結果。

這就是「人不能兩次踏進同一條河流」,當我們第二次踏入同一條河的時候,接觸到的水、泥沙以及石頭,都不是上一次接觸到的東西。

軟體承載的訊息之河,也是持續在變化的。

成功活下來的軟體,都是持續改善的軟體,因為我們的世界也一直在變化,人們彼此溝通與協作的方式也在變化。

所以當我們的組織下定決心要「開發軟體」時,其實就是在「尋求改變」,並且這個改變是一條恆常的旅程。

持續改變是一個反人性的事情,因此需要有人保持初衷與願景,成為軟體開發中團隊前進的引領者。

這就是我認為扮演一個成功需求方的條件。

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

2021年是成為自僱者身分的第五年,也是我逐步提昇對自己在 UX 教學這條路上專業要求的一年。

這篇文章記錄 2021 年完成的事情,總結來說,我在 UX 教學的這條路線上繼續紮實了馬步,有了更純熟的課程規劃能力與現場演練的引導技巧。

2021 年透過實體課與直播課程,我前前後後與五百多位同學一起創造了學習的體驗,因此衍生出額外的合作機會,包括企業內訓以及顧問服務的合作。

在這一年中,我做了這些事情:

  1. 與商業思維學院合作,錄製了九個小時的產品設計線上課程,製課的過程水深火熱不在話下,但熬過這份壓力之後著實令我成長,花費苦心整理課程的知識結構,成為我整年份成長的動能。
  2. 2020年末的時候我寫下雞排帖,立誓要推出的資訊架構設計課程,順利舉辦了好幾場的線上講座、試教課程,甚至收到了企業內訓客戶的邀約,這個卡關我兩年的大魔王課程,我的能力終於提升到可以正面挑戰了。
  3. 用戶訪談工作坊在 2021 年完成了非常豐富的昇華,我錄製了線上課程、也嘗試運作了六週的實戰營、因應疫情也採用直播形式進行教學、進行了好幾場企業內訓,這堂訪談課是目前服務形式最完整的課程產品。
  4. 新研發了易用性測試工作坊,這個課程始於企業內訓客戶以及我們產品專案的服務,後來嘗試改編成為公開課。
  5. 新研發了需求訪談工作坊,我在教用戶訪談的時候發現,許多同學混淆了用戶訪談(跟終端使用者聊聊他們遇到的狀況,挖掘潛在需求)以及需求訪談(跟利害關係人一起達成共識,協商產品服務應該如何交付),俗話說得好,用戶問題之所在,就是產品機會之所在,所以在年底的時候嘗試舉辦了試教場,反應似乎不錯。
  6. 今年以顧問服務的形式,協助了幾個不同產業的企業客戶,產業橫跨銀行、新創、區塊鏈、零售品牌,但對於產品設計顧問這個服務形式,我覺得自己還在初學摸索中,謝謝這些客戶的信任。
  7. 今年進行了五個專案,一個是去年的客戶回鍋再次找我們服務,兩個是新平台開發,兩個用戶研究相關的專案,另外有 27 個最後沒有談成的合作。
  8. 我們從實習生轉成正職研究員的小樓畢業了,她很喜歡新的工作,祝福她走上這條路。
  9. 我們多了一位新夥伴仲芸,她現在是八爪章魚的模式在支援各種工作。
  10. 我們邊工作邊偷偷摸摸的開發了一個線上學習系統,但其實還沒有想清楚定位,有人想贊助嗎?
  11. 我們將使用了四五年的「工作室」身分,重新註冊成為「股份有限公司」,有人可以教我該怎麼樣讓一個設計顧問公司建構商業模式,讓成長飛輪上軌道嗎?
  12. 我們家買了一台新車,有十一次的露營,以及多了幾次愉快的週末。
  13. 大概買了 81 本實體書,39本電子書,我正在持續降低買實體書的比例。

最近在籌備新課程《需求訪談工作坊》,於是將想到的一些雜談記錄下來。

最近我在客戶那邊進行顧問服務時,經常趁機引導客戶演練如何進行跨部門的需求溝通。

其中最關鍵的要訣,就是使用正向表述的字詞進行表達。

例如,如果你想討論某個規格要變動的提案

✘ NG 講法:這個規格不能這樣做!因為會出現 OOXX 問題…

✔︎ 正向表述:這個規格有另外一個方向需要討論,因為我們之前發現了 OOXX 問題…

採用正向表述的理由不是因為「想當一個好人」這樣的心態作祟,這邊有三個前提以及三個好處,讓我分析一下。

三個前提:

  • 我們的觀點可能有偏見
  • 對方可能有隱藏情報
  • 目前討論的議題不一定有絕對的品質驗證指標

三個好處:

  • 正面積極的情緒,有助於大腦產生聯想
  • 反向論述的邏輯造成認知負擔,正向表述較容易消化訊息
  • 正向表述較容易重塑溝通的認知框架,加速達成共識

我們在進行需求溝通的過程,最容易遇到的大魔王就是「太快跳入細節」、其次就是「只看到自己想看的」以及「短期情緒干擾」。

我發現,這些大魔王都不是一下子就蹦出來的,而是從異界撕開一小道縫隙,隨著溝通過程累積的認知落差而來。

換句話說,因為許多小狀況以及誤解,小怪被養成了大魔王,我們都太小看每一次小小的溝通進度,而又過度期待用一場戲劇化的大會議來決一死戰。

最好的需求溝通,是到會議室全部人一起開會之前,已經有共識基礎。

而「正向表述」就是一個在需求溝通過程,很棒的原子習慣。

如果說訊息的溝通就像一條高速公路,從我們嘴巴講出來的話,上了交流道,要找到正確的交流道才能抵達對方的腦袋中,重新還原意思。

狀況來了,我們的大腦在下訂單到出貨的過程,有可能會搞混訂單,所以我們表達出來的語言,只是全部想法的一部分。

所以當我們用負面表述、反向邏輯在評論或說明一件事情時,雖然不一定有攻擊別人的意思,但光是「聽起來很費力」、「聽起來有不舒服感受」、「質疑事情不是這樣」這些內心戲,就足以讓認知的高速公路塞車。

認知負擔讓對方要花費額外心力確認你的意思,負面表述會讓對方的情緒跑出來,想確認自己是不是遭受攻擊。

這些都是摩擦力,墊高了溝通成本,也就等於提昇了專案風險。

把要表達的意思重新整理變成正向表述,一開始不容易,這是對自己認知負擔比較大的轉譯工作。

經過實驗證明,下班之後的非工作時間,我也沒辦法對小孩維持正向表述(喂)

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

在 Hahow 的線上課程《產品分析入門:UX設計師的思考術》收到很多UX實務問題,答覆之餘也在這邊作個記錄。

Hahow同學的提問

請問用戶訪談大多使用的情境是在產品優化的時候嗎?

在產品新功能發想時,除了既有功能外,還想再豐富產品的內容,可以利用用戶訪談尋找用戶的淺在需求,進而發現新功能的契機點嗎?訪談的目標範圍會設定的太寬泛了嗎?

謝謝

我的回答

哈囉,感謝同學的提問,這是一個很實務的問題

我重新整理一下同學的提問,包括:

1. 用戶訪談最常使用的情境是什麼?

2. 產品新功能發想時,如何透過用戶訪談來挖掘用戶需求?

以下是我的看法,提供你做參考

在討論用戶訪談的使用情境時,我喜歡推薦同學從「用途理論」來思考,意思就是說,尋找我們的產品服務,被使用者找來解決什麼問題的情境。

透過了解使用者為什麼需要我們的產品,就可以發現他們的痛點與期望,這就是需求之所在。

所以回到你的問題「用戶訪談最常使用的情境是什麼?」

在用途理論中,有兩個關鍵時刻是我們可以注意的,這分為「大雇用」與「重複發生的小雇用」。

大雇用就是使用者採納我們的產品服務,替換掉原本不夠好的方案,成為顧客的那一個時刻。

重複發生的小雇用,就是使用者發現我們每次都可以幫他達成任務,因此每當那個任務情境出現時,就會重複回來使用我們產品服務的那個時刻。

從產品的角度來看,大雇用的時刻,告訴產品團隊如何拉新、如何定位你的新產品推向市場、如何找到跟競品差異化的關鍵因素。

重複發生的小雇用,告訴產品團隊如何優化轉換率、如何 Call back、如何提昇 LTV、如何發生口碑推薦。

當你理解了用戶訪談這種透過「探索用戶情境尋找創新機會」的方法後,你的第二個問題就順帶有了明確的答案。

那就是「不要在會議室裡面發想新功能」,去接觸真實市場的使用者,從他們身上尋找不滿意的地方,以及他們希望自己的生活可以如何改善。

透過幫助使用者的工作與生活更好,這就是發現新功能的契機。

以上提供你參考

by Soking

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

今年在商業思維學院開課了一系列從需求訪談、用戶研究到資訊架構、原型設計等等的產品設計課程,在這邊記錄一下學生的提問,以及我的回答。

商業思維同學的提問

[提問]sitemap 必須加上路徑的原因?

就自己公司和過往經歷的專案中,在sitemap階段文件的產出,看到都是比較屬於樹狀圖概念的形式,沒有納入操作流程這部分,比較像是首頁下方包含什麼功能,每個功能包含什麼項目,包個項目包含什麼資訊,所以想請問老師的意見,是否sitemap都最好加上路徑的概念?因為路徑這部分是不是,其實直接在wireframe階段處理即可?謝謝

我的回答

哈囉,很高興看到同學的提問

關於你提到「sitemap 的路徑概念,是不是在 wireframe 處理就好?」

以下是我對這個議題的看法,提供你參考

首先,我們講的路徑其實就是「產品上的動線」,有點像是你去百貨公司逛的時候,要知道上下層可以走電梯、手扶梯、逃生梯,平面層可以如何從 A 區逛到 B 區。

換到產品上來說,就是我們整個產品有多大?每一區可以幹嘛?希望如何引導用戶前往?

其實 sitemap 就是先把整個建築會有幾個樓層、如何分區給定義出來。

到了 wireframe 的時候,再進一步描述每個分區內的燈光、電線、空間格局、裝潢、收納規範等。

如果等到了 wireframe 階段,討論每一個分區的細節時,才處理 A 區如何抵達 B 區,容易掉入見樹不見林的陷阱。

當產品很小的時候,這個問題不複雜,很簡單就可以處理。

但如果不幸(或者幸運?)你經手的產品發展飛快,每個月都持續有新東西要繼續延伸的話,你會非常慶幸事先有花時間整理產品路徑的格局以及規則。

因此你可以從全局觀點評估後面發展的新事物如何與舊有的東西在層級上的融合方式。

以上是我的看法,提供你參考

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

最近在籌備新課程《需求訪談工作坊》,於是將想到的一些雜談記錄下來。

以前我當PM的時候,一直覺得需求訪談是一個談判協商的過程,但這個認知讓我痛苦不已,因為充滿矛盾與零和賽局,以及我總是想要當個好人。

這次整理教材的過程,我深度思考後,找到新的定義,改變我對需求訪談的看法。

需求訪談是一個「定義認知框架」的引導過程,我們是協調眾人的認知框架的引導者,而不是像批改作業一樣看到問題給出答案的作答機器人。

認知框架就是有色眼鏡,它會選擇性的制約我們的認知範圍,最後決定感知與思考的輸出結果。

認知框架會將「我們看見」、「做出什麼判斷」、「決定哪些行為」引導至特地方向,導出一定範圍內的結果。

所以對那些認為某件事情非做不可的人來說,一開始就不會去思考這件事情不能做的原因是什麼。

而從一開始就認為某些事情不能作的人,他們根本就看不出來為什麼非做不可。

這些就是我們在處理需求過程經常遇到的矛盾來源。

舉例來說,面對專案中的風險。

我們都知道需求方的背後往往還有好幾層,但對於風險的敏感度不同的人,可能就會做出不同的判讀。

例如你的窗口是菜鳥,他對於工作的看法很壓抑、戰戰兢兢的在面對專案,生怕自己在公司黑了,所以對於風險很畏懼。

但他背後的主管又資深又有靠山,根本不想刻意配合其他人,從一開始就不需要被討厭的勇氣,所以在專案裡面的風險對他來說就是搔癢。

俗話說鐵打的衙門,流水的官,上面總監換了,部門主管都還妥妥的。

然後更背後的總監新官上任需要三把火,他就要短期內可以端出來的菜來證明自己。

再更上面的大老闆根本是個風投思維的人,手上開了幾十個專案在丟骰子下注,他要知道的不是完美計畫,而是風險與收益。

這些人對需求的看法會一樣嗎?

這就是為什麼,我們不應該聽到「表面的」需求描述,對方給了聽起來像解決方案的觀點,我們就趕快端菜出去。

除非這是銀貨兩訖的固定規格品的產品買賣,才有這麼美好的事情。

一旦涉及依據需求方的想法提供服務的方式,我們都要謹慎面對需求方所講的「觀點」。

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

【雜談】需求方不是故意的,只是大家都沒經驗

擔任設計師這個工作一陣子之後,你會很有趣的發現,要把手上接到的工作漂亮達成,仰賴一些前置條件,而工作找上你的時候,往往不具備充分的前置條件,現實一點的情況是,這些前置條件甚至是隱藏情報,需要你自己當偵探。 但需求方也不是故意的,大多數的人都不擅長當需求方。 這就好比你吃了一輩子的夜市小吃,夜市小吃菜單明確,點什麼吃什麼,你對料理過程也沒什麼可以決定的,頂多問你要不要香菜跟加辣,彷彿這就是客製化了。 但突然有一天你去台菜海鮮餐廳,看到店門口一整櫃的海鮮,傻眼貓咪,怎麼沒有菜單?每個客人都在店門口跟老闆指指點點,輪到你的時候老闆的語氣又快又急,你楞在那裡發慌,這些都是什麼沒看過的魚?要怎麼點?價錢是多少?什麼叫時價?那我怎麼知道整桌菜要多少錢? 這些點菜的眉角,要吃過、看過、聽過,模仿別人怎麼做、聽聽看老闆的建議之後,才逐漸能摸索出自己的一套點菜方式,然後才會知道更深的一層,原來每一家店適合的點菜方式都不一樣,想要特定的吃法,還要找對店。 點菜點久了,你才能根據要招待什麼客人、聚餐的主題、這個季節適合吃什麼等條件,選擇適合的店,決定恰當的預算,作一個得心應手的需求方。 這些事情中,隱藏著大量的學習成本,顯現在軟體專案上,就是有關於需求的風險。 你在軟體專案上,幾乎一定會發生「點錯菜」的狀況,即使是資深的需求方也難以避免。因為干涉需求的情境實在數也數不清,你以為的需求方,背後還有需求方,一層一層的關係越來越抽象,甚至難以定義共識。 偏偏人腦就是厭惡模糊難以理解的事情,喜歡具體明確的東西,所以會希望你先做做看再說,這樣需求方才知道自己的需求,你瞧,這不就是學習的過程嗎? 進行觀察、提出假說、動手測試概念、分析成果,然後再進行下一輪的行動,所有人在這個過程中萃取出共識(或者獨特的領域知識),事情才逐漸明朗,需求方才明確知道自己應該點什麼菜。 這些事情用文字書寫起來好像輕鬆愜意,但在現實的工作期程中,卻是在充滿壓力、經常發生短期情緒干擾、利益不一致、缺乏共識、回饋模糊不清、溝通用語充滿歧義的情況下,要跟需求方進行兩人三腳。 所以,有時候你的需求方也放棄掙扎了,因為一切真的太模糊太抽象,又不是擔任需求方就知道怎麼做才是對的。 而如果我們也放棄掙扎,變成單純的聽令行事,反正需求方告訴我們什麼,非要畫押白紙黑字才執行,風險都是別人扛,那就把自己變成工人智慧的滑鼠以及語音輸入法了。 這樣的兩人三腳關係,就會成為觀落陰的地獄。 這就是為什麼,當我們開始成為能獨當一面的設計師之後,不能只是躲在設計語言的背後只處理專業工作的原因。

擔任設計師這個工作一陣子之後,你會很有趣的發現,要把手上接到的工作漂亮達成,仰賴一些前置條件,而工作找上你的時候,往往不具備充分的前置條件,現實一點的情況是,這些前置條件甚至是隱藏情報,需要你自己當偵探。

但需求方也不是故意的,大多數的人都不擅長當需求方。

這就好比你吃了一輩子的夜市小吃,夜市小吃菜單明確,點什麼吃什麼,你對料理過程也沒什麼可以決定的,頂多問你要不要香菜跟加辣,彷彿這就是客製化了。

但突然有一天你去台菜海鮮餐廳,看到店門口一整櫃的海鮮,傻眼貓咪,怎麼沒有菜單?每個客人都在店門口跟老闆指指點點,輪到你的時候老闆的語氣又快又急,你楞在那裡發慌,這些都是什麼沒看過的魚?要怎麼點?價錢是多少?什麼叫時價?那我怎麼知道整桌菜要多少錢?

這些點菜的眉角,要吃過、看過、聽過,模仿別人怎麼做、聽聽看老闆的建議之後,才逐漸能摸索出自己的一套點菜方式,然後才會知道更深的一層,原來每一家店適合的點菜方式都不一樣,想要特定的吃法,還要找對店。

點菜點久了,你才能根據要招待什麼客人、聚餐的主題、這個季節適合吃什麼等條件,選擇適合的店,決定恰當的預算,作一個得心應手的需求方。

這些事情中,隱藏著大量的學習成本,顯現在軟體專案上,就是有關於需求的風險。

你在軟體專案上,幾乎一定會發生「點錯菜」的狀況,即使是資深的需求方也難以避免。因為干涉需求的情境實在數也數不清,你以為的需求方,背後還有需求方,一層一層的關係越來越抽象,甚至難以定義共識。

偏偏人腦就是厭惡模糊難以理解的事情,喜歡具體明確的東西,所以會希望你先做做看再說,這樣需求方才知道自己的需求,你瞧,這不就是學習的過程嗎?

進行觀察、提出假說、動手測試概念、分析成果,然後再進行下一輪的行動,所有人在這個過程中萃取出共識(或者獨特的領域知識),事情才逐漸明朗,需求方才明確知道自己應該點什麼菜。

這些事情用文字書寫起來好像輕鬆愜意,但在現實的工作期程中,卻是在充滿壓力、經常發生短期情緒干擾、利益不一致、缺乏共識、回饋模糊不清、溝通用語充滿歧義的情況下,要跟需求方進行兩人三腳。

所以,有時候你的需求方也放棄掙扎了,因為一切真的太模糊太抽象,又不是擔任需求方就知道怎麼做才是對的。

而如果我們也放棄掙扎,變成單純的聽令行事,反正需求方告訴我們什麼,非要畫押白紙黑字才執行,風險都是別人扛,那就把自己變成工人智慧的滑鼠以及語音輸入法了。

這樣的兩人三腳關係,就會成為觀落陰的地獄。

這就是為什麼,當我們開始成為能獨當一面的設計師之後,不能只是躲在設計語言的背後只處理專業工作的原因。

我們要往前多站幾步,尋找更多方式,去幫助需求方降低他們的認知負擔,做出更有品質的決策討論。

一個重視品質與有所追求的大廚,必定會自己去進行食材的採買,誇張一點的甚至會自己從農場開始作起。

七分靠材料,三分靠手藝。

採取行動幫助需求方取得品質可靠的原料,我們才能夠好好的發揮所長,最終完成更符合目的的東西,回饋給需求方,實現在市場上的價值。

這個形成正面循環的動力飛輪,需要有人跳出原本的負面迴圈,額外產生作用力。

所以我們要認知,需求方往往不是故意的,他的位子並不好坐,需要更多的助力。

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

在 Hahow 的線上課程《產品分析入門:UX設計師的思考術》收到很多UX實務問題,答覆之餘也在這邊作個記錄。

Hahow同學的提問

老師您好

訪談的用戶是經過用戶分類分群與篩選後所找出來的對象,比如某一類用戶分群下的對象一到二位,但畢竟訪談的人數在這個分類的母數占比是非常少的, 我們要如何去判斷這個用戶其中的行為是能夠代表這個用戶群的分類呢(特別是ㄧ些新發現)?還是單純剛好只是這一個人獨有的行為,其實無法代表大部分屬於這個用戶群的人。

或者轉換一種問法,訪談出來的結果,會做其他方式的進一步的驗證與分析,還是其實是能夠直接拿來當作產品設計的考量點呢?

另外想問問,您的課程有提及訪談內容的階段分為:暖場>情境行為>認知>結束>閒聊

其中,認知的部份包含了解受訪者的動機, 想了解為什麼是放在用戶說明完情境行為之後呢? 若是放在詢問情境行為之前,會有什麼影響~

以上,感謝!!

我的回答

哈囉,感謝同學的提問,這些都是非常實務的問題,很高興你提出來討論。

首先是,如果你的訪談計畫之前有根據一些條件作出了用戶分群(例如:專業用戶、小白用戶等等),那建議你每個分群的受訪者應該要至少訪談四位,這樣比較能夠觀察重複發生的行為模式。

另外,我目前的習慣上,會希望一次先研究一個用戶分群。(但如果是客戶有全新產品或者大改版,需要了解數個用戶分群來比較,又是另外一回事,所以這要看狀況)

一次處理一個用戶分群來研究,最大的好處是有限定情境範圍、成果明確,而且所需時間比較短,馬上就可以將研究洞察回饋到產品設計的提案上。

我們要先認知一件事情,就是沒有一種需求叫做「所有人的需求」,我們為了滿足了 A 情境,選擇的某個作法,不一定能同時滿足其他情境。

而當我們選擇一個同時滿足多情境,妥協下的產物時,對於 A 情境的用戶來說,往往淪為只是「堪用」,而很難到「好用」。

經過以上推論,你可以明白,如果我們分辨不出當下最重要的用戶分群與情境,也代表我們目前產品要驗證的事情或指標不是那麼清楚。

方向很模糊對於產品來說是正常的,也因此要更珍惜探索與犯錯的機會,因為我們的資源與時間不是無窮的。

所以比起一口氣多線並行研究所有用戶分群的所有情境需求,我還是最常建議,找出商業策略上最有價值的用戶分群,定義滿足產品的成長目標,再小步快跑的跟上用戶研究,來去支持或者探索產品前進需要的判斷情報。

第二個問題,你問到為什麼先問行為,才問認知,這也是一個很棒的問題。

讓我舉個例子,假設我們要問受訪者出門旅行的經驗。

✘ 不好的問法(先問認知)長這樣:

主訪:「請問你為什麼會想出門去旅行呢?」(問動機)

受訪者:「啊就…在家無聊,所以會想出去走走啊」

這樣提問不好的原因在於,受訪者跟主訪的對話中,沒有足夠的鋪陳作為素材,所以只能很空泛的討論觀感。

✔︎ 好的問法(先問行為)長這樣:

主訪:「請問你最近去過哪邊玩呢?」(問行為)

受訪者:「喔!最近疫情解封,所以我跟家人開始恢復露營的行程,對了,上個週末還有去宜蘭兩天一夜住民宿!」

主訪:「哇,你出去玩的方式很豐富,去露營之外還有去民宿。」(每個段落總結核實)

主訪:「那請問,選擇去露營跟去住民宿,有什麼不同嗎?」(問動機)

這樣提問的好處是,你先討論明確的行為,然後再根據明確的行為,請教受訪者每個行為當下明確的選擇動機,或者比較條件。

這樣對於你事後收斂訪談成果,就會有非常清楚的依據,知道每一個段落受訪者表達的觀感,是因為什麼情境所產生的,而不是一堆空泛的意見。

以上提供你參考。

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

最近因為一個案子參與的工作坊,裡面來參與的人是不同政府機關網站的主要承辦人員,他們一起來學習使用者為中心的 UX 理念。

我們分配到的小哥很有趣,如果我不知道他的職業,只觀察互動過程、聽聊天內容以及興趣,會以為他根本就是個工程師轉 PM 的技術宅。

跟他聊電影,可以談文青片。
跟他聊網站,可以談 GA 以及 SEO。
跟他聊加密貨幣,他還能大談之前搬磚的經驗。

換他好奇的問我,到底設計顧問這工作在幹嘛呢?

之前需求訪談的時候,他會說資訊廠商那邊的設計師小妹是「美工」,雖然這對業界設計師來說是個踩雷的用語,但我意識到這只是他的詞彙認知問題。

畢竟我們接觸以來,從線上跟他需求訪談、討論網站策略、提出研究計畫、以及陪伴他進行設計工作坊的過程,他好像沒看過我們做過任何「美工」的事情。

很顯然,當他問我「設計顧問是做什麼?」的時候,已經沒把我們當做「做個畫面來看看」的職業了。

「我們換成實體的產業來比喻吧」我想了一下。

「假設你今天開店,而且是希望做稍微有點服務規模的事情,不是一個人擺攤做生意而已,這個時候就會開始遇到很多問題要處理。」

「例如會需要有服務人員、會需要整理店面的佈置、會需要幫忙點餐結帳的POS之類的,對吧?」

「嗯嗯。」

「另外,有些老闆是有想法跟資金,但不知道做出整套來的方式,有些老闆是有技術但不知道該怎麼處理技術以外的事情,然後,一間店的規模跟十間店的規模,複雜度也會完全不一樣。」

「這個時候,我們設計顧問這樣的角色,就會去跟老闆聊聊他想怎麼做生意,然後提供他整個店如何運作的規劃藍圖。」

「喔~所以像是開店顧問這樣的角色嗎?」

「對對,你要這樣理解也可以,但因為我專注在網路軟體,所以我們協助客戶的方式,就是幫忙規劃客戶的生意如果想透過網路來實現,可以怎麼做的問題。」

「我懂了,所以你們會幫人家弄電商。」

「呃………….以前會做電商的案子沒錯,不過現在電商很成熟了,我最近幾年服務的客戶都蠻有趣的,像是教育的數位科技轉型,或是區塊鏈之類的,這些都是還有很多有趣題目可以做,一直在變化的領域。」

「所以你們要寫程式囉?」

「也不是。」

🤪我到底有沒有講清楚啊。

訂閱 Soking 舉辦的 UX 教學活動:

如果你希望獲得 Soking 的課程以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

查看獸群之心的UX文章目錄

獸群之心 / Soking

獸群之心 / Soking

經營軟體設計顧問公司,也從事 UX 教學,喜歡以工作坊形式,引導學員體驗 UX 領域的專業知識。 工作聯絡:ask@soking.cc