網頁設計公司點揀：見面前先核對作品、分工與交付責任

網頁設計公司點揀：先聽對方怎樣追問你的問題

「網頁設計公司點揀？我睇過幾間的作品，都幾靚。」假設一位荃灣公司的老闆這樣問項目負責人，對方沒有立即推薦名單，而是反問：「你最怕網站做完之後，哪件事仍然做不到？」這段模擬對話，正好指出評選的起點：先知道合作要解決甚麼，才有辦法判斷眼前團隊是否合適。

老闆回答：「我想同事自己更新產品，但又怕做完之後甚麼都要另找人改。」負責人便把問題拆成後台可更新的內容、需要技術修改的範圍，以及維護聯絡安排。這些答案不在首頁截圖內，也不能單從公司規模推斷。選擇網站製作公司，需要看到對方如何理解工作，而不只是如何介紹自己。

以下面談全部屬示範問答，並非真實客戶訪談，也不代表任何公司的既定承諾。你可以把問題帶去見不同候選團隊，要求他們用自己的方法回答。目的不是找出最會講術語的一方，而是確認雙方能否在資料不足、需求改變及意見不同時，仍然把工作推進到可交付的狀態。

面談前最好交出同一份簡介，列明公司服務、主要訪客、網站要支援的操作，以及內部誰會更新內容。若一家收到完整資料，另一家只收到「想整個網站」，回覆自然難以比較。簡介毋須長，但必須讓對方知道哪些是已決定的條件，哪些仍想聽專業判斷，避免把試探想法當成正式要求。

若你還未整理過項目，可先用由需求至上線的工作流程列出階段，再集中比較每一階段由誰帶領、會交出甚麼及需要你提供甚麼。這篇則把焦點放在人員能力、合作方法和責任證據，不以報價高低作評分，亦不假設任何公司適合所有類型網站。

「你會先問我哪些資料？」

值得留意的答案，通常會接觸實際業務。例如團隊會問產品是否需要定期更新、客人通常先查甚麼、公司能否提供內容，以及現時接收查詢的人如何跟進。問題不一定很多，但應有目的。如果對方問某項資料，能解釋它會影響頁面、功能或工期，你便可以判斷其理解是否具體。

反過來，只要求你挑幾個喜歡的網站，也未必已理解項目。視覺參考可以協助溝通，但不能交代資料結構與日常運作。你可追問：「如果我喜歡的效果不適合我們的內容，你會怎樣提出替代？」觀察對方能否提出理由和可比較的選項，而不是一味答應或只說自己的做法一定最好。

「我們的需要仍有不確定，可以先做甚麼？」

供應商可以建議先整理資料、做小範圍示範或拆分階段，重點是解釋這項前期工作會減少哪種不確定。若每個問題都只能等正式開發才知道，公司便難以掌握方向。另一方面，也不應要求候選團隊免費完成整套設計或程式，合理的評選應圍繞方法、相關示例和可核對的經驗範圍。

把仍未確定的事項分開記錄，也方便你看出誰願意指出限制。例如公司未決定使用哪個存貨系統，對方應說明接駁範圍需要待資料確認，而非立即聲稱全部可完成。坦白指出前提，往往比過早承諾更有助合作；你亦要準備回應這些前提，不能只要求對方承擔所有未知。

第一輪面談：作品要問到對方實際做過哪一部分

「這個作品中，你們負責甚麼？」

一個網站可能由不同團隊處理設計、程式、內容、寄存及後續更新。看到作品後，應問候選公司當時負責哪些部分、哪些由客戶或其他供應商提供，以及目前畫面是否仍與交付時相同。這不涉及貶低合作模式，而是避免把整個網站的所有優點都誤認為同一家公司獨力完成。

可請對方選一項與你需要相近的操作來解釋，例如產品分類、查詢表格或內容更新。較有判斷價值的說明，會包含原本限制、採取的方法及留下的取捨。若只能不斷切換漂亮首頁，卻無法說清楚其中一項功能如何支援使用者，你還未得到足夠證據評估其能力。

你亦可請對方說明一個曾經需要取捨的設計決定，但不必要求提供客戶名稱。若答案是為了方便內容人員更新而限制某些版面自由，便可追問這種取捨是否適合你的團隊。評選重點不是證明對方做過完美項目，而是看他能否解釋決策、限制與結果之間的關係，並將經驗轉化為這次工作的可行建議。

對於涉及保密的作品，不宜要求展示真實客戶資料或後台帳戶。團隊可以使用獲授權的示範環境、遮去敏感內容的畫面，或用虛構資料重現操作。願意保護既有客戶資料，是合作界線的一部分；評選人亦應接受合理限制，不能以是否願意公開資料作能力高低的標準。

「有沒有與我們流程相近，而非行業名稱相同的例子？」

同樣是貿易公司，一間重視產品型號搜尋，另一間需要分級會員查看資料，實際工作差異可能很大。行業相同的作品可作參考，但更應看流程是否相近。你可描述一段從訪客進站到同事跟進的路徑，請對方指出曾處理哪些相似環節，以及哪些需要另作研究。

假設公司有大量型號，但產品相片未齊，候選團隊若能討論資料匯入、缺圖狀態及日後補資料的方法，便比只展示同業色系更貼近問題。這個例子沒有要求一定使用某種架構，而是測試對方能否從現有條件提出可行安排，並交代暫時缺資料會如何影響交付。

「可否讓我們實際操作，而不只看投影片？」

在獲授權示範環境中，請一位將來會使用後台的同事試做普通工作，例如修改一項資料、預覽及確認發佈。觀察團隊是否能解釋操作邏輯、指出限制和收集問題。示範不必涵蓋所有功能，但應與日後工作相關，避免花整場會議觀看團隊熟練操作，自己仍不知道能否上手。

操作時出現小問題，未必代表團隊不合適。更值得留意的是對方如何處理：是否先確認重現條件、能否分清設定與程式問題，以及會否記錄待答事項。你正在評估合作過程，現場反應提供的資料可能比一段完全剪輯好的示範更有參考價值。

• 作品名稱之外，記下候選公司實際負責的範圍。
• 每個相關作品至少追問一項操作及一項限制。
• 把未能當場核實的說法列為待補資料，避免當作已確認。

第二輪面談：誰作決定，誰真的動手做

「簽約後，日常由誰跟我們對接？」

售前聯絡人、項目管理者、設計師與程式人員可能不同，這本身沒有問題。需要知道的是問題如何轉達、誰整理決定、誰跟進逾期項目，以及主要聯絡人不在時怎樣接手。不要單以會議上有多少人判斷團隊規模或能力；看得見的分工，比籠統表示有專人跟進更容易評估。

你可以用一個模擬情境測試溝通方法：「假設我們星期三發現產品欄位理解不同，應通知誰，甚麼資料才足夠安排處理？」答案應說清楚接收入口、需要的例子及回覆方式。回應期限則應在實際合作條款中確認，不能把面談時的即時回覆速度當成日後任何時候的服務承諾。

公司內部也要有人負責整合意見。如果老闆、銷售及行政各自直接要求修改，外判團隊很難知道哪個版本才算數。評選時可以坦白交代你的決策方式，請對方說明會如何管理衝突。能合作的流程需要雙方配合，不能只問供應商會否無限接收零散指示。

「設計、程式與內容之間，怎樣交接？」

漂亮畫面能否在真實資料下運作，要看設計與程式是否共用一致理解。例如標題很長時怎樣換行、沒有相片的產品怎樣顯示、多語言長度不同時如何處理，都不只是某個人的單獨問題。可要求對方解釋會在哪個階段確認這些條件，以及發現不一致時由誰安排修正。

內容責任尤其容易被低估。有人負責排版，不代表有人負責撰寫或核實服務說法；有人協助上載，也不代表會自動整理混亂的產品資料。問清楚內容由誰提供、誰核對及誰批准，可減少雙方在製作期間互相等候。這裏要確認的是分工方法，具體包含哪些工作則留在範圍文件內寫清。

評估網頁設計及程式開發安排時，可請團隊拿一頁假設服務頁作示範，說明它如何從原始資料走到可發佈內容。若每一步都有明確交接物，你較容易估計內部需要投入多少時間；若全部被概括為「到時再傾」，便應追問哪些部分仍未有安排。

「有合作夥伴或外判工作時，誰承擔協調？」

網站項目使用外部專業人員並不罕見，重點是工作界線、資料存取及交付責任是否清楚。你不需要介入每一項人事安排，但應知道誰是正式負責窗口，是否可能需要你直接協調其他單位，以及第三方延誤會如何通報。不要把所有合作模式都理解為能力不足，也不要忽略多方依賴造成的風險。

可請候選公司把自行處理、由你提供及由第三方處理的事項分開列示。若某個關鍵接駁依賴另一套系統，應標明需要甚麼權限與文件。對方若能在評選時指出依賴，便有助你提早聯絡現有供應商；反之，直到快上線才發現缺少介面資料，項目時間便很難控制。

第三輪面談：交付之後，公司能否自己運作

「同事哪些工作可以自己做，哪些需要技術支援？」

不要只問網站有沒有後台，應列出日常工作逐項核對。新增產品、修改文字、調整分類、設定用戶權限及修改版面，可能屬於不同層次。請對方說明哪些已包含在操作介面，哪些需要程式修改，哪些受既定格式限制。沒有必要要求全部任意改動，重點是限制是否符合公司的實際更新需要。

培訓亦應對準工作。一次介紹所有按鈕，未必足以令行政同事獨立完成產品上架。可以問是否會以商戶自己的常用流程演練，會留下甚麼文件，以及新同事日後可如何學習。若培訓後仍有問題，亦要知道後續提問屬哪種安排，不能只用「會教你」概括整段交接。

讓未參與開發討論的同事試讀操作文件，是實用的判斷方法。他可能立即發現某些步驟只對熟悉系統的人才有意思。評選階段不一定能看到完整文件，但可請候選團隊展示不含客戶資料的文件格式，了解其說明是否包括前提、操作結果和常見例外。

「網站、域名和寄存的控制權如何安排？」

控制權牽涉帳戶持有人、授權使用及交接方法，應逐項確認，不能只聽「網站屬於你」。有些第三方元件可能只有使用授權，某些管理服務則由供應商代辦。你需要知道公司可取得哪些資料、哪些帳戶由誰持有，以及日後更換維護者時有甚麼條件。具體權利仍應以雙方確認的文件為準。

寄存亦要分清基礎環境與網站維護。對方提供網站寄存或主機安排，不代表任何內容或功能修改都包括在內。你可以參照寄存服務責任的核對項目追問備份、還原、更新及故障處理的分工，再確認需要由哪一方批准或提供資料。

如果你已有域名及寄存，請說明現時控制權狀況，不要只要求新團隊「幫我處理晒」。候選公司應先了解現有設定及可取得的權限，才建議是否需要搬遷。未經盤點便要求立即更換所有服務，未必適合你的情況；同樣，堅持完全不改任何環境，也可能妨礙必要工作。

「維護出現問題時，我們會收到甚麼回覆？」

試用具體故障情境提問，例如表格突然收不到通知、管理員無法登入或網站某頁出錯。應確認支援入口、初步需要的資料、如何分辨緊急程度，以及會否提供處理進度。回應、開始調查及完成修正是不同事情，面談時應分清，避免把快速確認收到訊息誤解為保證立即修好。

保安維護亦不能只用「有保護」概括。你可用網站保安檢查的責任清單，詢問誰核對程式更新、管理員權限及異常紀錄。好的答案應與服務範圍一致，既不把所有責任推給商戶，也不作無法驗證的全面保證。尚未包含的工作，應明白列為另需安排。

可再問一個交接情境：「假設兩年後由另一位同事接管，哪些資料足以讓他知道網站怎樣運作？」候選方可以說明文件種類、帳戶清單及工作紀錄的安排。若答案只是保證到時仍可找同一個人，便應追問人員變動時的方法。可持續合作需要有人負責，也需要讓必要知識留在可交接的紀錄內。

若有定期維護，可問報告會交代甚麼，例如完成的更新、仍待處理的事項及需要商戶決定的問題。只有「正常」兩個字，難以支持日後追查；報告太多技術資料而沒有結論，同樣不便管理。你要找的是能把技術結果轉成下一步行動的溝通方式。

把答案放在同一張比較表，才不會只記得誰講得好聽

每次面談結束後，先記錄已展示、已書面確認、口頭表示及仍待核實的事項。這四類不能混在一起。候選公司可能很有經驗，但如果你的特定需要仍未談清，便不能假設自然包含。評選的目的是找出適合這次工作的合作方，不是替市場上的公司作整體排名。

評分之前，先定最低條件。例如公司必須能自行更新產品、需要明確的程式維護窗口，或不能把域名控制權放在已離職人士手上。未達最低條件的方案，應先要求補充安排。不要讓視覺喜好把基本需要抵銷，也不要因某一項特別突出而忽略整個合作流程是否可行。

其後才按重要程度比較。假設網站主要承接專業服務查詢，內容整理及需求理解可能比複雜動效更值得留意；若網站每天大量更新資料，後台操作與支援分工便要佔更大比重。這些權重應源自業務，而非套用任何固定分數表。沒有一套評分可取代你對公司運作的了解。

面談亦可觀察對方如何拒絕不合理要求。若你提出互相矛盾的條件，合適的團隊應指出衝突並解釋選項。例如要求任何人都能自由改版面，同時又希望版面永不出錯，便需要討論權限與可修改範圍。能提出有根據的不同意見，是協作能力的一部分，並非服務態度差。

• 把「必須有」與「有更好」分開，先查前者是否得到證據支持。
• 對口頭承諾提出書面追問，保留未回答事項，不替對方補完答案。
• 請實際會使用網站的同事參與相關示範，避免只由外觀決定。
• 在作決定前核對最後版本，確保面談後的變動已反映在文件。

如果候選方案仍各有疑問，可以安排一輪有範圍的澄清，不必重開整場推銷會議。把同一問題同時交給各方，要求說明方法、限制及所需資料。你會更容易看出差別，也能避免某家公司因更熟悉你的內部想法而得到不公平優勢。

不要忽略回覆中的限定字眼，例如「視乎第三方支援」「需由客戶提供資料」或「只涵蓋現有格式」。這些不一定是負面因素，反而能幫你判斷條件是否可滿足。把每個前提交給內部相應負責人核對，能分辨方案本身不適合，還是公司尚欠準備；兩者的下一步處理不同。

最後的選擇理由應寫得出來。例如選某團隊，是因為其內容交接方法適合現有人手，而且已示範日常操作；仍需跟進的是某項外部接駁文件。這種紀錄既方便向其他決策人交代，也讓正式啟動時保留評選期間已確認的前提，不必重新爭論當初為何這樣選。

常見問題

一定要找做過相同行業的公司嗎？

相同行業經驗能幫助理解部分用語及流程，但不能代替核實。先看對方是否理解你的特定服務方式，再看有沒有相近資料結構或操作經驗。若沒有同業作品，仍可透過受控示範、流程說明及合理的前期研究安排評估；若有同業作品，也要確認實際參與範圍。

尤其不要把其他客戶採用的功能全部照搬。相同行業仍有不同客群、內部人手及接單方式。你可要求團隊說明哪些經驗可直接參考，哪些需要重新設計。能劃出這條界線，比把每個項目都套進同一個做法更有助長期使用。

小型團隊是否一定比大型公司風險高？

不能只憑人數判斷。應核對可用人手、備援聯絡、文件及交接安排，亦要看項目規模是否配合承接能力。小型團隊可能溝通直接，大型團隊也可能有較多交接層次；真正需要比較的是具體安排，而非把規模等同責任感或技術水平。

你可以問主要人員請假、離職或同時處理多個項目時怎樣接手。對方毋須透露其他客戶機密，但應能解釋工作紀錄如何保存及誰有能力跟進。若所有答案都依賴某一個人隨時在線，便要進一步了解該安排能否配合你的營運需要。

對方願意保證排名或所有功能都能做，是否更有信心？

過度概括的保證需要拆開核實。搜尋結果受多項因素影響，功能亦可能依賴第三方權限及資料。請對方把可控制的工作、前提和驗證方法說清楚。你應評估的是交付責任是否具體，而不是承諾的字眼是否最強。沒有前提的肯定答案，不足以支持採購決定。

下一次面談，帶同一份問題，也帶自己的工作例子

回到開首的模擬對話，老闆最後需要回答的已不是「哪間作品最好看」，而是「哪個團隊最能讓我們按已確認的方法完成網站並持續使用」。這個答案要由展示、文件及互相追問累積而成。評選花的時間應用在關鍵疑問，不必變成無止境收集公司介紹。

1. 準備一個真實工作流程，改用不含客戶資料的例子說明。
2. 選出不能妥協的合作條件，要求候選團隊提供相應證據。
3. 整理面談後仍未回答的問題，再作最終比較。

決定後，可將評選期間最重要的答案轉成啟動會議議題，例如誰整合意見、哪位同事參與後台示範，以及哪些外部資料仍待取得。不要讓評選文件完成使命後便被擱置。把已確認共識帶入正式工作，能減少售前與製作團隊理解不同，也讓你及早看見有沒有關鍵安排在交接時遺失。

也請預留內部判斷時間。供應商補充資料後，要由使用部門確認是否足夠，管理層則核對責任及持續投入。這能減少為趕決定而忽略關鍵限制，也讓正式合作開始時，各人知道自己曾確認甚麼、接下來需要交付甚麼。

• 會前：交出一致簡介，避免候選方各自猜測範圍。
• 會中：以問題及操作取得證據，不只記錄印象。
• 會後：核實未答事項，再把選擇理由留下來。

準備比較合作安排時，可把這份面談問題連同公司的日常更新例子，交給 Black Media 討論網站製作分工。先講清楚公司希望自己處理哪些工作，以及需要外部協助的部分，雙方才容易判斷是否適合展開項目。