Web App 2026

刊登收費

Turning a Free Platform into a Paid One

平台從「免費」走向「全面收費」的轉型專案。我的任務,是在「平台要賺錢」與「雇主不想被收費」之間,用設計找到讓營收成長、又不流失用戶的平衡點。

Role
Product Designer
Team
我 + 產品設計師 + PM + 工程 + 客服
Year
2026
Tools
Figma、Miro
刊登收費封面

背景與問題

小雞上工是一個打工、任務與家教的媒合平台,過去企業端刊登職缺完全免費。為了擴大營收,平台決定在2026 下半年正式從免費轉向「全面收費」。這不是一個單一功能的優化,而是一次商業模式的轉型。對設計來說,必須從過往的表現層、框架層或是結構層跳脫出來直接觸及戰略層面的思考。

我的角色與貢獻

在這個專案裡,我的角色貫穿了流程盤點、跨職能溝通到視覺執行三個階段:

角色一

盤點因收費可能產生的使用流程改動

角色二

與其他職能共同討論因收費會出現的各種狀況

角色三

所有因收費需異動的畫面稿件設計

這三個階段裡,投入時間最多是將想法與跨職能的團隊對齊,所以我想針對這部分多做些討論。

把每個人的觀點,即時寫上白板

前期我和工程主管、客服主管、和另一位產品設計師一起開了三次會議,會議的目的是針對可能因收費產生的變動進行討論。第一次會議時我們並沒將會討論內容記錄下來,這樣的結果導致第二次會議時出現進度無法有效銜接以及想法不一致的問題,我們又要從頭討論一次,這樣既費時又容易產生衝突。

後來我堅持任何討論都要留下記錄,這麼做至少有三個好處:

好處 1

寫的當下,就是在梳理自己的思緒。

一步一步推倒的過程也能幫助大家理解你的脈絡。

好處 2

把整個架構視覺化

專案牽涉的面向太廣,白板讓所有人看著同一張圖討論。

好處 3

方便留存

拍照後甚至能丟給 AI 協助整理,再把結論同步給沒能與會的成員。

決策過程

用「多方提案 → 逐步收斂」談清楚複雜規則

收費牽動的規則極多,而且每一條都同時被商業目標、用戶體驗、工程可行性、客服成本四方拉扯。我的做法不是直接出設計,而是先把每個爭議點出發想出多個解決方案並陳,再帶著各職能一起評估、收斂成最終解法。以下是幾個代表性的決策:

決策一:免費與付費誰的優先序更高?

先買先用
優先消耗付費額度
讓用戶自行切換

最終選擇:優先消耗付費額度

「優先消耗付費額度」讓用戶從購買當下就直接感受到付費的價值,也符合「有需求才買付費」的邏輯,同時貼近商業目標。「讓用戶自行切換」雖最彈性,但增加了操作認知負擔,且免費額度一個月只能使用一次,也不符合開發效益。


決策二:是否要開放職缺升級功能?

無法升級
可以升級

最終選擇:無法升級

此次版本的工程資源有限,需優先確保核心付費流程穩定上線。升級功能雖然對雇主有正向效益(不用重新建立職缺即可享用付費功能),但所需的開發複雜度與工時不符合目前優先序,決議先不做、待後續視用戶反饋與時程許可再評估開發。


決策三:付費結束後,聊天室怎麼處理?

鎖住整個聊天室
保留記錄,但禁止發送新訊息
提供聯絡緩衝時間

最終選擇:鎖住整個聊天室

付費結束即整體鎖住,規則單純明確,雇主不會混淆「還能看不能傳」的中間狀態,也讓續費與否的界線清楚對應到功能可用性,最大化續費誘因;工程實作上也最簡單,不需額外處理訊息層級的權限判斷。「保留記錄,但禁止發送新訊息」雖然體驗較平緩,但等於在付費與非付費之間創造出一個模糊地帶,容易讓雇主誤以為服務仍部分有效,反而增加客服解釋成本;「提供聯絡緩衝時間」則削弱了立即續費的必要性,與商業目標相悖,且緩衝期的長短難以拿捏,反而增加規則複雜度。

成果

待補
XX%

付費轉換率
(數據待補,需標註量測方式)

待補
XX%

營收成長 / OKR 達成
(數據待補)

待補
XX

既有用戶流失控制
(證明「平衡」成功)

反思

收穫 1

設計師的價值在於找到商業目標與用戶體驗的平衡點

收費型專案裡,設計不只是介面好不好看,而是願意在強推轉換的壓力下,適時替體驗踩一腳煞車。好的收費設計,不是讓用戶非付不可,而是讓他覺得付得有道理。

收穫 2

免費方案是緩衝,但也可能成為終點

免費體驗降低了轉型抗拒,但長遠可能養出永遠停在免費的用戶。下一步需要從數據區分「用免費當試用」與「只想白嫖」兩種人,再針對前者設計更強的升級引導。