零售會員App收藏清單實務指南：由目標、流程到驗收逐步拆解

零售會員App收藏清單真正要解決的業務任務

由一個可觀察的動作開始

零售會員App收藏清單要先釐清訪客任務、內容責任和驗收條件，再按業務流程安排設計與程式。這樣能避免把網站畫面原封不動搬進流動裝置，亦令測試、上線和移交有共同依據。

會員在零售 App 看見一件暫時未打算買的商品，希望日後再找回；若收藏只是一個愛心圖示而沒有同步、登入與停售規則，使用者很快會失去對清單的信任。

例如零售會員、預約服務、教育及企業內部流程團隊常把不同訪客混作同一類人，結果首頁和表單都不能回答真正問題。把App開發的頁面任務列成一句動詞，才能分辨資訊展示與下一步動作。這樣才能把資訊展示和下一步動作分開驗收。

不要把模糊偏好當需求

「想要高級感」可以是視覺方向，卻不是可驗收條件。可驗收的說法應包括誰會看、要看甚麼、完成後要交給誰處理。這亦是把網站畫面原封不動搬進流動裝置最早出現的位置。

用資料界定範圍，而非憑印象加功能

資料不足時，先縮小決定範圍

動工前應收齊使用者情境、帳戶、API 文件、測試機、圖示和截圖。資料未齊不必假裝已確認；應標明缺口、負責人與截止日。在整理時，可用零售會員App預約改期作為頁面資訊取捨的參考。

把資料轉成欄位與責任

每個輸入資料都要知道誰提供、誰核對、何時可更新。圖片若沒有比例和用途，設計稿完成後仍會在上線前被迫重裁。資料表不只是技術文件，也是避免口頭遺漏的工作清單。

原生裝置能力、流動網頁覆蓋和後台 API 穩定度的取捨怎樣落地

比較時要比較日後工作，不只第一版

原生裝置能力、流動網頁覆蓋和後台 API 穩定度各有適合位置。選項的差異通常會出現在內容是否常改、流程是否有例外，以及日後誰負責維護。處理這些分界時，零售會員App會員積分提供的流程觀點比單看截圖更有用。

選型要連同驗收方式一起決定

任何平台或程式架構都要列出可驗收的輸入、輸出和失敗情況。若只寫功能名稱，供應商與客戶會各自理解成不同畫面。要把選型落地，應先預演一個正常流程與一個例外流程。

以帳戶狀態、商品變化與後台資料設計收藏清單

把專題規則寫成可見資料

收藏功能要先定義何時可加入、未登入時如何處理、登入後是否合併、本機與帳戶資料如何同步，以及停售或缺貨商品怎樣顯示。收藏不等於購物車，兩者的數量、價格與庫存提示不應互相混淆。

先預演一次例外，再談擴充

React Native 畫面可共用收藏流程，但 API 應以會員、商品與狀態的關係保存資料。實機測試要涵蓋登入切換、離線、重覆按鈕、商品下架和重新安裝 App 後的結果。

把相連決策留在同一條路徑

當同一個決定會影響內容、流程或上線檢查，應把可延伸閱讀的規則保留在手機彈窗干擾，讓負責人不用靠記憶尋找下一個核對點。

收藏清單的資料責任

• 會員帳戶：保存可同步的收藏關係。
• 商品資料：決定名稱、圖片、售價與可售狀態。
• 前台畫面：顯示加入、移除、缺貨與登入提示。

角色、交稿與決策權如何埋位

決策人不等於每頁撰稿人

專案應分開內容負責、業務拍板、技術核對和最終驗收四種角色。同一人可以兼任，但不能不寫清楚。若要預先看見改版的協作節點，可參考預約服務App首次開啟引導。

修改要有原因、影響與去向

每次改動應寫明要解決哪個任務、會影響哪些頁面及是否改動時程。單靠「幫我改靚啲」會令設計意見無法收斂。把變更留在同一份紀錄，可減少口頭要求在交付時消失。

• 指定每類內容的一位最終負責人。
• 把修改意見合併後才交出，不用逐人零散傳達。
• 任何新增流程先寫使用情境，再判斷是否納入首版。

把iOS、Android、REST API、PHP、MySQL 和上架素材放進正確的位置

技術是為流程服務，不是功能名單

iOS、Android、REST API、PHP、MySQL 和上架素材的組合要配合資料如何進出與誰會操作。PHP 和 MySQL 適合把內容、表單或訂單資料放在可管理的結構內；但欄位設計必須先反映業務語言。當技術範圍和服務責任需要對照，可查看對應服務頁的實作範圍。

把不可見的失敗情況提前寫出來

例如資料未填、權限不足、重複提交或回傳延遲，都應在測試表內有預期處理。這些情況平日不常出現，卻最容易令前台和後台的說法不一致。技術文件至少要記錄欄位、狀態、通知對象和手動處理方法。

測試時要找出的不是版面喜好

用真實內容、真實帳戶和真實裝置測試

空白示例很少揭示真正問題。測試應把長標題、缺圖、錯誤輸入和重複操作都放進去，才看得到流程是否完整。這時安排需求交流所列的準備項目可幫團隊預先分工。

驗收問題要能重現

一個有用的問題紀錄包括裝置、操作步驟、預期結果、實際結果和截圖。「有時不行」不能讓開發者定位原因。驗收會議應先處理阻斷任務的問題，再處理文字與視覺微調。

1. 以一個新用戶完成主要任務。
2. 以一個已有資料的用戶改動或取消。
3. 以一個錯誤輸入確認提示與紀錄。
4. 由非項目成員按說明重做一次。

不同行業會令流程在哪裡改變

行業差異會改變欄位，不只是改圖片

零售會員、預約服務、教育及企業內部流程團隊的客戶決策速度與所需資料不同。餐飲較重視時段和菜單狀態；專業服務要先建立問題脈絡；零售則要把商品選擇和訂單例外寫清楚。當流程需配合其他數碼接觸點時，網站內容與查詢安排的規劃能避免網站單獨運作。

不要把敏感或例外資料藏在備註欄

若某資料會影響誰可見、何時處理或能否提交，便應成為明確欄位與規則。備註只適合保留補充說明，不能代替狀態設計。行業專有資料越早命名，後期改程式和補資料的代價越低。

上線前要留住哪些可追蹤紀錄

網址與內容關係要在改版前對照

如果舊站已有被搜尋或被分享的頁面，改版時要列出舊網址、對應新頁和是否需要 301 轉向。沒有去向的連結會令訪客走到不存在頁面，也會令過往內容失去脈絡。內容與推廣的連動可從會員及訂單流程開始規劃。

追蹤應只量度可回答的問題

例如表單是否成功送出、哪類服務頁帶來查詢、哪個內容促成下一步，都是可檢視的問題。不要把一長串數字當作成果；先約定哪個動作需要改善。上線後的第一輪檢查應定在內容和技術仍可快速調整的時間。

• 保存上線前的網址對照與帳戶清單。
• 記錄主要表單、電話和重要按鈕的測試結果。
• 把待觀察問題寫成下一輪更新項目。

移交後誰負責甚麼才不會失控

移交不只是交出登入帳戶

真正可用的移交文件要說明誰可改甚麼、改動後怎樣檢查、遇到例外找誰處理。若內容人員沒有看過真實流程，網站很快又會回到只能找開發者的狀態。需要安排交接方式時，可由推廣活動的落地頁開始列出聯絡與決策安排。

把下一階段留在已知邊界內

首版未做的功能應保留原因、優先次序和需要補的資料，而不是用一句「日後再加」帶過。這樣下一輪啟動時可從既有紀錄判斷，而非重新猜測。當需求增加，先看它是否改變主要任務，再決定是否另開變更工作。

常見誤解如何在動工前拆開

畫面完成便代表流動應用程式已可發佈嗎？

這個想法忽略了由使用情境、資料來源、裝置權限和上架要求定義首版。真正決定品質的，是每個角色能否在預定狀態下完成自己的工作。外觀、平台或功能只是在清楚任務之後才有意義的選擇。

一個可執行的判斷方法

把一項要求寫成「誰在甚麼情況下，輸入甚麼，應看到甚麼，之後誰要處理」。若寫不出來，代表仍未可交給設計或開發。這個方法同時適用於首版功能、內容修改與上線後的改善。

把執行細節變成可追蹤工作

資料、規則與責任要可以重現

每一項決定都要有來源、負責人和可核對結果，才不會在不同部門之間變成各自理解。

先固定資料來源：每個數字、服務描述和政策文字都要知道來自哪位負責人及何時核實。來源未定的內容應標為待確認，不能在設計稿內假裝已成定案。

失敗畫面也屬交付內容：沒有資料、輸入錯誤、網絡中斷和權限不足的畫面都要有明確說法與下一步。若只製作成功情境，真正上線後最常見的問題反而沒有人負責。

欄位要有單一意思：狀態、日期、備註和負責人不可混在同一個自由文字欄。資料模型先分清含義，客服、營運和技術人員才會用同一套方式核對。

時間點是流程規則的一部分：開始、截止、暫停與重新公開等時間不應只存在於電郵。若日期會影響訪客可見內容或營運處理，便要有明確資料欄與負責人更新。

公開與未公開內容要分開管理：草稿、預覽、排程與已公開版本不能以同一個狀態混用。權限與流程分清後，團隊才不會把未覆核內容或過時版本錯誤推到前台。

變更集中由一位窗口發出：跨部門意見可很多，但每一輪要由指定窗口整合後才交給製作方。這能保留優先次序，也能避免同一件事被不同人要求相反修改。

測試證據要留給下一輪使用

測試不是一次性的交差文件；它應幫下一位更新的人理解哪些條件已確認、哪些仍要觀察。

真實文案要提早入稿：長服務名稱、完整地址格式或商品規格若到最後才放入，最容易令版面與表單重做。測試稿應使用接近正式長度的文字，而非短暫的示例句。

換裝置後要重做關鍵任務：桌面完成並不代表手機、平板或另一個瀏覽器會得到相同結果。每次改動導覽、表單或圖片時，至少重走一次主要任務與一個例外情境。

例外流程要有停下來的條件：當資料不足、交易待覆核或內容未確認時，系統與人員都要知道可否繼續、要通知誰及何時重試。沒有停止條件的流程最易把錯誤一路帶到下一步。

客服要看到同一張訂單或查詢：前台顯示、通知內容和後台紀錄若來自不同規則，客服便無法有效回答問題。每個主要狀態都應以相同識別資料讓不同角色交叉核對。

舊資料先以小樣本演練：內容、商品或會員資料搬遷前，先用少量真實樣本核對欄位、圖片、日期、網址與狀態。演練發現的缺口應回到對照表修正，而不是在正式匯入後逐筆補救。

標準規則與例外規則分開寫：一般流程宜用簡短語句說明，例外才額外列出條件與處理人。把所有限制塞進同一句，無論客戶、客服或開發人員都難以判斷哪一條正在生效。

上線後保持內容與流程一致

每次變更先看受影響的任務

一個小改動可能同時影響內容、網址、通知或後台處理，因此要由實際使用路徑反查範圍。

交接人要親手完成任務：只觀看示範不足以證明可接手。內容或營運人員要以自己的帳戶完成一次更新、預覽、提交與前台核對，才知道哪個步驟仍需要文件。

網址改動放入交付表：路徑、標題或內容合併一有改動，就要同步更新舊新網址對照與內部連結。把這件事留到上線日才做，最容易造成跳到錯頁或找不到頁面。

服務內容要同表單相互核對：頁面承諾處理的問題，應與表單要求的資料及回覆責任相符。若表單問不到判斷所需資料，前端說明再完整也難以支援後續跟進。

自訂需求先看資料模型能否承受：新增畫面不一定是新增能力；若背後資料、權限或例外狀態未定，功能很快會變成人手補救。先列清輸入與輸出，才知道應用既有平台還是另作開發。

分類架構要反映尋找任務：分類、標籤或篩選不是為了填滿導航。它們要讓訪客和編輯以相同邏輯找到內容，並避免同一項資料被放在多個互相矛盾的位置。

發佈後要安排首輪核對：公開後宜由內容、技術與業務各走一次最重要路徑，核對網址、內容、表單、通知和後台結果。這輪檢查要有日期與負責人，不能只寫「上線後再看」。

日常更新也要有可交接習慣

把小型核對變成固定習慣，能令項目在初次上線後仍保持可管理，而不是逐漸回到靠人記得的狀態。

版本名稱要說明目的：檔案或頁面版本不宜只用「final」和「new」。名稱應包括日期、用途或修改主題，令覆核人可以判斷自己正在看哪一次決定。

通知不是最終憑據：電郵、推送或畫面提示可以提醒人處理，真正狀態仍應由可追查的後台紀錄確認。這個分工可避免通知延遲或重覆時，團隊作出錯誤處理。

圖片加入前要看裁切後效果：一張相片在橫幅、卡片和手機首屏未必仍保留主體。素材交付時應同時註明焦點、可裁切範圍和替代文字，減少上線前臨時換圖。

第三方串接要預留測試情境：外部服務會有取消、逾時、重覆回傳或資料不完整等狀態。驗收表要寫出前台怎樣提示、後台怎樣記錄和誰可作人工覆核。

關鍵動作應有替代路徑：若手機、權限、付款或網絡令某個動作不能完成，訪客仍應知道可否稍後再試、改用其他方法或聯絡誰。替代路徑可把一次失敗變成可跟進的情境。

常見問題

動工前要預備甚麼？

應先整理使用者情境、帳戶、API 文件、測試機、圖示和截圖，再標示每份資料的負責人和可交付日期。若未能一次過備齊，至少要先確認首版必需內容與不能延後的帳戶權限，避免設計和開發在錯誤假設下前進。

應該何時確認範圍？

範圍應在架構與設計開始前確認，並用頁面、欄位、流程和驗收條件表達。完成後若新增任務，應記錄它影響的內容、測試和上線安排，而非直接插入已排好的工作。

內容未齊可以開始嗎？

可以先做資料盤點、導航和首版流程，但不應假裝空白位置日後自然會補好。內容未齊時要保留真實長度與缺口，並指定最後交稿時間，否則手機版和測試都會失真。

怎樣安排驗收才有效？

有效驗收要由一位不參與製作的人按真實步驟操作，並紀錄裝置、輸入、預期結果與實際結果。應先處理阻斷任務的問題，再討論文字或視覺微調，避免不同嚴重程度混在一起。

日後誰可以更新內容？

日後更新權限要按角色分配：內容人員可改文字和圖片，決策人核對發佈，技術人員處理欄位或流程改動。每次更新後應有一個簡短檢查步驟，確保前台顯示與後台資料一致。

出現例外流程怎樣處理？

例外流程應有明確狀態、負責角色和手動處理方法，例如資料不全、提交重複或需要覆核。不能只在備註寫「跟進」，否則不同同事會以不同方式處理，紀錄也無法重現。

怎樣開始與團隊溝通？

開始前先帶同業務目標、現有資料、需要處理的問題和可決定的人出席。需要正式討論時，可聯絡 TERO 網頁設計公司；電話 6205-3555，地址：上環干諾道中 130 號誠信大廈 8 樓 806 室。