服務範圍 · 流動應用、網站與設計
Equator 的開發與設計服務範圍
這個頁面把 Equator 的服務拆開來說，讓你知道每一項適合什麼樣的專案，以及不適合的情況。我們不做包山包海的清單，只列出實際會承接、也有交付方法的工作。
服務分開列出，是因為報價與交付方式差別很大。對外網站與對內系統的設計重點不同；單做設計審查與從零規劃流程，投入的時間也不一樣。下面每一項都說明適合的專案情境，以及我們通常會在什麼階段介入。
流動應用開發
手機 App 是我們的主要工作之一。從功能規劃、畫面設計到上架，整段都可以承接，也可以只接其中一段。常見的專案是面向消費者的服務 App，或給內部員工使用的作業工具。
技術路線取決於你的需求。需要 iOS 與 Android 同時上線、且介面要求一致時，Flutter 這類跨平台框架可以讓單一程式碼庫輸出兩個平台，版本同步的負擔較小。若功能高度依賴特定硬體或系統層能力，原生路線會更合適。iOS 端我們以 Xcode 進行編譯、除錯與模擬器測試，並處理上架前的憑證與描述檔準備。
適合與不適合
- 已有明確使用者流程與功能範圍，需要有人把設計落到可上架的版本
- 內部作業工具要從紙本或試算表搬到手機上，讓現場人員直接填寫
- 只想做一次性展示、沒有後續維護計畫的樣板 App，通常不划算
網站與後台系統
網站專案在我們的定義裡包含對外網站與對內系統。對外網站重視內容呈現、載入速度與搜尋可見度；對內系統重視流程、權限與資料正確性。兩者的設計重點不同，報價結構也不一樣。
很多香港客戶的實際需求是後台：把原本用試算表管理的個案、訂單或申請流程搬上系統。這類專案的重點在欄位設計與例外處理，例如同一筆資料在不同狀態下誰能修改、修改後要不要留紀錄。這些細節會在需求整理階段逐項確認。
UX/UI 設計
設計服務涵蓋使用者流程、資訊架構、線框圖、原型與介面設計。我們不會跳過流程直接畫畫面，因為那通常導致開發後才發現動線不通。
如果你已經有設計稿但想確認可用性，也可以單獨委託設計審查。我們會從主要流程出發，檢查新用戶能否自行完成關鍵動作、錯誤提示是否清楚、以及雙語切換後版面是否仍然成立。
設計審查涵蓋
- 新用戶能否自行完成關鍵動作
- 錯誤提示是否清楚、可回復
- 雙語切換後版面是否仍然成立
設計系統與元件庫
當產品需要長期迭代，或有多個頁面與平台要維護時，設計系統的價值會慢慢浮現。它把按鈕、表單、顏色、間距與文字樣式定義成可重用的元件，讓新增頁面時不必每次重新決定。
我們通常在 Figma 裡建立與維護這套系統，並在開發端對應成可重用的程式元件。這樣設計與程式兩邊的命名一致，交接時少一層翻譯。專案越大、參與的人越多，這層投資回報越明顯。
元件庫通常包含
- 按鈕與表單欄位的各種狀態
- 顏色、間距與文字樣式定義
- 設計與程式共用的元件命名
- 換行、截斷與雙語長度規則
原型與概念驗證
有些專案在投入開發前需要先驗證方向。原型可以是可點擊的畫面流程，也可以是能實際操作、有假資料的網頁應用。前者用來確認動線，後者用來確認流程與資料結構是否合理。
如果目標只是快速確認某個流程有沒有用，Bubble 這類無程式碼平台能在較短時間內做出可操作版本，讓真人試用後再決定要不要客製開發。需要高互動敘事的產品頁或概念展示，Framer 的原型與發布能力會更貼近成品。
跨平台一致性與雙語介面
同一個產品在不同裝置上
同一個產品在 iOS、Android 與網頁上出現，介面與行為不一致是很常見的問題。使用者會覺得「換了裝置就像換了產品」，客服也會收到重複的問題。
我們的處理方式是在設計階段就把共用與分流的元件分清楚，哪些行為必須一致、哪些可以遵循各平台的慣例。實作上再配合跨平台框架與共用元件庫，把差異控制在可預期的範圍內。
繁中與英文並存的版面
繁中與英文並存是香港產品的常態。字串長度差異、標點與換行規則、日期與數字格式，都會影響版面是否成立。這些問題如果留到開發後期處理，通常要回頭改設計。
我們會在資訊架構階段把語言切換納入規劃，標籤與錯誤訊息都預留英文長度，並在設計系統裡定義換行與截斷規則。這樣雙語不會變成臨時加班的來源。
上線前檢查與效能審核
網站上線前，我們會用 Google Lighthouse 從效能、無障礙、SEO 與最佳實踐幾個面向做檢查，改版後再跑一次做對照。重點不是分數，而是把結果當成待辦清單逐項處理。
圖片體積、字型載入與第三方程式碼通常影響最大，也最容易在趕上線時被略過。無障礙檢查會提醒對比度、替代文字與鍵盤操作的問題，對需要服務不同用戶群的機構網站尤其實際。
上線後維護與迭代
上線後的工作包括既有功能修復、系統與憑證更新、以及新需求開發。我們會在一開始就約定維護範圍與回應方式，避免後續出現「這算誰的」的爭議。
常見的維護節奏是按季度檢查依賴項目與作業系統版本，並在需要時安排更新。若產品需要持續加功能，也可以改用固定的迭代週期，把設計、開發與驗收排進同一個節奏裡。
功能修復
既有流程出錯時，先確認影響範圍與重現步驟，再排入修復順序。
系統與憑證更新
依賴項目、作業系統版本與上架憑證都需要定期檢查，避免到期才處理。
新需求開發
用固定迭代週期把設計、開發與驗收排進同一節奏，範圍一開始就講清楚。
維護不是上線後才想的事，而是一開始就要談清楚的範圍。
常見問題
可以只做設計，不接開發嗎？
可以。設計審查、流程規劃或介面設計都能單獨承接，交付的是設計檔與規格說明。若之後要交給其他團隊開發，我們會把元件狀態與尺寸規則寫清楚，減少來回確認。
跨平台框架會不會讓效能變差？
多數以表單、清單與內容瀏覽為主的 App，跨平台框架的效能足夠。真正需要原生路線的，通常是重度圖像處理、背景長時間執行，或高度依賴特定硬體功能的專案。這些會在功能規劃階段先判斷。
設計系統對小專案有必要嗎？
只有幾頁、也不打算長期加功能的專案，通常用不上一整套系統。但如果之後會持續新增頁面或增加平台，先把按鈕、表單與文字樣式定下來，可以省掉每次重新決定的時間。
雙語介面什麼時候要開始處理？
越早越好。語言切換會影響標籤長度、換行位置與錯誤訊息排版，在資訊架構階段就納入規劃，比在開發後期回頭改設計省事得多。
接著可以看什麼
如果你已經知道需要哪一項服務，可以直接把專案背景與時程寄給我們，我們會先判斷適合的服務組合再回覆。還在比較階段的話，先看流程與工具這兩頁會更有幫助。