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

設計交付

資訊架構

UX 寫作 (UX Writing)

工作想法

用戶訪談

讀書筆記

工作坊

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文章目錄

商業思維同學的提問

請問Wire frame一般來說都是由產品經理產出嗎?我們公司都是UX/UI一起搞定。

或是說不由產品經理產出會有什麼問題嗎?

我的回答

哈囉,每間公司對於職責分工的期待都不一樣,所以你的問題沒辦法獲得通用回答。

我過去在新創公司擔任產品經理的經驗,以及這些年與不同領域的產品經理交流,的確沒有找到什麼明確的規律,很看公司目前發展階段以及人力現況。

我先說說如果是 PM 負責產出wireframe的優缺點:

優點是,PM 通常是彙整需求變動的人,因此可以將 wireframe 作為目前規格的共識文件,只要有良好的線上發佈習慣以及搭配編碼原則,團隊夥伴只要經過一開始的共識講解,後面在開發過程就不需要一直跑回來問 PM 某些狀況怎麼辦、去哪邊找人問之類的問題

缺點也很明顯,主要有兩個原因,一來是 PM 的時間通常是團隊生產力瓶頸,二來不是每個 PM 都對於互動設計有所涉獵。

先談談第一個狀況吧,PM 的時間通常是團隊生產力瓶頸

我過去在擔任 PM 時,經常一整天有開不完的會議,要跟各色各樣的利害關係人以及合作單位溝通,協調共識。

通常有時間坐下來好好寫文件的時候,多半已經是夜深人靜的晚上。

但其實這個時間,經過一整天的認知消耗,注意力已經是匱乏狀態,不容易維持高度專注以及動用系統二的邏輯腦來進行深度思考。

也就是說,這樣狀態寫的規格文件,有大概率充滿了漏洞。

然後當犧牲了休息時間的 PM 辛辛苦苦把這樣的文件好不容易擠出來,提供給團隊夥伴之後,又因為漏洞擺出的規格描述,被團隊夥伴砲轟以及降低專業信任感。

瞧,這邊就是負面循環以及衝突的癥結點。

辛苦熬夜的 PM 沒有得到正回饋,反倒是讓網路上增添更多吐槽的文章。

第二個狀況是,不是每個 PM 都對於互動設計有所涉獵。

到了 wireframe 階段,這是資訊架構設計重要的格局規劃以及互動引導的規格文件。

有些 PM 是技術背景出身、有些是行銷出身等等,對於人類需要什麼程度的訊息量,用以完成目標的互動設計以及 UX 體驗,認知程度不一。

常見的產品領域,或許還可以上網找一些通用的模版來當範本改看看,但更常見的狀況是變成拼裝車,找了四五種不同領域產品的模版來參考,各取一點看起來像是我要的東西放上去。

這個狀況到了工程師以及後面接手的設計師手上,看起來就會像是噁心的大雜匯,因為無法辨識哪些元素是真正的想法,哪些元素是抄過來用的時候沒有拿掉的。

更糟糕的情況是,我們會愛上自己付出心力的東西,這份 wireframe 再怎麼醜,也是我辛辛苦苦熬夜的呀,怎麼你們都不認同我?

這些慘劇我也遇過,也看過許多 PM 朋友踩過坑。

但坦白說,這不是誰的錯,而是沒有正確識別每個角色的能力範疇以及團隊應該如何互相支援。

我會定義為,這是團隊人力資源沒有協調好的問題,才發生了某項工作雖然知道有人該處理,但是卻將壓力放在脆弱的環節上。

不過話又說回來,我也因此遇到很多心靈充滿創傷的 PM,一下子嚷嚷著要去寫程式(被工程師嗆),一下子嚷嚷著要多學一點設計(被設計師嫌棄)。

這也是這份職業為難以及充滿矛盾的地方,我們似乎什麼都要會,但又似乎不應該插手團隊夥伴的專業,但如果我們真的不會,又要怎麼 review 成果以及提出足夠品質的要求呢?

這就是 PM 的修煉了。

以上分享給你。

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

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

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

資訊架構講座主題:新的需求討論工具, iA 速寫討論法

七月份的時候終於初次舉辦了資訊架構講座,寫下這篇文章作為感想紀念。

身為乙方設計公司最大的困擾在於需求變動

這幾年我一直在琢磨去發展資訊架構相關的需求討論技巧,起因是我們身為 UX 設計的乙方,設計師也只有小貓兩三隻,並且接案生活最麻煩的地方就在於會有淡旺季。

閒的時候,某一年我們還通通放暑假,把案子集中趕完之後,大家各自出國玩一個月把工作室整個空窗。

忙的時候,有一次我們同時跑九個專案,每個案子的進度不一,產業別以及規模也不一樣。

接案過的人都知道,很多時候專案估時是個假議題,因為我們永遠只能算清楚「自己做」要花多少時間,而接案其實是甲乙方的兩人三腳遊戲,你不能只顧著自己快速前進,要客戶的認知也跟上才行。

講白話來說,設計其實可以做得很快,但再怎麼快的快手,也怕改。

但其實資深的設計師通常都會有備案,保留修改的彈性,所以怕的不是改,而是大家都摸不清楚為什麼而改,或者什麼樣的程度修改是合理的?現在討論的修改影響幅度有多大?

資深的產品開發者可以用經驗去估算這些影響以及預見可能的問題,但就像前面說的,接案其實是甲乙方的兩人三腳遊戲,要客戶的認知也跟上才行。

所以我們不能憑直覺就告訴客戶:「這樣修改有問題。」

客戶只會認為你在擋他需求,造成雙方的利益不一致,落入了尷尬的對抗局面。

其實沒有人是笨蛋,當然知道修改會造成風險,但是做出錯誤的東西沒辦法達成目的,許多人是無法背負這樣的責任的。

那麼,我們該如何站在客戶(需求方)的立場,幫助他們一起辨別哪些修改是合理有彈性的?哪些修改會產生大範圍的變動呢?

我們需要新的資訊架構討論工具

上述的原因,就是這次講座中,我們提出新的 iA 討論工具的緣由。

我們稱之為「iA 速寫討論法」,這個方法承先啟後,介於 UserFlow 之後,Sitemap 之前。

主要的訴求是透過具體情境討論,辨識出為了實現這個流程的用戶目標,系統應該準備哪些功能機制,以及這些功能機制背後的內容欄位需求、組合規則是什麼。

透過這個討論法,設計師不需要在聽完需求之後,去觀落陰生出畫面來,工程師也不用等 wireframe 都畫完了,才來一個畫面一個畫面的拼湊整體資料需求,回頭冥想系統架構。

簡單來說,就是紮實的走穩每一步,盡可能讓需求在推進過程越來越清晰。

身為接案方的產品設計公司,這些年經歷各種產業別的產品開發案,我們也經常要跟陌生的工程師們合作。

陌生的產業、初次合作的客戶、第一次認識的工程團隊,這些都是軟體開發上的風險因素。

這個時候,好的設計流程,就是為了幫大家認知對齊,降低溝通的風險。

能夠把這個流程整理出來,跟業界朋友分享,對我來說已經是快成為心魔一樣的怨念了。

結語

大概從兩年前開始我就在思考著,該怎麼把這個工作流程變成明確的框架呢?一面想著這樣的目標,每次我在新專案中,就忍不住進行各種嘗試,希望抓出一個我自己能說得清楚的模式,而不是憑經驗與直覺來討論。

其實在七月初我決定辦這場講座時,心理也還在發慌,因為我還沒有找到適合的角度來說明這個討論法的架構。

最近我跟一位前輩聊到,他問我:「你用這個做了什麼事情,讓客戶滿意,願意買單?」

一開始我被這句話問傻了,直覺的回答:「經過資訊架構設計的流程,工程師能夠獲得更有品質的設計交付,降低專案的風險。」

前輩不耐煩的揮揮手:「你講的是魔術,更具體一點,所以你到底做了什麼事情?」

我支支吾吾的嘗試幾次之後,終於找到了一個說法勉強讓前輩點頭:「資訊架構設計這個流程,會清楚的規劃一個功能需要的欄位以及內容,並且說明這些欄位資訊,運用在整個產品中的組合規則,這樣一來工程師就可以清楚的認知到商業需求是怎麼落地變成設計稿。」

重新整理一次:

說明產品功能需要的「欄位資訊」以及「組合規則」,工程師才能明白商業需求如何落地變成設計稿。

舉個栗子,假設有一個課程網站,行銷想規劃新版位來推薦單一老師的多個課程,結果發現系統其實沒有老師資料。因為每次都是直接在後台的課程內容填寫老師名字與照片,而且同一個老師在不同課程的名稱還會寫不一樣。

這就是內容資料沒有結構化,所以無法重複組合運用。
行銷同事當然搞不懂,為什麼這麼簡單的功能也做不出來?

像這類軟體產品開發上的鬼故事,或許你也見過。

為什麼是你來做資訊架構設計?

直覺上,我們會認為這是當初需求沒有談好,所以最後用了不恰當的作法。其實,這些情況絕大多數都可以避免,只是許多時候,需求方不知道要提供什麼樣的資訊,才能夠講清楚情境,讓工程師可以幫忙考慮更多。

「這些事情不就是工程師要做的系統分析嗎?我們又不是 SA,不懂資料庫結構,怎麼可能完成這個工作呢?」我知道你有這樣的疑問,過去我擔任 PM 的時候也困惑過這件事情。

理由其實也很簡單,因為 PM 是負責「確認需求情境」的人,整個系統要服務哪些情境?什麼邊緣案例要考慮、不考慮?這是 PM 有義務要提供判斷的範圍。

PM 當然沒辦法跳下去開資料庫欄位,可是 PM 至少要負責解釋清楚「什麼情境下會怎麼使用系統功能」,資訊架構設計就負責帶路到這邊為止,將使用情境轉化為「在這個情況下使用某個功能,用戶或營運需要某些欄位資訊,好用來判斷與管理某些事情」。

「可是設計師不會寫程式也不會資料庫,為什麼要負責資訊架構設計嗎?這聽起來就是技術工作?」

其實設計師反而是更需要參與資訊架構設計的人

相信許多設計師都遇過這樣的情況,今天需求方跟你說要弄一個新的東西,可是只講了模糊的方向,要你先弄出一版畫面來討論。

結果你觀落陰半天好不容易東拼西湊,到了會議室之後,需求方覺得這裡不對、那裡不行。

工程師也面有難色的質疑這邊不合裡、挑剔那邊看不懂,還逼問你這些東西確定嗎?

你馬上就頭腦爆炸,因為整個東西都是需求不明確的情況下趕出來的,最好能夠確定啦?你內心的委屈馬上轉為憤怒,想痛罵需求方只提概念沒有明確的規劃,想跟工程師抗辯自己又不懂資料庫,怎麼會知道系統有沒有什麼資訊。

這就是設計流程上少了很多「確定性」的步驟,直接將所有人拉進會議室討論需求還未定案的設計的經典災難情況。

其實身為設計師的你,需要的是用不同的設計工具來處理「不同程度溝通需求」的利害關係人。

資訊架構設計的流程,就是協助身為設計師的你,將需求與構想能按部就班的從起飛到落地。

我們要在這個設計過程將需求拆解到最小的欄位資訊,直觀上就像用樂高積木組合出整個城市(程式),但最小的樂高零件你依然可以清楚的發現有其固定的形式結構。

一般來說,在需求不確定性高的時候,先用 Prototype 與需求方討論情境,以及測試解決方案的概念是不是能被需求方買單。

接著在資訊架構設計的流程中,產品的設計師要去識別商業模式的內在結構、用戶的認知意圖與觸發行動、思考內容取用的規則、設計資訊內容在不同的地方出現的形式、並且劃分內容的層級以及在介面上的路徑引導,最後才會看到我們熟知的 Wireframe 等資訊架構文件。

當你透過 Prototype 與需求方確認了使用情境,並規劃出合宜的結構化內容以及跟工程師確認內容取用與組合的規則,其實前台的介面互動流程能夠實現什麼範圍,工程師心理也有數了,需求討論的會議上,你就多了一個支持你設計構想的夥伴。

這就是透過資訊架構設計流程,需求可以逐漸被收斂,並得以實現的過程。

這些過程也是我從事軟體產品設計十多年來,磕磕絆絆許多次,從無數與工程師合作的摩擦與衝突之後,逐漸理解的事情。

結語

在需求、設計構想以及工程師需要的設計交付之間,過去存在巨大的鴻溝,因為需求方以及設計師都欠缺一個溝通的工具,好好的把需求變成技術開發上可以評估如何實踐的內容。

如果你在工作上也遇到類似的難題與困境,想學習資訊架構設計的方式,請留下你的 Email 聯絡方式,我會跟你分享相關的開課訊息,以及我們在產品設計與 UX 工作上的心得。

也歡迎將這個訊息分享給你認為需要的朋友 🙌

訂閱開課訊息:https://prodigious-builder-6290.ck.page/d2c732f947

商業思維同學的提問:

想問老師:除了B2C企業外,B2B是否也可以依照相同的方法建立Persona?謝謝~

我的回答:

哈囉,感謝同學的提問。

B2B 產品當然也需要 Persona,某方面來說 B2B 的 Persona 更容易具體化明確的用戶輪廓,因為用戶端企業所處的產業以及規模通常也會直接影響他的行為模式,變因相對於大眾市場 C 端更少,只是一般來說困難點在於利害關係人的決策結構,所以不能只看使用情境。

相對的,B2B 的 Persona 更重視明確的效益,以及使用上會不會造成其他問題的疑慮,這些都是阻止他們行動的原因。

幫 B2B 產品做 Persona 常見的情況是,大B、小B 以及不同產業的 B,莫非我每個區隔都要做一次嗎?

這就要回到目前產品最重要的策略是什麼了?

如果每個用戶區隔都很重要,那就等於分散了力道,每個用戶區隔都無法顧好。

也就是在亂槍打鳥的討論產品策略。

舉個例子,我們過去有個跨國教育平台的產品設計顧問案,客戶一開始就想說做亞洲十七個國家,問他們為什麼?

理由是公司在亞洲有十七個分公司,所以理所當然用這個當做目標。

可是韓國日本的市場需求,跟越南泰國不會一樣吧?

所以我們換個方向問,請客戶回答:「如果第一波要推動營運試點,資源最豐富的地方是哪邊呢?預計哪個市場的難度最低?」

經過幾番討論,客戶發現可以先從掌握度最高的市場開始嘗試新產品,然後再切分成幾個階段性去推廣到別的市場。

解除了客戶的這個產品策略上的疑慮,我們一開始鎖定東南亞的一兩個經濟成長高速的國家作為用戶研究對象,列出當地的教育資源以及 B2B 市場的競品研究。

並在這個基礎上提出 Persona,跟客戶討論「因為這個商業邏輯,所以我們的新產品這樣切入市場,來服務這群需求沒有被滿足的客戶」

同學可以發現,如果你能夠運用在商業思維所學到的思考模式,幫企業進行整體的策略考量,Persona 只是你最後用來說明情境的小工具。

關鍵還是在於你有沒有順著客戶的疑慮,在正確的問題點上溝通。

以上提供參考

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

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

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

商業思維同學的提問:

顧問公司到客戶公司訪談,如果受訪者覺得過去公司就是這樣,這個訪談或這次的優化專案,對事情不會有幫助怎麼辦?

我的回答:

哈囉,感謝同學的提問。

首先可以檢視一下「利害關係人圖」的分佈,容易的、高影響力先攻略。

高影響力的利害關係人應該優先處理

我舉個例子,去年我們有一個顧問案也遇到同學提到的狀況,有些我們預計要訪談的工程師就是處於「這樣對事情不會有幫助」的心態

記得我們在前面的課程有談過「需求與利害關係人」嗎?其實這就是「不想改變的利害關係人」類型。

記得我們討論過如何處理嗎?就是要創造新的期待。

商業思維同學的提問:

我一直對內容規範、設計表單驗證感到困惑,內容規範是為了防止 Garbage In、避免不好的情況等等。

可是要規範到什麼程度?哪個欄位必填,欄位要防呆到什麼程度?

規範太嚴,又怕日後有很多例外狀況,也擔心增加使用者的負擔。我目前都是採取,不能讓系統無法運作、不能讓用戶不滿為原則。

老師有什麼心得、原則、指引可以分享的嗎?

我的回答:

哈囉,感謝同學的提問。

我們可以分為幾個觀點來討論這個問題,例如用戶動機、商業目的、系統目的。

我先舉個反例,令人討厭的註冊表單長什麼樣子呢?就是要求你填寫長達十幾個選項才能送出的表格。

但如果我換了個情境,跟你說這是「結婚登記申請的線上表單」,填寫十幾個選項你會一樣不耐煩嗎?(雖然還是很麻煩)

在法格行為設計(Fogg Behavior Model)公式中有討論到,用戶是否產生行為的幾個關鍵要素:

B = MAT

意即當動機(M)、能力(A)、觸發(T)三者同時齊備,才會產生行為(Behavior)。

當我們順著用戶的動機,配合(或降低門檻)用戶的認知能力,在正確的時機要求用戶產生行動(CTA),行為就會誕生。

例如某個網站無緣無故跟你要住家地址,你會覺得被冒犯,但前提若是你要查詢從國外寄送商品到你家的運費試算,要地址的行為就是順著用戶的動機了。

再談商業目的,很多表單過於冗長,是因為除了用戶動機、系統目的之外,含參雜了太多「額外的商業目的」

例如希望用戶多填寫個人興趣,這樣之後才能發送廣告訊息,很顯然這對於用戶來說沒有感知到好處,純粹在蓐羊毛。

但你可能也看過,有些新的服務會在用戶初次登入的過程,不只是詢問你對什麼類型的主題感興趣,還推薦你豐富的內容可以逛逛,這樣就將商業目的與用戶動機對齊了,雙方各取所需。

至於系統目的這次先不多談,系統是為了實現前面兩個目的而存在的,才能產生價值。

許多時候這是多方平衡出來的結果,但這就是我們身為產品設計者的價值所在,不是嗎?

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

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

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

Hahow 同學的提問

老師您好:

目前在一間打算開發ERP系統的公司擔任UIUX設計師,在做前期研究的時候,需要做出各行各業(比如_製造業_的_會計)的persona,請問老師在沒有實際用戶訪談的資源下,有沒有甚麼替代的方式或資源能站在他們角度製作?(目前基本上以辜狗為主….)

我的回答

哈囉,感謝同學的提問

給你幾個建議,分別是「從內部尋找資源」、「尋找專家」以及「現在開始培養用戶研究資源」。

首先談談「#從內部尋找資源」,一般來說 ERP 系統的銷售會有負責攻略產業的商務開發或業務單位,這些部門的同事就是未來要負責將產品介紹給客戶的第一線。

相信他們對於各個產業的用戶或許已經有想像了,建議你從內部同事的訪談開始,去跟他們聊聊平常去拜訪客戶的過程會遇到哪些角色?這些角色對於我們的產品有什麼期待?客戶那邊的不同角色可能用我們的產品來完成哪些任務?不同規模客戶內的相同角色,他們的期待有什麼不同?等等

透過同事對於客戶端的理解,至少你可以建立一個內部共識的 Persona 版本。

第二個建議是「尋找專家」,或許你可以去找找外面有開課或者寫文章分享的專家,去認識他們或者去參與一些他們會出沒的課程或活動(例如 clubhouse ?),跟這些專家聊聊你感興趣的產業內的角色,可能會拿 ERP 來幹嘛?這些角色的目標與痛點常常是什麼?

你可能會覺得,這不就是自己去發展人脈關係嗎?

是的,用戶研究資源本來就不會憑空產生,尤其是在 UX 文化較缺乏的環境下,大家不會有意識到產品設計的團隊需要研究資源(包括人脈、名單、時間等等)

這就衍生第三個建議,「#現在開始培養用戶研究資源」

其實「沒有用戶研究資源」是假議題,我們應該重新定義一下這個情況背後的本質問題,其實是「#不知道原來需要用戶研究資源」。

我換個概念舉例,公司招募員工進來,通常會預期要準備位子、準備電腦、準備帳號權限,為什麼會知道要準備呢?因為這件事情有慣例,別的公司也都這樣做,而且不處理的話會發生一些麻煩事。

同樣的,大多數的產品開發團隊,都沒有用戶研究的經驗,所以從來沒有預期要建立資源(包括名單、預算、時間等等)

但如果一樣的事情換成「行銷或業務」單位,是不是又覺得合理?

行銷或業務需要找目標客群聊聊?合理。
設計師需要找目標客群聊聊?你想幹嘛?

所以至少,你要先從跟最接近研究資源的同事多互動,甚至跟他們共享你需要的資源開始,然後把每次你做了一些研究成果,試著用來幫助同事讓他的工作更順利或有成績。

這樣一來,大家才會開始意識到,原來讓產品設計的同事多多了解客戶需求以及情境,可以產生這麼多以前不知道的好處。

你所需要的資源才有機會誕生。
以上提供參考。

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

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

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

獸群之心 / Soking

產品設計師以及 UX 教育講師。Hahow線上課:https://hahow.in/cr/think-with-ux , 工作聯絡:charm.soking@gmail.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store