作品分享｜Zuna 租屋評論平台——解決學生租屋的資訊不透明問題

一個點子被孕育的過程

其實我當時只是想做個作品集好讓我找到工程師的工作

時間回到 2021 年，當時我只是個剛上完 Huli 的程式導師計畫課程的學生，正在苦惱於作品集的選題。看著社群上大家的作品集無非是「靜態形象網頁」、「CRUD 功能留言板」、「模擬電商網站」，反骨的我不想跟大家開發類似的東西，一直思考該做怎樣的東西才可以讓我 stand out，於是我突然有個靈感——我何不做一個有真實使用者使用的產品？

CRUD 是 Create（建立）、Read（讀取）、Update（更新）、Delete（刪除） 的縮寫，代表應用程式中最基本的資料操作。

從自身問題開始發想

那要做什麼樣的專案，讓我可以展現目前我所學的技術，又讓人有意願想要使用呢？我開始思考自己與身邊的人的問題與生活上的痛點，同時這個 scope 不能太大，若妄想著解決所有人的問題，那麼很大的機率最後可能解決不了任何問題。

我想到一個即使我已脫離那個時期，至今仍痛到不行的——大學租屋地獄迴圈。

當時的我北漂念書，學校宿舍名額也有限，所有北漂莘莘學子租屋時都會面臨這些問題：不知道哪裡可以租、租屋處有哪些公設、會不會遇到對學生很壞的惡房東、租金水準如何、這些租屋處環境好不好等等，且剛到一個陌生環境的你很大機率「沒有人可以詢問這些問題」，大家只能挨家挨戶走到學校附近的社區，詢問那裡的警衛或社區管理員這些問題，很多時候警衛只叫你留下名字和電話草草打發你走開，只能回家等待那通遙遙無期的電話。

為什麼我知道這些？因為我、我身邊北漂的同學，大家都經歷過一模一樣的事。

解決一小群用戶的問題就好

為了印證我的想法，當時我在 Dcard 上爬了許多同樣有租屋問題的人的發文：

大家的怨念很深 XD

我不希望有一樣需求和問題的人再次經歷這樣的痛苦，我希望大家可以發揮社群的力量，分享自己的租屋經歷，讓其他人有真實依據可以參考，幫助這些人知道有哪些社區可以選擇、知道這個社區的環境和租金怎樣、居住體驗如何。

為何頻頻提到「社區」？臺北大學（我的母校）所在的北大特區是一個非常特殊的區域，周遭高級社區住宅林立，許多投資客在那裡買下幾戶，然後出租給學生。（我有個同學的爸爸甚至直接買一戶給他，讓這位同學自己住之外也可以出租給同學...呃請問缺乾女兒嗎？）

於是 Zuna 匿名租屋評論平台的想法誕生了，Zuna（租哪）這個名字是我在洗碗時想到的。

關於介面設計、技術選擇、夥伴選擇

夥伴招募與工作分配

你知道一個人單幹專案最開心的是什麼嗎？是你可以百分之百實踐你的想法，自己決定這個網站的風格、功能，做出一個完全符合你想像的專案。

那你知道一個人單幹專案最悲傷的是什麼嗎？是你會遇到一些技術限制（我會前端，我目前不會後端），要校長兼撞鐘凡事自己來，整個開發時程可能會被拉得很長。

盤點了一下自己的技能，可以做的事情有前端開發、介面設計、開功能 spec，因此我找了一位當時也對做 side project 有興趣的後端夥伴，正因為我們都有過租屋地獄輪迴的體驗，因此更可以互相討論真正必要的功能。

我們討論出的必要功能如下：

1. 看評論：顯示所有社區，點選社區卡片後顯示該社區所有評論
2. 找社區：點選設施按鈕後，於 Google Map 顯示符合條件的篩選結果，hover 社區小房子的 icon 會顯示社區資訊卡片
3. 寫評論：點選欲評論的社區卡片後，可撰寫星級評分、設施清單、租屋心得、居住資訊四大項題目，表單附有錯誤驗證功能，送出填答後導回該社區評論頁面。
4. 關鍵字搜尋功能，透過輸入關鍵字來快速查找相符的社區
5. 後台管理，能隱藏不當評論、將租金極端值不納入平均避免失真
6. 其他增進使用者體驗的小功能：infinite scroll、go to top、lazy load、美化提示訊息與錯誤顯示，減少使用者瀏覽的緊張感
7. 支援 RWD

很重要的一點是，將 spec 以文字化的方式記錄下來除了可以清楚劃分任務與負責人，更可以在撰寫的過程中再次檢視自己的想法，且這也是現今軟體開發的標準做法，透過學習與習慣這些流程，對日後工作也會很有幫助。

當時的 API 文件非常陽春的用 HackMD 寫 XD

介面設計

雖然自己不是一位專業的 UI 設計師，但非常希望這個 app 可以呈現出自己也很喜歡的風格，於是決定自己學習Figma，配色靈感從colorhunt探索，配圖從Getillustrations尋找免費資源，最終設計出了看起來好像還不錯的介面，重點是自己也很喜歡 🥹

完成設計稿後感受到滿滿的成就感 🥹✨

前端開發

前端技術選擇上，我使用 React、Styled-Component 來開發前端功能，原因是使用前端框架可以快速開發快速上線（且我將來需要靠 React 吃飯），以及我喜歡 Styled-Component 可以直觀地處理動態樣式、很好地隔離 CSS 作用域、支持巢狀寫法。

暴雷：當初沒想到 CSR（Client-Side Rendering，客戶端渲染）會對 SEO（Search Engine Optimization，搜尋引擎優化）造成不小的影響，連帶影響到網站流量，因此後續我含淚砍掉重練，使用 Next.js 重寫網站，成功地讓網站主要流量來源由 direct（直接流量）變為自然搜索（Organic Search）。待會會再提到這件事。

後端開發

為了快速開發這個專案，後端選擇的技術是 Ruby On Rails，僅以它提供的 API only 模式下開發，非常適合 MVP（Minimum Viable Product，最小可行性產品）的快速開發，讓整個後端應用程式在一週內完成。

產品上線了，然後呢——尋找使用者與社群迴響

我想這是所有產品開發者都會遇到的問題，該如何找到願意使用這個產品的用戶？當時有著一股熱血與信念，覺得這個工具一定可以幫助到許多人，抱著這種「使命感」與「推薦好東西」的想法，我找了幾個管道來找到這群使用者：

① 身邊有在校園周遭租房的同學與朋友

② 臺北大學租屋、找室友社團

有一些 tips 可以分享，若要找人填寫評論，一定要將連結附上並將所有流程列點之後告訴別人，讓幫助你的人「感覺起來很簡單」；同樣地，若要找社團管理員協助發文貼廣，就直接寫一段文案給他，讓他複製貼上做完這件事不花三秒鐘。不變的是必須抱持著一個「我想幫助大家」的心意去推廣你的工具，動機越純粹，大家更願意幫助你。

③ Dcard 發文

由於客群是臺北大學的學生，我當然要好好利用這個免費又直接接觸到這些人的社群——Dcard 校板！

我在文章點出大家在租房共同遇到的問題，以及重要功能簡介，最後邀請大家發揮社群互相幫助的力量，藉由評論也許可以幫助一個正在煩惱租房問題的新生，一起創造一個良善的分享互助風氣。

這篇文章獲得超過 400 愛心、400 收藏、近 60 則討論與好評，並為 Zuna 帶來近百則的使用者評論。只能說社群的力量真大 🤝🏻

大家的好評與感謝 🥺 甚至還有看到一篇留言「可以嫁給我嗎」我真的是 🤣🤣🤣

過了行銷期後，我發現網站瀏覽量急遽降低

從數據找洞見

Zuna 上線後的推廣期間，從 GA（Google Analytics）後台來看，流量一直還不錯，也陸續收到使用者的評論，但一過推廣期、我的發文被洗掉之後，我發現網站瀏覽量大幅度地降低。

從 GA 用戶流量來源發現，最主要流量為 Direct，代表大家都是透過輸入網址的方式找到 Zuna 比較多，可以推測是看過推廣文章或受他人推薦的人有意識地輸入網址造訪 Zuna，僅有少數人是透過輸入關鍵字（真正的搜尋意圖）並於搜尋結果頁造訪 Zuna。

數據記錄區間為 Zuna 上線後 ~ 優化架構前

這樣的結果對產品而言長期可不是一件好事，你不可能無時無刻都在行銷，且那些針對租屋有搜尋意圖的人才是真正需要這個網站的人，我了解到 SEO 是當務之急。

為什麼我的網站無法出現在搜尋結果頁？

「為什麼我的網站無法出現在搜尋結果頁？」那時我 Google 了這個問題，我才意識到原來技術架構會如此大地影響到商業結果。

當時 Zuna 採用純 React 開發，使用的是 CSR（Client-Side Rendering，客戶端渲染）渲染方式。這種架構下，瀏覽器需要先下載並執行 JavaScript 後，React 才會開始在客戶端渲染頁面內容。CSR 的優點是頁面切換相當流暢，使用者不需重新載入整個頁面；缺點則是首次載入時間較長，且對 SEO 不友善，因為並不是所有搜尋引擎都能有效處理 JavaScript 渲染的內容，可能影響網站在搜尋結果的排名表現。

決定更換技術架構徹底解決 SEO 不友善的問題

發現是技術導致的自然限制後，我決定趁網站內容還不是很多、架構並不複雜的這個時間點，改掉網頁的渲染方式。

前端開發

① 渲染方式調整

我使用 Next.js 這個全端開發框架，它能讓開發者根據頁面性質與瀏覽體驗選擇合適的渲染方式。例如 SSR（Server-Side Rendering，伺服器渲染）適合動態內容、SSG（Static Site Generation，靜態網站生成）適合靜態內容，可依據需求靈活選擇。由於我的需求是「SEO」和「使用者進到評論頁面都要能看到最新評論」，所以採用了 SSR 這個渲染方式。這確保了搜尋引擎能抓取到內容，且使用者總能看到最新內容。

② 使用 Typescript

既然已經要大幅重寫 Zuna，我也決定將純 JavaScript 換成 TypeScript。這樣在開發時比較不會因型別錯誤導致問題，且型別的定義本身就是最好的文件。開發時有了這些「文件」提升了開發體驗，不需要過度翻找之前寫過的程式碼，也減少了一些低級錯誤的可能（例如少給了元件幾個 props、資料結構錯誤等）。

③ 渲染方式以外的 SEO 優化

每個頁面都加入了適當的 meta tags，包含 title、description 標籤，同時也產生並提交了 sitemap 給搜尋引擎，讓爬蟲更容易索引網站的內容。

meta tags（中繼標籤） 是 HTML 文件 <head> 內的標籤，用來提供頁面資訊，如 SEO、描述、作者、編碼等。

④ 其他 UI 優化

當時請了幾位沒用過 Zuna 的朋友瀏覽網站，並觀察他們操作網頁元件時是否有卡住的地方。我優化了一些部分，例如將原本的 Infinite Scroll（無限捲動）改為傳統的頁數系統（點擊頁數切換到該頁），這讓使用者更容易掌握內容位置和分享特定頁面。另外把地圖頁面的按鈕從 switch 改成勾選元件，更能直覺地讓使用者知道「自己目前在哪裡」、「自己目前選到什麼」。這些改動都是基於實際使用者反饋做出的優化。

傻眼真的等於是全部重寫一次 Zuna 了 🫠 大家在開發前真的要想清楚自己的需求以及 app 的性質，綜合考量後再去決定要採用的技術。前期的技術選擇和架構規劃非常重要，它們會直接影響到後期的開發效率和維護成本。

從數據來看大改技術架構是否有效 (⁎⁍̴̛ᴗ⁍̴̛⁎)

從 GA 數據看，改完架構上線後一個月，最主要流量來源為 organic search，占比約 57.7%。

數據記錄區間為優化架構後一個月

而上線後至今平均來看，organic search 流量占比來到了 75.8%。

數據記錄區間為優化架構後至今

甚至後來還有收到 Google 通知「這是很厲害的成就」？雖然不確定和別的網站相比，這樣的數據是否真的厲害，但我可以確定的是，這樣的技術優化策略帶來了好的結果，有更多人透過搜尋意圖造訪 Zuna，大家的租屋體驗幫助了這些人得到更真實的參考依據。

佛系經營零行銷能達到這樣的成果似乎不錯 😭

2025 年的我回頭看這個 side project

如果當時有 AI

當時開發 Zuna 是 2021~2023 年之間的事情，開發時完全不像現在可以使用方便的 AI 工具一起開發，如果當時有 AI 可以讓我確認技術選擇，或許我不用重寫一次 Zuna 了吧？如果當時有 AI，也許我可以用更有趣的方式來開發相同的功能，例如將所有社區資訊以及使用者的評論整理成一個資料庫，建立一個 RAG 系統讓使用者可以自由詢問他想得到的租屋資訊。

RAG（Retrieval-Augmented Generation，檢索增強生成） 是一種結合資訊檢索與生成式 AI 的技術，主要用於提升 AI 生成內容的準確性與相關性。

還好當時沒有 AI

回想這段開發歷程，某方面來說我慶幸沒有 AI，讓我可以採這個技術大坑，有一個很急迫的問題想要解決，花費全身的力氣只為解決網站想要被更多人看見這個問題，體驗到原來技術真的會影響商業結果。我期許自己成為一個不僅會使用技術的工程師，還是一個理解這項技術背後會帶來哪些不同層面影響的工程師。

後記

也許這篇文章現在看來可能有些過時，若要我現在進行一個 side project 選題，我或許不會再選擇開發純 CRUD 功能的評論網站，我希望可以嘗試一些 AI 工具為我的網站帶來更好玩、豐富的可能性，但不變的是，我仍然會從自身不便去擴散思考，專注於解決一小部分用戶的問題，找各種資源推廣與加速完成的個專案，努力成為一位解決真正問題的開發者。