Alpha 階段如何進行
Alpha 是您嘗試不同解決方案來解決從探索（discovery）階段中發現到的問題。
在 alpha 階段，請花費時間建立原型並測試不同的想法。不要害怕挑戰目前的做法：alpha階段是探索新方法的機會。
您不必對整個更廣泛的使用者旅程（wider user journey）進行原型設計。
譯註：更廣泛的旅程（wider journey）指的是整個使用者體驗或服務所涵蓋的更大範圍。
您甚至可能不想對您正在處理的所有事務或元素進行原型設計：通常只需專注於您認為最具挑戰性的領域是有合理的。就可以完成測試風險最大的假設所需最低限度的工作。
Alpha 服務不應供公眾使用。
使用您想 嘗試的任何線上解決方案，建立足夠複雜的東西來讓您測試不同的想法，而非正式環境品質的程式碼。預期在alpha結束時，您可能會拋棄任何程式碼以及測試過的想法。
譯註：正式環境品質的程式碼意即不複雜的程式碼，正式環境的程式碼通常會要求越簡單越乾淨越不容易出錯。
到 alpha 階段結束時，您應該能夠決定您測試過的哪些想法值得推進到 beta 版。
Alpha 階段通常持續 6 到 8 週。這意味著您應該在 alpha 階段開始後的兩週內預約進行 alpha 評估。
在 alpha 階段，考慮一下您的團隊需要哪些人是很有幫助的。
在您的探索（discovery）階段結束時，如果您認為不值得進行 alpha 測試，這是可以接受的。
專注於測試您最高風險的假設
Alpha 階段的一個關鍵部分是識別並測試風險最高的假設。這些風險是什麼取決於您正在建立的服務。
以您想要解決的問題可能是減少孤獨感和孤立感為例，如果您認為線上資訊服務可能有助於解決該問題，那麼您可能會 優先進行研究，以瞭解您試圖幫助的人們目前如何接收資訊；如果他們根本不使用網際網路，他們就不太可能使用您的服務。
或者，能夠與現有技術整合可能是優先事項。致力於投票登記的團隊意識到他們需要建立一個與 400 多個地方議會的登記系統整合的 API。如果不可能，這項服務就無法發揮作用——這就是他們在 alpha 階段關注的重點。
同樣地，如果您可能的解決方案之一依賴於尋找解決法律限制的方法，您可能需要花費部分 alpha 階段時間來確定其可行性。
在 alpha 階段達到標準
在 alpha 階段，有一些標準您會特別需要密切關注。
為使用者解決整體問題
服務標準的第 2 點表示，您需要努力為使用者解決整個問題。
在 alpha 版本中，這可能意味著顯示：
- 您如何知道您的旅程範圍是正確的
- 您已經瞭解了您的服務所涉及的更廣泛的使用者旅程
- 您對使整個旅程盡可能正常運作所需發生的事情有一個概念（特別是，您能夠談論屬於同一旅程的其他服務，以及更改這些服務所涉及的機會和挑戰）
- 您正在公開工作（Working in the open），並 已開始與負責旅程其他部分的團隊建立關係（如果有必要的話）
譯註：公開進行工作（Working in the open）強調透明度和開放性，通常包括分享和公開許多相關訊息，例如項目進展、決策過程、程式碼和文件。
- 您瞭解影響您的服務的任何法律、合約或技術限制
- 您計劃將使用者向政府提交相同資訊的次數降至最低
正確確定您的旅程的範圍
正確確定交換資料範圍可能是使其易於使用的最重要部分。使用 alpha 階段來探索從使用者的角度來探索具有意義的範圍。
與使用者更廣泛的旅程結合
並非所有交換資料都是更廣泛使用者旅程的一部分。但如果您的交換資料是這樣，您應該在探索階段中探索更廣泛的旅程。
您可以將粗略的旅程地圖（或類似的工具）帶入您的 alpha 評估，顯示您的服務在使用者旅程中的位置、涉及的不同組織以及人們存取不同管道。
如果您風險最高的假設之一是，可以對其他服務進行更改以便為使用者提供簡單、直觀的旅程，請在 alpha 階段，透過與負責這些其他服務的人員交談來測試這一假設。在alpha版本結束時，確保您清楚可以更改哪些內容以及進行這些更改的難度或成本。
如果您面臨跨政府或更廣泛合作的任何阻礙，您需要展示您正如何解決這些問題，例如透過與潛在合作夥伴建立關係。
無論哪種方式，您都應該與與您在同一領域工作的其他人交談並建立關係。一個好的起點是檢查您工作的區域是否有服務社群。
您還應該在 alpha 測試過程中與 GOV.UK 內容團隊取得聯繫。他們將幫助您確定您的交換資料應如何與 GOV.UK 結合。
處理限制條件
在 alpha 階段來探索法律、合約或舊有技術（legacy technology）中不可撼動的限制條件，這些條件將影響您計劃建立的服務。在 alpha 階段結束時，您應該能夠解釋：
- 如何在這些限制條件下建立滿足使用者需求的服務
- 如果這些限制條件是可以長期消除的（例如，透過改變技術平臺或以不同的方式與供應商簽訂合約），組織的計劃如何達成消除這些限制
公開工作（Working in the open）
在 alpha 階段，您應該繼續公開談論您正在建立的原型以及您從中學到的東西。例如，透過部落格文章和公開展示和講述。作為其中的一部分，請考慮如何與作業交付同事分享您所學到的知識。
盡可能重複使用使用者資訊
通常的情況是，在與相關服務互動時，使用者已經向政府提供了您所需要的相同資訊。
使用 alpha 階段來調查是否可以重複使用該數據，以便使用者在從一個任務轉移到另一個任務時不必多次提供相同的資訊。除非有公共政策、信任或法律原因不共用數據，否則您將需要展示您正在朝向共用數據方向努力。
提供跨不同管道的整合體驗
服務標準的第 3 點表示，您的服務需要在使用者可能用來存取它的所有管道上正常運作。
這涉及瞭解您的服務的線上和離線部分如何連接在一起，以及使用者因此遇到的任何痛點。
在 alpha 階段，您可以透過以下方式努力實現這一目標：
- 在 alpha 階段實驗和使用者研究中包含離線元素，如字母，特別是在涉及風險假設的情況下（例如，您將能夠更改字母的內容）
- 考慮在協力廠商或非政府組織內開始的使用者旅程，例如轉介
- 邀請營運交付同事參與 alpha 階段——他們將對最高風險的假設有一個非常有用的視角
確保每個人都可以使用您的服務
對於線上原型，您無法在正式環境的程式碼中測試所有的無障礙技術。但在 alpha 階段，您應該能夠展示您：
- 瞭解 WCAG 無障礙性原則-這將幫助您識別和測試您的服務可能面臨的任何特定無障礙性挑戰
- 將身心障礙人士納入您的使用者研究中
您不必在 alpha 階段進行無障礙性稽核，但值得開始考慮它，因為他們可能需要時間來安排。如果您在 alpha 期間指定稽核員，他們可以審查您的 alpha 設計或原型是否存在潛在的無障礙性問題，從而為您提供充足的時間來解決問題。
不管怎樣，在 alpha 版本結束時，您應該制定一個計劃來解決 beta 版的無障礙性問題。
您還應該能夠展示您已經考慮了更廣泛意義上的包容性。這意味著：
- 您已經考慮過特定人群在存取該服務時是否可能會遇 到痛點（例如，如果您要求提供某人的永久位址，而您的使用者包括無家可歸者，您就需要證明您已經制定了計畫來防止他們被排除在外）
- 包括在使用者研究中對數位化信心較低的人
- 您已經開始考慮如何為需要線上幫助的人設計輔助數位支援模型
決定是否進入 beta 階段
當您擁有足夠強大的原型來幫助您決定是否進入 beta 階段時，alpha 階段就完成了。
要進入 beta 階段，您需要確定：
- 您可以創造出滿足使用者需求並且具有成本效益的東西
- 您將擁有交付所需內容所需的預算和人員——這包括研究預算
您應該能夠使用您在探索階段結束時確定的成功指標來解釋您是如何做出此決定的。
如果您的 alpha 階段結束了，但您不確定自己可以做這些事情，您可以完全停止或決定重複探索階段或 alpha 階段。
當您確信想要進入 beta 階段時，您的交付經理和服務所有者應該開始製定測試版業務提案。這應該包括您的測試團隊中需要哪些人的資訊。
Alpha 需要考慮的其他事項
在 alpha 階段，您還需要考慮其他一些事情。您需要表明您已經開始考慮：
-
您希望在 beta 階段選擇的程式設計工具類型，以及為什麼您認為它有這個價值
-
您將如何識別對服務的威脅、如何處理它們以及如何及時瞭解威脅
-
您將如何開源程式碼——以及如何透過離線管道分享您的方法和流程
-
您是否要使用通用平臺
-
如果您的服務的線上部分出現技術問題，您的使用者將受到怎樣的影響
您還應該繼續完善用於衡量服務成功程度的指標。
如果您建立了任何新的設計模式 - 或學到了跟現有設計模式有關的任何有用資訊——請透過 GOV.UK 設計系統分享您的心得