改版 App 可以考慮再投 UX Design Awards，但若作品曾在這個獎項獲獎，報名前須說明這次改了哪些功能或設計。官方條款對未經重大功能或設計變更的舊得獎作品設有限制。準備詢問資格時，應提供具體改動與原參賽版本供主辦方確認。

UX Design Awards 改版參賽的準備，可以從一個使用者任務開始：使用者原本在哪個步驟遇到困難、新版如何調整，以及測試或客服紀錄是否記下相關問題。整理清楚問題、改動與研究紀錄之後，再撰寫英文說明和製作影片。

本文以 2026 年 10 月 13 日查得的官方資訊為準，對應 Spring 2027 徵件；以下流程安排及假設例子是編輯建議，並非主辦規定的固定送件格式。

舊版獲獎紀錄與重投資格

先把產品名稱、舊版參賽年度、獲得的正式稱號與當時提交的版本找出來。官方條款第 2 節第 3 項說明，曾在 UX Design Awards 或其前身獲獎的作品，若之後沒有重大功能或設計變更，便不符合再次參賽的資格；有重大變更者，須在作品描述中特別指出並提出相應資料。

條款未以改版百分比判定重大變更。

詢問時除了列出新增功能，也要說明使用方式改變了什麼。例如，新增取消預約按鈕後，使用者便能自行取消，不必再聯絡客服；相較之下，新增頁面若只重新分類原有內容，操作方式可能沒有改變。重大變更的適用情況仍以主辦方答覆為準。

若以前只有入圍、得到特別提名，或舊稱號的性質拿不準，詢問時應附上正式通知與原作品頁。通知中的正式稱號有助於確認適用條款。沒有獲獎紀錄的改版案，仍須核對一般作品資格、推出時間與本次提交範圍。

寄給主辦的詢問資料不必是一份大型簡報。可以先準備舊版連結、這次改版日期，以及一段可核對的功能差異。例如註明原本需要客服代辦的某項變更，現在由使用者自行完成，並附上兩版流程。信中註明此次參賽的版本及類別，並將主辦回覆交給負責上傳的人留存。

另一個需要提前詢問的情況是上市日期。官方報名頁把 Product 寫為已上市或報名後一年內上市的作品；條款則使用當屆競賽年度及兩個曆年的表述。跨年度推出、分階段開放或只有部分客戶已能使用的改版，需要由主辦方說明適用的日期範圍。把原產品上市日、新版推出日與預計全面開放日分別列明，請主辦按本次作品狀態確認。

參賽作品的範圍

假設一款已營運多年的預約 App，這次重做的是改期流程。使用者從收到提醒、查看可用時段，到確認改期，都屬於這次改期流程；會員商城與內容專區則沒有改動。若標題寫成整個平台全面更新，後面卻只能提出改期功能的研究紀錄，作品名稱就超出了資料能說明的範圍。

此時可以先寫一段內部說明：「本次提交涵蓋預約變更，以及使用者與服務人員接收變更資訊的流程；其他既有功能作為使用背景。」這份說明能讓詢問資格與整理資料的人知道，本次提交包含哪些功能。主辦是否接受這個範圍作為獨立作品，仍須確認。名稱、作品描述、示範影片與研究資料，都應圍繞同一個範圍。

除了手機畫面，也要交代改期資料如何傳到店員端。

若使用者在 App 裡看到改期成功，店員端卻仍顯示原時段，就需要查明新時段是否正確傳到店員端。UX Design Awards 的評選準則會看使用情境及幕後參與者，因此應確認本次改動牽涉到哪些人：消費者、櫃檯、排班人員，或負責處理異常的客服。每一方需要看到的資訊不必一樣，但應說明各方何時收到通知，以及資料何時更新。

改版專案可能牽涉不同部門的工作。行銷希望呈現會員經營，產品團隊想談操作效率，資訊部門則想介紹新架構。這些工作各有用途，若沒有共同的使用任務，資料就難以說明這次改版要解決的問題。可以先保留與本次改版直接相關的部分，其餘只用足以理解背景的篇幅交代。

資格確認時，也要如實說明新版哪些功能已可操作。官方接受的作品須涉及數位或電子介面、功能；尚在探索與原型階段的內容，應核對 Concept 的適用條件。填寫時分別標示已上線功能、可操作原型與尚待開發的內容，再依實際狀態選擇類別。

一個實用的檢查方式，是請產品負責人把本次範圍圈在流程圖上，再請實際製作送件素材的人指出每個圈選位置可以用什麼呈現。若某一段只有提案圖，另一段已經有使用紀錄，就分別標明狀態。說明中可分列已完成內容與後續開發方向。

舊新版流程的比較

新版最容易取得的是完成後的畫面；舊版常只剩設計檔，甚至已經被更新覆蓋。準備改版作品時，值得先做的是找回舊版的操作路徑。官方 FAQ 對 redesign 的建議包含交代原版本、主要改善及其支持資料。實際整理時，應讓讀者知道兩版在處理同一件事，否則兩排截圖只有外觀差異。

沿用預約的假設，舊版若從訂單詳細頁開始，新版卻從推播捷徑開始，看起來少了好幾步，起點其實不同。可以保留這種捷徑改動，但要明寫新入口在哪裡、使用者如何收到它，以及沒有收到通知時還能怎麼操作。若只剪出新版最短路線，再用舊版最長路線比較，就無法讓人判斷改善來自何處。

整理前後版本時，可記錄下列項目：

比較位置舊版要保留新版要交代不能省略的條件
任務起點入口與當時已知資訊入口是否改變、資訊是否提前兩版是否從相同情境開始
關鍵決定使用者原本要判讀什麼新增提示、限制或預設值是否把負擔轉給另一位使用者
任務結束完成確認與後續人工處理完成狀態及異常回復方式畫面顯示成功後，預約是否確實變更

拿不到可運作的舊系統時，可以使用當時留存的錄影、畫面與操作文件，並標示版本及日期。若只能重建流程示意，也應說明是依哪一份原始紀錄整理。

比較時也要說明舊步驟原本的用途。某個確認步驟雖然增加一次點擊，可能防止使用者改錯日期；新版若移除它，就要交代誤操作如何被發現、能否取消，以及需要誰協助恢復。把所有刪除都寫成效率改善，會忽略原本用來防止誤操作的設計。關於畫面前後對照的整理，可接續閱讀站內的數位服務流程與例外狀態文章，再按這次改版的任務調整。

若本次主要改的是字體、色彩或元件一致性，也有可以具體交代的內容：哪些狀態原本難以辨識、跨頁用詞怎樣讓人誤解、調整後如何檢查閱讀與操作。UX 評選本來就包含視覺與文字品質。團隊仍要分別確認：送件資料能否說明這些改動改善了哪些操作，以及是否符合舊得獎作品再參賽條件。

研究紀錄與改版成果

分析改版成果時，需要一併查看上線期間的其他變化。預約完成數增加、客服詢問減少，可能同時受到活動、客群、營業規則或系統穩定度影響。若沒有足夠比較條件，分析時應一併說明這些影響因素。

UX Design Awards 的評選準則重視可行性、成果及研究如何影響設計決定。說明改版成果時，應一併交代測試對象、方法與觀察結果。

可以先回到研究紀錄，把受測者、任務、使用版本與測試情境放在一起看。同樣叫「完成預約」，有人從已登入狀態開始，有人需要建立帳號；有人熟悉服務，有人第一次使用。若前後兩次研究包含不同條件，仍能描述各次觀察，只是不能直接拿兩個平均時間當成改版前後差距。

沒有舊版測試資料時，可著重新版的觀察結果。團隊可以陳述新版測試中觀察到的操作問題，說明哪項回饋促成後續修正；至於「比舊版更快多少」，就暫時不下結論。

客服紀錄、實際操作影片與訪談各能回答不同問題。把它們並列時，應說明每份資料回答哪個問題，以及哪些觀察仍待驗證。

以預約改期為例，假設測試發現使用者看見新時段後，仍不確定舊預約是否已取消，研究紀錄就應保留這項觀察。若團隊因此讓確認頁同時列出原時段與新時段，可附上修改後畫面，再記錄後續測試的結果。實際送件說明應填入團隊觀察到的內容，包括修正後仍有人看不懂的地方。

測試結果的說明應包含受測者條件與測試環境。若測試只涵蓋熟悉手機操作的成人，就不宜延伸成各年齡都容易使用；若只測過一般網路情況，也不能保證連線中斷時同樣順暢。把尚未驗證的使用者及場景列出來，有助於評審理解成果範圍，也讓團隊知道下一次研究要補什麼。

回查設計紀錄時，可選一項改動，整理促成修改的觀察、曾比較的方案與採用原因。紀錄中應區分團隊的視覺偏好與使用者實際回饋。

還有一種容易被漏掉的成本：讓顧客少填資料，可能讓服務人員多花時間核對身分或訂單；讓使用者自行改期，可能增加後台處理衝突的工作。若只統計了前台操作時間，說明時就註明這個範圍，並列出尚待觀察的後台工作。

操作影片與研究附件

UX Design Awards 的 FAQ 建議提供短篇操作說明影片，並以研究與開發 PDF 補充設計過程；其中影片建議為 60 至 90 秒，PDF 最多 10 頁。影片長度依內容安排，PDF 則須在頁數上限內。

影片呈現操作過程，附件補充改版理由與研究紀錄。

影片可以示範一次改期操作：使用者臨時無法赴約，打開通知，選擇替代時段，再查看變更結果。容易誤解的步驟可放慢播放，讓人看清畫面提示。短片不必把所有功能選單全部點開。若另有宣傳影片，也應檢查它是否以配樂、標語和快速剪接為主，卻沒有讓評審看到服務如何運作。

研究附件可依問題、觀察、修改與結果的順序整理。放入舊版遇到的問題、觀察條件、採取的調整與目前確認的結果。頁數由內容決定；一張對照圖能解釋的事情，沒有必要切成三頁重複標語。過程中曾放棄的方案，若能說明取捨，也可以簡短保留。例如，團隊若曾放棄自動推薦時段的方案，原因是使用者還須與同行者協調，就可交代這項觀察如何影響最終設計。

涉及介面內文時，英文說明應讓海外讀者讀懂操作，而非只把按鈕逐字翻譯。假設中文按鈕寫「保留」，需要讓人知道保留的是原預約、新時段，還是尚未送出的變更。譯文、影片字幕與附件中的稱呼要一致。若畫面仍保留中文，可在相應位置提供英文解釋，避免關鍵決定只能由熟悉中文的人理解。

資料公開範圍也要逐份確認。官方表單將公開 PR 內容與供評審使用的專案資訊分開，但團隊仍須自己檢查上傳內容及授權。操作錄影可以使用示範帳號，避免把客戶姓名、聯絡方式或訂單資料拍進去。研究摘錄若移除了身分資訊，也要保留理解觀察所需的情境，例如保留受測者執行的任務與遇到的操作問題。

對持續更新的 App，檔名和日期尤其有用。影片、截圖、研究結果與提交說明應註記各自對應的版本。若送件後產品又推出新功能，對外介紹時，應區分當時送評的功能與後來新增的功能。保存提交版本，日後介紹獲獎作品時就能找到當時的截圖與功能說明。

Spring 2027 時程與費用

Spring 2027 的官方徵件期間為 2026 年 9 月 1 日至 11 月 15 日，入圍通知預定 12 月 2 日發出，2027 年 1 月 19 日公開入圍作品，3 月 3 日公布得主。可依截止日安排版本確認、資料整理與翻譯的交件時間。

專業 Product 與 Concept 類別目前每件報名費為 320 歐元，入圍方案為 2,250 歐元，合計 2,570 歐元，均未含增值稅。條款另列入圍通知後七個工作天的書面拒絕期間。

報名前也要確認：誰收通知、誰核准後續費用，以及客戶是否同意該版本被公開。報名與入圍後的費用應一併納入核准範圍。

若主辦已確認資格，而舊新版的差異也能由實際資料支持，就可以把時間用在填報、翻譯與核對。若資格仍有疑問，先把那個問題問清楚；若只有新版畫面，卻找不到原本問題及改動理由，應先補資料或調整送件論點。

曾獲獎的產品還有一項後續安排。官方條款對原得獎作品的變體與後續版本設有標章使用限制，對外使用標章前須確認適用版本。準備再參賽資料時，順便核對公司網站、商店頁與簡報的版本名稱：舊獲獎紀錄應指向當時的作品，本次改動則用目前已確認的事實描述。

開始寫英文送件稿之前，先讓負責人看一份簡短的版本說明：原作品的參賽紀錄、這次改動的任務、可核對的研究與操作資料，以及仍待主辦確認的事項。若還說不清新版改善了哪些操作，可對照兩版錄影，再補上具體的變更說明。確認操作差異與研究資料足以說明本次改動後，再決定送件。