網路是令人驚豔的平台，不論是使用何種裝置，都能觸及全世界的使用者。這類產品易於使用及共用，不必安裝任何程式但最重要的是，這是一個開放生態系統，任何人都可以使用或建構。
目前有些應用程式無法在開放網路上建構及提供。這就是所謂的「應用程式差距」。網路上潛力無窮的 原生可能和原生的不足我們想填補缺口。我們認為網頁應用程式應該具備原生應用程式的強大功能，
如何設計及導入這些新功能？
我們開發了這套流程，是為了設計及開發新的網路平台功能，讓使用者能夠在現有的標準程序中，快速設計及開發符合開發人員需求的新網路平台功能，最重要的是。這與我們開發其他所有網路平台功能的方式並無不同，而是著重開發人員的意見回饋。
開發人員的意見回饋十分重要，有助於我們確保提供的功能正確無誤，但如果整個流程的後期有所調整，就很難改變課程走向。因此，我們提早開始徵求意見回饋。如果及早收到可做為行動依據的技術和用途意見回饋，就能輕鬆修正或停止開發作業，而不會因缺乏周全或實作不當的功能而造成問題。在 WICG 開發的功能並非無法變更，且您的輸入內容將大幅影響其演進方式。
值得注意的是，許多想法絕對不會超過說明或來源試用階段。這個程序的目標是寄送適當的功能。這表示我們需要快速學習並反覆改進。拒絕提供功能 因為無法解決開發人員的需求為了實現這個學習目標，我們採用了下列程序 (不過由於意見回饋，使用者經常會重新排列步驟中的某些步驟)：
找出開發人員的需求
第一步是找出並瞭解開發人員的需求。開發人員希望達成哪些目標？誰會使用？他們今天的做法如何？ 這項新功能還可以解決哪些問題或困擾。一般而言，這些功能會由開發人員提出功能要求，通常是透過 error.chromium.org 提供的錯誤回報。
建立說明
確定新功能的需求後，請建立說明 (基本上是用於說明問題的設計文件)，以及一些說明 API 運作方式的程式碼範例。此說明是一份持續運作的設計文件，只要新功能不斷演進，就會經歷大量疊代作業。
取得意見回饋並反覆改進說明內容
當說明具備合理的清晰程度後，就可以發布說明、徵求意見回饋，並反覆改進設計。您可以藉此機會確認新功能符合開發人員的需求，並以預期的方式運作。這是收集公開支援並驗證實際需要這項功能的機會。
將設計移至規格並反覆測試
一旦說明狀態處於良好狀態，設計工作就會轉成正式規格，與開發人員和其他瀏覽器廠商合作，以疊代及改善設計。
等到設計開始穩定後，我們通常會使用來源試用來實驗實作結果。來源試用可讓您邀請實際使用者試用新功能，並對實作方式提供意見。這些實際回饋有助於塑造及驗證設計，確保我們在納入標準前，能夠得到正確的結果。
寄送
最後，來源試用完成後，規格就已確認完成，其他所有啟動步驟也都已完成，就可以將版本運送到穩定版了。
考量使用者安全性、隱私和信任
其中部分功能一開始可能令人感到驚慌，在原生實作方面更是如此。不過，網路的本質比原生使用者來得安全，開啟網頁時也不應令人害怕。
在預設情況下，不應授予任何存取權，但這類模型依賴的是讓使用者能完全掌控且易於撤銷的權限模型。但必須清楚瞭解這些 API 的使用時機和使用方式。我們在「控管強大 Web Platform 功能存取權」一節中概述了幾個思維流程。