自 1995 年艾碼科技成立以來,經歷了三次重要的公司合併,最終形成了今日的鼎華智能。這些變化為公司的產品、組織和市場結構帶來了極大的複雜性。過去,我們的產品專注於半導體製造業,主要針對單一系統的廠內應用,目標較為單一。隨著業務的擴展和多元化,我們的產品和服務迅速增長,涵蓋了更多的製造業領域。
為了應對組織結構和市場需求的變化,我們意識到作為大型 B2B 系統服務商,不僅需要提供所需的功能,更重要的是能夠聚焦在使用者上,已快速適應和滿足不同的需求。為此,公司投入了超過兩年的資源,由UCD 部門進行了深入的內部和外部流程分析,重點解決存在已久且能快速產生效益的問題。
我們的目標是:「如何準確的找出使用者需求並滿足,以及提升跨部門合作的工作效率?」在這過程中,我們專注在三個主力產品和四個製造行業,致力於提供更便捷且醒目的使用體驗。
在分析鼎華的主力產品和戰略行業時,我們發現相同的產品在不同產業中的使用者需求和體驗有顯著差異。因此,在產品迭代過程中,精確掌握使用者需求至關重要。使用者模型(Persona)在此扮演著關鍵角色。我們期望使用者模型能協助團隊減少主觀猜測,增強數據支撐的決策,深入理解使用者的真正需求,從而提供更好的服務。
專案期間
Feb 2022 - Apr 2023
擔任角色
Service Designer
負責項目
Co-creation Workshop
Role Definition
Product Function Definition Product Design
Co-editor
團隊目標
透過使用者模型,於產品開發的不同階段,將相關 Stakeholder 聚焦在使用者動機和行為上。初期減少溝通成本,中期能夠聚焦並深化使用者場景,後期減少重工成本並領先行業需求。
角色與產出
我擔任一位整合設計師,將搜集的資料整合,其中包和產品經理、售前、顧問和使用者的反饋,並將其使用者模型設計出來後,推導於每一項專案中,作為議題的切入點。
專案挑戰
使用者遍及不同國家和行業,當聚焦在 5W1H 分析時,經常遇到映射和聚類的困難,我們必須找出共性且符合業務需求,以實現 B 端 使用者模型價值。
成果與影響
產品單負責產品符合營銷單位需求,達到重工次數減少 20% ,二開機會減少 30%,並逐年增加。溝通成本的減少,會議時間縮短 50%,使聚焦更快速。
01
前置作業
專案輪廓
鼎華於 1995 年成立,由三家公司合併,聚焦在製造業發展,透過 8 個大型系統實現 MOM智能方案,企圖以軟件服務成為工業 4.0 的領頭羊。UCD(User Center Design)部門在公司的策略下,負責提升公司產品的行業體驗,而在這 1 到 N 的階段,快速實現設計並且滿足客戶需求變成我們這次的課題。如何減少溝通成本進而深化客戶場景,我想與您分享在鼎華是如何透過 Persona 將複雜的合作流程簡化,減少「我認為」的設計。
影響客戶
413 家
206
場內部會議
設計部門同仁參與內部會議,了解每個會議目標和部門利弊,並找出痛點。
51
位使用者訪談(內部)
我們結合兩岸的使用者,透過線上、線下訪談,了解會議目標和預期結果。
37
位使用者訪談(外部)
將我們內部預期的使用者與實際客戶內部使用者做對焦,清楚知道戰略市場的使用者及其痛點。
12
個使用者模型產出
根據 2023 年戰略規劃及接下來2年的市場,我們規劃出 12 個使用者模型。
設計團隊花了一年梳理會議中的成本及痛點,將內部同仁作為使用者,透過研究釐清現況,平衡溝通成本與使用者需求,讓團隊理解模型價值並延伸至客戶體驗優化。同時,考量產品設計、商業策略和區域溝通,建構了一套易於理解和修正的Persona,幫助團隊在溝通和決策中更快聚焦和覆盤。
現存問題
合作無法達成共識
公司業務跨足中國、台灣和東南亞等地區,溝通通常需要依賴線上會議。然而,不同國家的文化習慣各異,不同製造行業的使用者場景差異顯著。除了外在因素的影響,內部同仁對使用者輪廓缺乏統一的理解,對腦中的使用者形象認知不一,再加上彼此業務不熟悉,經常導致溝通上的困難和誤解。
產品開發優先權不明確
作為 2B 的系統服務商,產品單位的目標在於實現使用者需求,為產品的實際使用者提供價值,使用者的接受度越高。但從業務單位的角度出發,往往會認為只有在決策鏈上的使用者,才是具有價值的關鍵角色。這也導致開發優先權始終無人拍板。
重工多,客製多,納標少
B2B 市場競爭激烈,且客戶需求多樣且複雜。前線人員經常在需求不明確的情況下為了獲得訂單而向客戶做出承諾,這導致設計錯誤、需求變更及產品不符合用戶需求等問題。結果,公司在投入大量資源後,才發現產品並不符合市場需求,陷入了資源浪費和反覆修改的負向循環。
我們的目標
完整內部流程,確保資源分配和開發順序,以符合公司戰略目標和市場需求
假設
假設一
精準地掌握複雜的廠內使用者,可以幫助內部加速決策推導。
映射困難
會議人數眾多,每位成員面對不同客戶,收到的使用者反饋各異,導致對客戶需求的解讀不一致,最終在決策階段無法達成共識,導致會議無法形成明確結論。
聚類困難
訪談的使用者越多,越難找出共性,若無法有效地體現大盤情況,無法獲得業務方支持,而資料便成為閉門造車無法使用的工具。
假設二
快速調整使用者的基礎和獨有特徵,可以貼合不同國家、行業的場景需求。
文化習慣
由於鼎華市場遍及亞洲各地,我們發現將製造行業細分後,使用者環境極為複雜,其基礎特徵和獨有特徵都有些許不同。因此討論過程中需快速聚焦使用者的共性和差異性,以確保溝通成本降低且滿足市場需求。
02
專案設計
專案目標
以使用者模型(Persona)貫穿產品投入的每一個階段
設計團隊投入了一年的時間,參與超過 200 場的會議,會議參與者包含產品經理、顧問、業務、開發和設計師,並從中觀察到在產品相關的會議中,有 5 個重要階段經常出現爭議,導致上面所敘述的問題經常浮現,以下是我們整理出來的內容:
我們將產品開發階段展開,透過使用者模型幫助團隊進行對焦,避免階級化或自我參照設計(Self-referential design)影響產品開發和會議進行,若是內部產出環節出現問題或發散,我們期望使用者模型可以調動團隊的共情能力,將大家焦點拉回使用者和戰略目標,幫助團隊更直觀的理解使用者。

鼎華在 2019 年成立 UCD 部門,在這 0-1 的階段,優先讓團隊設計師明確所服務的對象尤為重要,也就是我們核心價值「我們服務的是一群什麼樣的人」。而 B端 相較於 C端 不同的地方,那就是信息收集和準備工作不單是服務對象的背景,更重要的是服務使用者的業務範疇。
作為學習工具
Goal
無論設計部門或其他合作部門,在培訓方面的成本都相當高,且效果不彰,若無法實際進廠了解,新進員工無法快速掌握 Knowhow ;其次,鼎華 85 % 的市場皆來自於中國地區,台灣 IT 團隊能否開發貼近當地文化之體驗,設計和開發團隊的同理心尤關重要!
作為設計工具
Goal
為整合不同產品至不同行業場景,設計師必須了解整個製造業的環境,我們期望 Junior 或 Senior 設計師皆能夠抓取使用者模型(Persona)上的資訊,進行快速討論並擬定可行性設計 。藉由使用者模型(Persona)來確立使用者目標和任務,奠定設計的基礎。
作為溝通工具
Object
在 B2B 行業當中,設計的「成果」會影響著內部夥伴之間的利害關係,以鼎華為例,設計影響著 IT、Sales、Marketing 和 Consultant 等部門,透過使用者模型(Persona)作為討論的共同語言,幫助大家在意見上達成共識和承諾,除了可以減少闡釋時間和專注使用者細微的背景差異,還能避免重工成本,助力於市場營銷規劃。
建置流程
Step 1
確立目標與維度
以公司四個主力產品進行分析,觀察使用者的目標、行為和觀點。
Step 2
信息搜集與假設
進行內部訪談和客服調研,將輪廓進行,再進行問卷搜集,最後實際安排進場調研。
Step 3
信息求證
與各單位代表合作,將行為變量和痛點進行映射,將相同角色的共性、差異化進行還原。
Step 4
分析建模
將使用者的期望、環境和產品之間的關聯組建成視覺化的溝通工具。
確立目標與維度
工業 4.0 目標是透過設備互聯、自動化和智能管理,提升效率、降低成本、增強靈活性和改善質量。在這基礎上,鼎華以智能製造運營管理(MOM,Manufacturing Operations Management)爲藍圖,研發數個系統支撐客戶達到工業4.0的目標,其中MES、ERP、APS 和 QMS 為最主要的四個系統,也是我們鎖定在這一階段擬定的維度。
在專案的前期,我們與前線夥伴進行緊密討論,從產品和市場的維度討論符合條件的使,最終我們依照職能做劃分,以下是我們這次討論中所學習到的事情:
系統很複雜,但使用者要的「非常」簡單
系統多角色評估
我們將四個系統展開,評估至少有12個角色同時使用系統,在不同場景和裝置下,效率和問題解決是共同的核心目標。
2B 產品的使用者模型
比起 2C 產品關注使用者的年齡、愛好和習慣,2B產品更注重使用者的工作能力和內容,當聚焦在系統服務商的業務時,模型要素構成更清楚的圍繞在工作目標管理。
產品價值與決策關鍵
在 B2B 市場,產品的目的是為了給實際使用者提供價值。使用者接受度越高,整體服務質量和未來續購機會就越好,但整個業務流程中存在著多個關鍵「決策」角色。
最後我們也針對鼎華的業務為目標,根據調研對象梳理出使用者模型的維度:
信息搜集與假設
確定了大致方向後,團隊首先進行靜態的調研,主要是為了對業務和市場進行初步理解,對於後續在於使用者進行訪談和深入個案時,能夠保持過程順暢,並營造專業感。
由於我們想要做出一個實際能夠幫助團隊溝通提效且討論出來的方案能夠與使用者產生共鳴,於是我們調查完後,在邀請各部門進行訪談前,團隊透過問卷的方式,了解客戶、顧問、業務和產品中心等單位對使用者的整體狀況。
以下是我們發送問卷的內容:(問卷範圍涉及多個國家,因此我們透過騰訊問卷進行調研)
為了加深我們對使用者的理解,我們邀請使用者(包含外部實際系統使用者37人與合作部門51人)做訪談。在訪談完成後,我們聯繫了 7家客戶進行個案拜訪,希望能獲得新的洞見。
為什麼我們安排這樣的調研對象和順序?
設計團隊參加了超過 200 場的內部會議,發現大概有 70% 左右的會議忽略了使用者的需求,而是建立在業務上,其中又有 68% 的會議無人願意承擔責任,因此,我們相信工具的使用只是溝通提效的方法之一,真正有效的方式往往建立在彼此的信任程度上。
信息搜集與假設
調研結束後,我們將蒐集到的資料進行共同化與差異性化分類,將11 個角色進行還原。我們觀察使用者的日常使用場景、3C 使用熟悉度和自主學習能力等等,推測出使用者對產品的使用程度和使用成本。
我們透過調查、問卷、訪談和深入個案後,搜集的資料相對深入,團隊在這一階段對於我們服務的對象也有近一步的認識。但隨著資料量的增加,廣度也隨之增加,使我們再提煉共同點時非常困難,於是我們再次邀請不同的 BU 進行焦點會議,首先與大家介紹目前的內容,接著提出過去經常聚焦的行為變量與使用者場景,最後才針對未來發展進行補充。
我們知道不同區域和行業下的同一使用者痛點、共性和需求肯定不只上述,所以我們會在設計的時候,確保 Persona 是能夠往下細化或擴充,根據產品的特點、業務、定位進行資訊的補足。
設計原則
經過上面的步驟,接著我們需要將資料轉成可用的資訊,並以圖像化的方式呈現已達到我們目標,以下是我們的設計原則:
資訊易得(廣度)
即使我們透過不同的調研方式挖掘車間人員的背景,從不同課題和解決方案,我們掌握了深度,但由於跨國家及行業的因素,單一角色的廣度有不同,我們需持續討論和進行對焦。至少在設計上,我們能確保雙方具有即時的資訊訪問,讓討論更具體和針對性。
清楚的(結構)
團隊希望人物誌的結構能夠幫助大家快速找到所需的具體內容,因此除了視覺的感受度要提升外,文字敘述也要簡潔扼要,符合不同文化上的用語。另外,我們除了將關鍵特徵列出以外,仍保留一些過去大家經常討論的次要特徵。
調整彈性(時間)
每場會議所討論的內容都不一相同,我們想要幫助團隊在獲得新數據或需求時,能夠迅速更新和調整資訊,保持資料的即時性和準確,幫助合作時能夠形成協同效應。
設計產出
這是我們首次產出的使用者模型(Persona)內容以及後續聚焦目標:
更快找到討論的使用者
我們目標是以使用者模型(Persona)貫穿產品投入的每一個階段,作為加速會議效率的工具,我們想要讓每一個參與會議的人在有需要的時候可以快速找到相應的使用者,我們從調研的資料所知,單一產品對應數個使用者,因此我們以顏色將使用者分門別類。
生產物料控制人員
生產控制人員
物料控制人員(物控)
車間主任
班組長
生產調度員
維修工程師
設備工程師
出貨倉管人員
物料倉管人員
質檢人員
生產加工人員
將觀點和工作事實區分
我們從過去參與參加的內部會議中總結發現,無論是哪個部門在探討使用者時,經常將觀點和工作事項作為論點,以利說明產品發展方向,觀點經常是在前線人員面對客戶時所得到的資訊,而工作事項則經常對焦在系統功能的方向和完整度,由後勤單位提出較多。
調研的過程中,我們搜集到非常多的資訊,來自不同的國家、行業和規模,因此,這次設計我們直接將許多資訊的架構分成兩個面向(觀點和工作事實),讓團隊在溝通的過程當中能夠快速對應到正確的方向。
將議題的優先序對焦在使用者痛點
車間內,每一個角色在乎的產品體驗不盡相同,尤其在 2B 的商業模式中,我們發現具備決定權的老闆或高階主管,會優先注意視覺上的吸引度,以及功能是否滿足;而後勤人員則「通常」會在意操作上的直觀性和順暢度,雖說是如此,往往因為公司已經購買了,後勤人員雖有抱怨也只能硬著頭皮使用。
因為後勤人員只能「將就」,就不需要知道他們體驗的痛點嗎?其實未必,他們的聲音影響著公司是否續購或購買其他產品,也影響著顧問職能在進行輔導時的效率。因此我們將訪談後統計出來的結果,根據每個使用者模型(Persona)的痛點列出,其優先權可加速團隊溝通時的判斷和取捨。
我們團隊致力於分析這些來至內、外部的資料,我們將這些資料萃取了最關鍵的資訊,並依照痛點反應頻率進行排序,這能夠有效地幫助團隊進行聚焦,將使用者、產品和商業進行分析。
將產品與工作場景對焦
在 2B 的商業中,功能是客戶的剛性需求,其次才是方案和藍圖,而功能往往對焦在使用者場景,這次的使用者模型幫助了團隊將產品與使用者場景進行對焦,在會議當中,能夠縮小議題範圍,並精準的掌握需求的可行性。
以生產物控人員(PMC)為例,有 60% 的時間都在執行生產計畫排成和物料控制,也代表著優先將資源安排在這一區段的痛點解決,能提升產品競爭力和未來的發展性。
提效的線上、線下會議運用工具
我們的目標是是藉由使用者模型(Persona)將整體內部溝通提效,並試著將議題聚焦在使用者上。為了實現跨區域會議的需求,我們除了將使用者模型(Persona)印出來成卡片,也提供線上支持的工具,幫助團隊更容易運用在會議中。
03
專案成果
驗證模型
我們實現了第一步 - 設計具體的使用者模型(Persona),但我們知道首次設計出的模型不一定考慮完善,因此我們要驗證兩個假設:
假設一
精準地掌握複雜的廠內使用者,可以幫助內部加速決策推導。
假設二
快速調整使用者的基礎和獨有特徵,可以貼合不同國家、行業的場景需求。
首先,我們團隊在每個設計會議時,會優先將這次會議的使用者提出,優先說明他的背景、價值和使用場景,接著提出我們設計方案解決的痛點,最後再次將使用者模型(Persona)展示出,作為大家 QA 時對照的資訊,以下是我們這四個月參加 37 場會議的策略和結果:
起初,滿多團隊懷疑這工具的準確性,但事實上對焦在不同行業和區域時,使用者模型確實很難 100% 相符,我們也在使用初期倡導這件事。經過了 4 個月,我們很高興看到大家會去使用和修改,也讓我們針對半年的調研重新審視,作為第二版發佈的依據。
從公司內部成功擴展至客戶成功
內部成功
一直以來,設計團隊的聲音其實一直處於較弱的部分,這次,我們透過使用者模型成功引導會議順利決議並且效率成長,也在每場會議後修正 User Journey Map。雖然在調研的過程當中,映射非常困難,但也讓設計團隊的成員對不同行業和地區的使用者有更多的認識。
外部成功
無論是產品的發展或是前線人員對客戶的需求都有了更多的理解,我們從被動地聽取意見,成功的主動與客戶創造價值,NPS 分數也從專案實行前 43 提升至 76。對產品的發展也具備更好的策略,讓我們有機會成為市場的領頭羊。
+62 %
+53 %
+15 %
+28 %
-37 %
-12 %
-16 %
-47 %
整體來說,我們發現模型的導入,對內部會議而言能有效幫助團隊聚焦、專案評估、快速決議和目標達成,在整體開發中,也能幫助新進設計師快速了解使用者和場景,並且隨著時間增加,設計時程能有效減少。
在這次專案當中除了發現使用模型能有效改善溝通,且團隊也願意使用模型以外,模型修改率也相對高,證明在貼合不同文化上,使用者模型(Persona)會是內部溝通的敲門磚,但無法滿足所有國家和行業,因此我們會希望加強在變動模型上的效率。

反思與學習
團隊成員在設計這塊道路上,都知道使用者模型的重要性,但實際上能夠達到什麼目標卻是個疑問?在這一年當中,我們試著去打破常規,不再只是將使用者模型(Persona)作為設計發表時的工具,我們非常努力的希望真正的能夠實現它的價值,這也讓每位設計師忙到焦頭爛額,但我們確實得到了非常好的成果。
要解決內部溝通的挑戰有很多方法,這次主要由我提出以使用者模型(Persona)作為這次的突破口,以面試的過程為例,許多設計師會將使用者模型(Persona)提出,但近一步詢問他們為什麼要將模型放在作品集時,大部分的求職者是不知其原因的,更多的是變成作品集中一定要有的內容;其次,在 B2B 的商業模式中,使用者的背景相對複雜,尤其我們商業版圖跨足了中國和東南亞市場,對設計師來說是一大考驗,更現實的是,若設計師對於使用者和行業 Knowhow 不熟悉時,別說內部溝通要提效,經常是沒有人願意浪費時間和設計師溝通。
因此,在執行 DesignOps 的過程中,我們希望能以使用者模型(Persona)達到一些目標,為了達到這些目標,我們需要在很多事情上做取捨,除了用在設計初期的溝通外,我們還可以透過使用者模型(Persona)達到什麼樣的目標?我們要如何讓模型成為學習的工具?我們要如何讓其他團隊願意用這模型?我們要如何讓大家更了解設計師的價值?如果做完了沒有人認同下一步該怎麼做?我相信每個公司的工作模式不同,但我們堅信設計師不只是美編,而是團隊之間彼此相長的好夥伴。
這次透過透過使用者模型(Persona),我們成功解決了一部分內部溝通上的問題,使各部門能更精確地理解客戶需求,進而設計出更貼合市場的產品,除了在交付上更符合預期,整個過程中我們也發現,這樣的方式不僅提升了議題解決的效率,還大幅減少了團隊訓練的時間。由於所有人對產品的理解更加一致,我們的會議流程也因此更加順暢且高效。
我們在專案結束後,復盤整個成功因素,認為大部分原因歸咎在我們不是做完模型後向大家發布並說明使用,而是與不同團隊的成員一同深入瞭解和描繪不同使用者角色,過程當中充分表達以客戶需求為核心的設計有多中要。這樣的過程不但讓團隊之間的信任感增加,彼此的目標一致,對我新進的設計師來說,也能夠快速了解我們製造業的使用者和場景。
最後,團隊成員的成長不僅反映在專案交付的結果上,也反映在跨團隊溝通上,讓彼此間更有方向感,減少了溝通中的摩擦,提升了整體的協作效率。我想,這次DesignOps專案不僅促進了產品設計的進步,也為我們在未來的工作中提供了寶貴的經驗,讓我們能夠在更複雜的項目中游刃有餘。