·10 分鐘閱讀

Google Stitch Web App 設計指南

用 Google Stitch 設計 Web App：頁面結構、儀表板與到達頁版面、響應式元件、提示詞範例，以及從設計到程式碼的完整工作流程。

S
Stitch Prompt Team
Content Team
提示詞設計風格工作流程

Web App 不是「多了一個登入按鈕的到達頁」。它有導覽、權限、資料表格、表單、設定、空狀態與響應式版面。只要提示詞描述的是產品結構，而不只是視覺風格，Stitch 就能產生一版可信的初稿。

本文聚焦讓 Web App 真正可用的頁面與系統：七類核心頁面、主要版面模型、可重複使用的提示詞公式，以及從設計到程式碼的交付。

Web App、到達頁與行動 App 的差別

到達頁只有一個轉換目標，說一條線性的故事。Web App 支援反覆發生的任務，因此需要導覽、狀態、資料密度與權限。行動 App 優先觸控、單手操作與短工作階段。如果用同一套結構提示三者，至少有一個會出錯。

在提示詞第一句寫清楚載體，然後寫頁面類型。因為即使在同一個產品裡，「儀表板」與「設定」需要的元件也完全不同。

每個 Web App 都需要的七類頁面

登入與註冊

登入、註冊、重設密碼與驗證。版面保持簡單，主動作要明顯，並涵蓋錯誤與載入狀態。

引導流程

只收集產品交付第一個有用結果所需的資訊。用進度提示、一步一個決策，並給使用者跳過或返回的出口。

儀表板

儀表板用於掃描與比較。優先放少量指標、一條趨勢，以及進入待處理工作的路徑。不要把它變成產品裡所有圖表的陳列櫃。

列表與表格

列表需要排序、篩選、分頁、列選取、批次操作與清楚的空狀態。表格要能承載真實資料，同時保持可讀。

詳情頁

詳情頁要回答三個問題：這是什麼、發生了什麼、下一步能做什麼。主動作保持可見，次要動作分組收納。

設定與帳務

設定頁管理身分、偏好、團隊權限與付款。用清楚的分區、安全的預設值，並對破壞性操作做確認。

空狀態與錯誤狀態

新帳號是空的，網路會失敗，權限會改變。主動設計這些狀態，而不是讓介面直接崩掉。

Web App 的版面系統

側邊欄 + 內容區

最常見的 SaaS 版面：固定導覽、帶搜尋與帳號操作的頂欄，以及可在列表、詳情與設定之間切換的內容區。它很適合資訊密度高的產品。

頂部導覽

適合較簡單的 Web App 與偏行銷的產品。內容區更寬，但分區與角色一多就會擁擠。

分欄檢視

適合收件匣、客服工具，以及需要「列表 + 詳情」對照的情境。左欄負責選取，右欄負責脈絡與操作。

響應式斷點

先從 1440px 開始，再檢查 1280px、1024px 與 768px。收起側邊欄、減少表格欄位、把次要操作收進選單。產生多尺寸之前，先讀 Stitch 的裝置類型說明。

Web App 提示詞公式

每個頁面都用這個結構，把方括號替換成產品細節。

Design a [web app type] for [audience].
Page: [page type] whose primary job is [job].
Navigation: [sidebar / top nav / split view].
Layout: [columns, density, max width].
Components: [table, filters, forms, charts, modals].
States: [loading, empty, error, success, permission denied].
Style: [design system or visual direction].
Constraints: [breakpoints, accessibility, data volume].

這個公式把頁面、導覽與狀態放進同一則提示詞。它通常決定你得到的是「好看的 mockup」，還是「能用的應用介面」。

儀表板提示詞範例

Design a B2B analytics web app dashboard for a customer support platform.
Page: dashboard; primary job is to show queue health and surface the most urgent conversations.
Navigation: left sidebar with Inbox, Analytics, Team, Settings; top bar with date range and search.
Layout: 12-column grid, four KPI cards, two charts, and a conversation table below.
Components: KPI cards, line chart, stacked bar chart, sortable table, filter bar.
States: loading skeletons, empty queue, error banner, permission-denied state.
Style: clean SaaS interface with neutral surfaces and one blue accent.
Constraints: 1440px first, responsive to 1024px; table must remain scannable.

到達頁提示詞範例

Design a landing page for a developer tool that turns API logs into dashboards.
Audience: backend engineers at small SaaS teams.
Primary goal: start a free trial.
Sections: hero with code sample, three feature blocks, integration logos, pricing preview, FAQ, final CTA.
Style: technical editorial, monospace accents, restrained color, generous whitespace.
Constraints: mobile-first; one primary CTA repeated; no stock-photo hero.

到達頁不是 Web App，但同一個產品可能兩者都需要。保持視覺系統一致，同時改變導覽與資訊密度。

元件與狀態

表格是大多數 Web App 成敗的關鍵。寫清楚排序、篩選、分頁、批次操作、欄位優先順序，以及沒有資料時會發生什麼。表單需要標籤、驗證、錯誤提示、成功回饋與明確的主按鈕。彈窗與 toast 應該留給決策與短回饋，而不是塞進本應獨立成頁的內容。

向 Stitch 要狀態，而不只是「順利路徑」。一則包含載入、空、錯誤與權限狀態的提示詞，會產出更完整的介面，也更早暴露版面問題。

保持頁面一致

寫一段共享的提示詞前綴，包含產品、使用者、風格規則與限制。然後每個頁面重複使用同一套顏色、字體、間距、圓角與元件詞彙。頁面偏離時，修共享限制，而不是靠提示詞繞過去。

Stitch 的變體可以幫助測試版面替代方案，同時不改變視覺系統。要涵蓋更大的系統，可以把設計規則寫進 DESIGN.md，在多個畫面與程式碼代理程式之間重複使用。

從設計到程式碼

Web App 設計只有能被開發者實作才有價值。先保證版面乾淨、元件命名清楚、狀態有文件。然後把 Stitch 的 HTML、React 或 Tailwind 結果當作起點，上線前再檢視。

匯出能力見下載產物，終端工作流程見 CLI 教學，在程式碼庫與設計系統之間往返見從程式碼到設計的工作流程。

QA 檢查清單

交付 Web App 頁面前，檢查：

  • 是否只有一個主動作與清楚的頁面標題；
  • 導覽是否匹配使用者角色與任務；
  • 表格或列表在 1024px 下是否仍然可讀；
  • 是否涵蓋載入、空、錯誤、成功與權限狀態；
  • 表單是否有標籤、驗證與確認；
  • 顏色、字體、間距與圓角是否一致；
  • 是否為下一個斷點準備了響應式方案；
  • 是否有重複或衝突的操作。

常見問題

Stitch 適合複雜後台嗎？

它適合做版面、層級與視覺方向的第一版。複雜後台仍然需要真實的資料建模、權限與可用性測試。用 Stitch 探索與對齊，再用使用者驗證。

如何產生響應式 Web App 頁面？

先產生桌面版面，再要求同一頁面在 1024px 與 768px 下的具體變化：收起側邊欄、減少表格欄位、卡片堆疊。不要假設 AI 會自動推斷每個斷點。

如何把 Web App 設計匯出成程式碼？

使用 Stitch 的匯出選項，並檢視產生的 HTML、React 或 Tailwind 結果。把它當作起點，再套用你的架構、無障礙與測試標準。需要可重複的流程時，使用 SDK 或 CLI。

下一步

如果需要更完整的設計流程，閱讀 Google Stitch AI UI 設計指南。也可以瀏覽 Web App 風格、試用編輯器，或依照教學系統練習。

← ← 返回部落格