add plans from usability testing: onboarding v2, notifications, live editor

Onboarding UX v2 supersedes the original plan — reworks setup into a
single guided journey with progress bar, forgiving validation, and
contextual prompts for skipped steps.

Notification overhaul replaces floating toasts with inline feedback
and persistent top banners (110+ flash messages audited).

Live site editor is a design exploration for on-site editing with
contenteditable text and live CSS variable injection.

Also adds SEO settings and multiple providers to the roadmap.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/plans/live-site-editor.md

@@ -0,0 +1,152 @@
+# Live site editor
+
+Status: Design exploration
+
+A live, on-site editing experience where admins browse their real shop with an editing overlay. Change theme settings, edit page content, and adjust block settings — all while seeing the result immediately on the actual site.
+
+## Inspiration
+
+Squarespace, Webflow, Shopify's theme customiser. The common pattern: you're looking at your real site, with an editing panel alongside it. Changes apply live. No separate "admin preview" — what you see is what your customers get.
+
+## Core concept
+
+### Edit mode
+
+Logged-in admins see a small floating "Edit" button (or pencil icon) on their shop. Clicking it enters edit mode. This is invisible to regular visitors.
+
+### Layout by screen size
+
+**Mobile / small screens (< 768px):**
+- Full-width site view
+- Tap a block or element to select it
+- Bottom sheet or full-screen overlay slides up with settings for the selected item
+- Swipe down or tap outside to dismiss
+- A small floating toolbar stays visible (edit toggle, undo, save)
+
+**Tablet / medium screens (768px–1024px):**
+- Site view takes most of the width
+- Sidebar slides in from the left or right, narrower (250–300px)
+- Site content reflows to fit
+
+**Desktop / large screens (> 1024px):**
+- Split view: sidebar (350–400px) on the left, live site preview on the right
+- Sidebar has full settings panels
+- Site renders at remaining width, giving a realistic preview
+
+### What's editable
+
+**Theme settings (global):**
+- Preset picker (the 8 existing presets)
+- Colour tokens (primary, surface, text, accent)
+- Typography (font family, sizes, weights)
+- Layout settings (max-width, spacing)
+- Logo, header image, favicon
+
+These already work via CSS custom properties — changes can apply instantly client-side before saving, exactly like the current theme editor.
+
+**Page content (per-page):**
+- Block list: reorder, add, remove blocks
+- Block settings: layout, styling, images — shown in sidebar when a block is selected
+- **Inline text editing**: `contenteditable` for text content within blocks (headings, paragraphs, button labels). Edit directly on the page, changes sync back to block data via LiveView events.
+
+**Page settings:**
+- Title, slug, SEO metadata, publish status
+- Accessible from the sidebar when no block is selected
+
+### Interaction model
+
+1. **Click a block on the page** → block highlights (outline/overlay), sidebar shows that block's settings
+2. **Click text within a block** → enters inline editing mode (`contenteditable`). Sidebar shows block settings alongside.
+3. **Edit in sidebar** → changes apply live to the page (theme via CSS vars, blocks via LiveView re-render)
+4. **Sidebar tabs/sections:** "Theme" (global settings) and "Page" (current page's blocks and settings)
+5. **Save** → persists all changes. Unsaved changes indicator in toolbar.
+6. **Exit edit mode** → removes sidebar/overlay, back to normal browsing
+
+### How it relates to existing features
+
+The current admin already has:
+- **Theme editor** (`/admin/theme`): full theme customisation with preset picker, colour/font/layout controls
+- **Page editor** (`/admin/pages/:id/edit`): block list with drag-and-drop reorder, block settings panels, live preview
+
+The live site editor doesn't replace these — it re-surfaces the same components in a new context. The admin pages remain as the full-featured editing environment. The live editor is the quick, visual, "I just want to tweak this" experience.
+
+**Shared components:**
+- Theme setting controls (colour pickers, font selectors, preset cards)
+- Block settings panels (per block type)
+- Block list with reorder controls
+
+These need to be extracted into standalone components that work in both contexts (admin page and live editor sidebar).
+
+## Technical approach
+
+### LiveView architecture
+
+The live site editor would be a LiveView that:
+1. Renders the actual shop page content (blocks, theme) as the main view
+2. Has a sidebar component (LiveComponent or function component) for editing controls
+3. Manages edit state (selected block, unsaved changes, edit mode on/off)
+
+**Option A: Wrapper LiveView**
+A dedicated LiveView at e.g. `/edit/:path` that wraps the shop page rendering with the editor UI. The shop page content is rendered server-side just like normal, but wrapped in edit-mode markup.
+
+**Option B: Editor overlay on existing shop LiveViews**
+Inject the editor UI into the existing shop LiveViews when the user is an admin in edit mode. Cleaner URL story (you're editing at the same URL) but more coupling.
+
+Option A is probably cleaner for a first pass — less risk of breaking the shop experience.
+
+### Inline text editing
+
+`contenteditable` integration with LiveView:
+
+1. Block text content renders inside a `contenteditable` element with `phx-hook="InlineEdit"`
+2. The JS hook captures changes (on blur or on a debounce) and sends them back as LiveView events
+3. The LiveView updates the block data
+4. Need `phx-update="ignore"` on the contenteditable element to prevent LiveView from overwriting mid-edit
+
+This is achievable but needs careful handling of the LiveView ↔ JS boundary.
+
+### CSS custom property injection
+
+Theme changes already work by injecting CSS custom properties into `<style>` tags. The live editor can use the same mechanism:
+
+1. User changes a theme setting in the sidebar
+2. LiveView updates the CSS custom property value
+3. Browser applies it instantly (no page reload, no re-render needed for most changes)
+4. On save, persist to the database
+
+### Responsive sidebar
+
+CSS-based responsive layout:
+- `@container` queries or media queries to switch between split view and overlay
+- Sidebar as a fixed/absolute positioned element on small screens, part of the grid on large screens
+- Transition animations for sidebar open/close
+
+## Open questions
+
+- **URL routing:** `/edit/*` prefix? Or a query param like `?edit=true`? Or detect from session state?
+- **Permissions:** just the admin user, or could there be collaborator roles later?
+- **Conflict resolution:** what if someone edits in the admin panel while someone else uses the live editor? (Probably fine for single-user MVP, but worth noting.)
+- **Block types that aren't text:** image blocks, product grids, etc. — sidebar-only editing, no inline editing for these?
+- **Performance:** rendering the full shop page inside a LiveView with extra edit UI — any concerns?
+
+## Task breakdown (rough)
+
+This is a bigger feature. Rough phases:
+
+| Phase | Description | Est | Status |
+|---|---|---|---|
+| 1 | Design: sketch 2-3 approaches, pick one | 2h | planned |
+| 2 | Extract shared components from theme editor and page editor | 4h | planned |
+| 3 | Build the editor wrapper LiveView with sidebar shell | 3h | planned |
+| 4 | Theme editing in sidebar (re-use theme controls, live CSS vars) | 3h | planned |
+| 5 | Block list and block settings in sidebar | 3h | planned |
+| 6 | Block selection: click-to-select with highlight on page | 2h | planned |
+| 7 | Inline text editing with contenteditable + phx-hook | 4h | planned |
+| 8 | Responsive layout (split view ↔ overlay) | 2h | planned |
+| 9 | Save/discard/undo flow | 2h | planned |
+| 10 | Edit mode toggle (floating button for admins on shop pages) | 1h | planned |
+| 11 | Polish and testing | 4h | planned |
+
+Total estimate: ~30h
+
+This should be broken down further when we get to implementation. Each phase is roughly a session.

docs/plans/notification-overhaul.md

@@ -0,0 +1,172 @@
+# Notification system overhaul
+
+Status: Planned
+
+Replace floating toast/flash notifications with inline feedback and persistent top banners. Based on usability testing (March 2026) — flash messages overlay UI, auto-dismiss means users miss them, and the overall pattern feels messy.
+
+## Current state
+
+Phoenix flash messages shown as floating toasts. 110+ flash messages across 28 files (65 info, 45+ error). Auto-dismiss after a few seconds. Overlay existing UI content.
+
+## New approach: two layers
+
+### 1. Inline feedback (primary)
+
+Contextual to the field or action. Persistent until the state changes.
+
+- **Success:** green tick/label next to the saved field or action area. E.g. "Saved" next to a settings field after change.
+- **Error:** red border on the field + error text below it. Stays visible until fixed. Bold, clearly coloured, impossible to miss — same visual weight as validation errors.
+- **Loading/progress:** subtle indicator while an async action is in-flight (e.g. "Syncing..." next to sync button).
+
+Best for: form saves, field validation, toggle changes, individual actions.
+
+### 2. Top banner (page-level confirmations)
+
+For actions that affect the whole page or aren't tied to a specific field.
+
+- Bold, clearly coloured background: green for success, red for errors, amber for warnings
+- Non-overlapping: pushes content down (not an overlay)
+- **Persistent until manually dismissed** (click to close) — no auto-dismiss, because users may be looking elsewhere
+- Clear close button (x icon)
+- Positioned at top of the content area, below the header/nav
+
+Best for: "Products synced successfully", "Page saved", "Email provider connected", navigation-result confirmations, operation outcomes.
+
+### 3. No floating toasts
+
+Remove the floating toast pattern entirely. Between inline feedback and top banners, every use case is covered with better UX.
+
+## Migration plan
+
+### Category 1: Form saves → inline feedback
+
+These should become contextual inline confirmations near the action:
+
+| Current flash | Location | Inline replacement |
+|---|---|---|
+| "Theme saved successfully" | Theme editor | Green tick next to save button, brief "Saved" label |
+| "Email settings saved" | Email settings | Green tick/label near save area |
+| "Settings saved" | Provider form | Green tick near save |
+| "Navigation saved" | Navigation editor | Green tick near save |
+| "Page settings saved" | Page editor | Green tick near save |
+| "Metadata updated" | Media library | Green tick on the metadata form |
+| "Product updated" | Product show | Green tick near the field that changed |
+
+### Category 2: Validation errors → inline field errors
+
+Already partially in place via changesets, but some are flash-based:
+
+| Current flash | Location | Inline replacement |
+|---|---|---|
+| "Please enter your API token" | Setup wizard | Red border + error text on the API key field |
+| "Missing required fields: {labels}" | Email settings | Red border on each missing field |
+| "Please enter your Stripe secret key" | Settings | Red border + error on the Stripe key field |
+| "Please fill in all required fields" | Contact form | Red border on each empty required field |
+| "Please enter a valid email address" | Newsletter | Red border + error on email field |
+| "Please enter your email address" | Various | Red border + error on email field |
+| "Password must be at least 12 characters" | Setup recover | Red border + error on password field |
+| "Please enter a shop name" / "email address" | Setup | Red border on the relevant field |
+
+### Category 3: State changes → top banner
+
+These are page-level outcomes, best as persistent top banners:
+
+| Current flash | Location | Banner replacement |
+|---|---|---|
+| "Shop is now live" / "Shop taken offline" | Settings | Green/amber banner at top of settings |
+| "Connected to {provider}!" | Provider form | Green banner on the provider page |
+| "Email provider disconnected" | Email settings | Amber banner |
+| "Stripe connected and webhook endpoint created" | Settings | Green banner |
+| "Provider connection deleted" | Providers index | Green banner |
+| "Page saved" | Page editor | Green banner |
+| "Page deleted" / "Page created" | Pages index | Green banner |
+
+### Category 4: Operation outcomes → top banner
+
+Async or significant operations:
+
+| Current flash | Location | Banner replacement |
+|---|---|---|
+| "Sync started for {name}" | Providers/settings | Green banner with progress note |
+| "Connected! Product sync started in the background." | Setup | Green banner |
+| "Submission retry enqueued" | Activity log | Green banner |
+| "Image uploaded" / "Image deleted" | Media library | Green banner |
+| "Campaign is being sent!" | Newsletter | Green banner |
+| "Test email sent to {email}" | Email settings | Green banner |
+| "Added to basket" | Shop cart | Inline: brief confirmation near the add button or cart icon update |
+| "Removed from basket" | Shop cart | Inline: item visually removed, no separate message needed |
+| "Message sent! We'll get back to you soon." | Contact | Green banner above the form (or replace form with success state) |
+
+### Category 5: Auth/system messages → top banner (keep as-is pattern)
+
+These are inherently page-level and work fine as top banners:
+
+| Current flash | Location | Notes |
+|---|---|---|
+| "Welcome back!" | Login redirect | Green banner on dashboard |
+| "Logged out successfully" | Post-logout | Green banner on login page |
+| "Invalid email or password" | Login | Could be inline under the form, or red banner |
+| "User confirmed successfully" | Email confirm | Green banner |
+| "Your basket is empty" | Checkout | Redirect + banner or inline empty state |
+
+### Category 6: Error/failure messages → inline or banner
+
+| Current flash | Replacement |
+|---|---|
+| "Could not connect — check your API key" | Inline error on the API key field + help link |
+| "Stripe connection failed: {message}" | Inline error near Stripe key field |
+| "Failed to send test email: {reason}" | Inline error near the test email button |
+| "Upload failed" | Inline error near the upload area |
+| "Cannot delete — image is still in use" | Red banner with explanation |
+| "Something went wrong. Please try again." | Red banner |
+
+## Implementation
+
+### Phase 1: Build the notification components
+
+1. **Inline feedback component** — reusable component that shows success/error state next to any action. Props: status (success/error/loading), message, auto-clear timing (optional, for success only after state persists).
+2. **Top banner component** — replaces the current flash component. Pushes content down, persistent until dismissed, coloured by type.
+3. **Remove** the existing floating toast CSS/JS.
+
+### Phase 2: Migrate admin forms (highest impact)
+
+Start with the most-used admin pages:
+- Theme editor
+- Page editor
+- Settings
+- Email settings
+- Provider forms
+
+### Phase 3: Migrate remaining admin pages
+
+- Media library
+- Products
+- Activity log
+- Newsletter
+- Redirects
+- Navigation
+
+### Phase 4: Migrate shop pages
+
+- Cart (add/remove feedback)
+- Contact form
+- Checkout errors
+- Auth flows (login, registration, confirmation)
+
+### Phase 5: Migrate setup wizard
+
+Update the setup flow (ties into the onboarding-ux v2 plan).
+
+## Task breakdown
+
+| # | Task | Est | Status |
+|---|------|-----|--------|
+| 1 | Build inline feedback component | 1.5h | planned |
+| 2 | Build persistent top banner component (replaces flash) | 1.5h | planned |
+| 3 | Migrate admin forms to inline feedback (theme, pages, settings, email, providers) | 3h | planned |
+| 4 | Migrate remaining admin pages (media, products, activity, newsletter, redirects, nav) | 2h | planned |
+| 5 | Migrate shop pages (cart, contact, checkout, auth) | 2h | planned |
+| 6 | Migrate setup wizard notifications | 1h | planned |
+| 7 | Remove old flash/toast CSS and JS | 30m | planned |
+
+Total estimate: ~11.5h

docs/plans/onboarding-ux.md

@@ -1,109 +1,168 @@
-# Onboarding UX improvements
+# Onboarding UX v2
 
 Status: Planned
 
-## Context
+Supersedes the original onboarding-ux plan. Based on usability testing session (March 2026) covering the setup wizard, launch checklist, email provider setup, and general onboarding flow.
 
-The setup wizard and dashboard launch checklist work, but there are gaps that leave new users guessing. Goal: make onboarding totally fool-proof and guided so a non-technical seller can go from zero to live store without confusion.
+## Vision
+
+A non-technical seller should be able to go from zero to a live shop without confusion or frustration. The setup should feel like one cohesive journey, not a scavenger hunt through admin pages. Every step should explain *why* it's needed, be forgiving of mistakes, and never leave the user stranded.
 
 ## Current flow
 
-1. **Setup wizard** (`lib/berrypod_web/live/setup/onboarding.ex`): 3 cards — admin account → provider API key → Stripe connection. Gated by secret in prod, auto-login after account creation.
-2. **Dashboard checklist** (`lib/berrypod_web/live/admin/dashboard.ex`): 5 items with progress bar — sync products, connect Stripe, customise theme, place test order, go live. Visible when `site_live` is false and not dismissed.
+1. **Setup wizard** (`lib/berrypod_web/live/setup/onboarding.ex`): 3 cards — admin account, provider API key, Stripe connection. Gated by secret in prod, auto-login after account creation.
+2. **Dashboard checklist** (`lib/berrypod_web/live/admin/dashboard.ex`): 5 items with progress bar. Visible when `site_live` is false and not dismissed.
 3. **Coming soon page**: blocks public access before launch.
 4. **Setup status** (`lib/berrypod/setup.ex`): `setup_status/0` returns booleans for each milestone.
 
-## Gaps identified
+## What changes
 
-### High priority
+### A. Simplify initial setup to account creation only
 
-#### 1. Dead end after setup wizard
-The wizard ends at Stripe connection with no redirect or next-steps message. User has to figure out where to go.
+The first screen should be dead simple and low-friction: email, password (with confirmation field), shop name. That's it. No provider keys, no Stripe.
 
-**Fix:** After completing the final wizard step, redirect to `/admin` with a flash message like "You're in! Here's your launch checklist." (~30m)
+- Live validation on all fields (email format, password strength/match, shop name not blank)
+- Note under shop name: "You can change this later"
+- On submit: create account, log in, redirect to the guided setup flow
 
-**Files:** `lib/berrypod_web/live/setup/onboarding.ex`
+Email/password correction after this point is just normal admin account settings — no special "go back to setup" needed.
 
-#### 2. No shipping rate setup in checklist
-Checkout requires shipping rates. There's no checklist item for configuring shipping, and no warning that checkout will fail without it. A user could "Go live" with no shipping rates.
+**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, possibly `lib/berrypod_web/live/admin/settings.ex`
 
-**Fix:** Add "Set up shipping" checklist item that links to `/admin/settings` (shipping section). Gate "Go live" on at least one shipping profile existing. (~1h)
+### B. Guided setup flow with progress bar
+
+After account creation, the user enters a single multi-step guided journey. This replaces the current approach of separate admin pages.
+
+**Intro screen** — before any steps, briefly explain what Berrypod does and why you need each thing:
+
+> "Berrypod connects your print-on-demand products to your own online shop. To get fully set up, you'll need three things:
+>
+> - A **print provider** account (like Printify or Printful) to make and ship your products
+> - A **Stripe** account to accept payments from customers
+> - An **email provider** account so your shop can send order confirmations and shipping updates"
+
+Then the steps with a clear progress bar at the top. Each step shows: step number, title, whether it can be skipped, estimated time.
+
+**Steps:**
+1. **Connect print provider** — allow connecting multiple providers (not forced to pick just one). "Skip for now" available.
+2. **Connect Stripe for payments** — "Skip for now" available.
+3. **Set up email provider** — "Skip for now" available.
+
+Each step embeds the same settings UI components that live in the admin pages (shared, not duplicated). The guided flow adds extra context and hand-holding around them.
+
+On completion (or after skipping all): redirect to dashboard with clear status messaging.
+
+**Key UX decisions:**
+- Progress bar visible at all times, showing completed/current/upcoming steps
+- Each step has a "Skip for now" with a brief, non-naggy note about what won't work without it
+- External service links (create Printify account, etc.) open in new tabs with external-link icon and aria label
+- Users can go back to previous steps to correct mistakes
+- If revisiting (e.g. after closing browser), detect existing state via `Setup.setup_status/0` and resume from the first incomplete step
+
+**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, `lib/berrypod/setup.ex`, new shared components
+
+### C. Forgiving API key validation
+
+API key entry should be as forgiving as possible:
+
+- Auto-strip leading/trailing whitespace on paste and submit
+- Validate format where known:
+  - Printify: 36-character UUID format
+  - Printful: specific prefix/length
+  - Stripe: must start with `sk_live_` or `sk_test_`
+  - Email providers: provider-specific format checks
+- Specific, helpful error messages: "This looks too short — Printify API keys are usually 36 characters" rather than generic "Invalid"
+- Validate on blur for fast feedback, not just on submit
+- Link to where to find the key: "Find your Printify API key at Settings > Connections"
+
+**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, `lib/berrypod_web/live/admin/providers.ex`, validation logic in contexts
+
+### D. Email provider setup UX
+
+Rework the email provider selection and configuration:
+
+- **Recommended pick** highlighted at top — whichever has the best free tier, easiest setup, and supports newsletters. One clear "if you're not sure, pick this" option.
+- **Two groups:** "Also sends newsletters" vs "Transactional only" with one-line explanation of the difference
+- **One-liner per provider:** free tier info, setup difficulty ("paste one API key" vs "requires domain verification")
+- **Self-hosted/SMTP** in a collapsible "Advanced" section at bottom
+- **Guided flow after selection:** link to create account (new tab), then "Now enter these settings:" with config fields
+- **Send test email** button after configuration
+- **Remove** the masked key display ("Current: 84159e26•••4f3")
+- **Default from address** to the admin email automatically — don't surface during setup, it's a general settings thing for later
+
+**Files:** `lib/berrypod_web/live/admin/email_settings.ex`, shared components for guided flow
+
+### E. Contextual prompts for skipped steps
+
+When a step is skipped, surface the need where it matters — once per context, never as global nags:
+
+- **Products page** (no print provider): empty state explaining why products are empty, with link to connect a provider
+- **Cart/checkout** (no Stripe): checkout button disabled with explanation and link to connect Stripe
+- **Order detail** (no email provider): note saying "Order confirmation emails aren't being sent. Set up an email provider to send them automatically."
+- **Dashboard checklist**: always shows outstanding items regardless of skips
+
+Principle: explain what's missing, link to the fix, one instance per context.
+
+**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod_web/live/shop/` (various), `lib/berrypod_web/components/`
+
+### F. Dashboard checklist and messaging
+
+Rework the dashboard checklist to match the guided setup flow:
+
+- **Before setup complete:** "Your admin account has been created. Continue the full setup below." with checklist of outstanding items
+- **After all steps done and site live:** "Your shop is live! Ready to go"
+- Checklist item names match the setup wizard step names exactly (no mismatches)
+- Each checklist item links to its admin settings page (for when they return outside the wizard)
+- Help/FAQ links next to items involving API keys or complicated config
+- Collapsible rather than dismissable (can always get it back)
+- Shipping setup and shop settings as additional checklist items (carried forward from v1 plan)
 
 **Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod/setup.ex`
 
-#### 3. No shop settings in checklist
-Shop name, currency, country are critical but not in the checklist. User could go live with "My Shop" as the name.
+### G. Coming soon page fixes
 
-**Fix:** Add "Configure your shop" as the first checklist item, linking to `/admin/settings`. Mark complete when shop name differs from default. (~45m)
+- Fix logo displaying oddly to the side
+- Add a subtle "Admin login" link (footer or corner)
 
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod/setup.ex`
+**Files:** `lib/berrypod_web/live/shop/coming_soon.ex`, associated template
 
-### Medium priority
+### H. External links UX
 
-#### 4. Checklist dismissable and gone forever
-Once dismissed, no way to get it back. Stored as `checklist_dismissed` setting.
+All links to external services throughout the app get:
+- `target="_blank"` + `rel="noopener noreferrer"`
+- Small external-link icon
+- Aria label indicating it opens in a new window
 
-**Fix:** Replace dismiss with a collapse/expand toggle. Or add a "Show launch checklist" link in the dashboard sidebar when dismissed but site isn't live yet. (~15m)
+**Files:** templates throughout `lib/berrypod_web/`
 
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, possibly `lib/berrypod_web/components/layouts/admin.html.heex`
+### I. Input styling — WCAG compliance
 
-#### 5. "Place a test order" has zero guidance
-Links to the shop home page. No mention of Stripe test mode, test card numbers, or what a successful test looks like.
+Increase input field border contrast to meet WCAG AA (3:1 minimum for UI components), aim for AAA. Clear, visible field edges in all contexts.
 
-**Fix:** Add inline help text under the checklist item: "Use card number 4242 4242 4242 4242 with any future expiry and CVC. You'll see the order appear in Orders when it works." (~45m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`
-
-#### 6. Skip completed wizard steps on revisit
-If a user closes their browser mid-setup and comes back, the wizard restarts from scratch (session-based). Should detect existing state and skip completed steps.
-
-**Fix:** In `mount/3`, call `Setup.setup_status/0` and set `current_step` to the first incomplete step. (~1h)
-
-**Files:** `lib/berrypod_web/live/setup/onboarding.ex`
-
-#### 7. Better provider connection error messages
-If the API key is wrong, the error is generic. No link to where to find the key, no troubleshooting.
-
-**Fix:** Add provider-specific help text: "Find your Printify API key at Printify → Settings → Connections" (with link). Show the actual API error when it's user-facing (auth failure vs server error). (~30m)
-
-**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, `lib/berrypod_web/live/admin/providers.ex`
-
-### Low priority
-
-#### 8. Guide theme customisation
-`theme_customised` is true if any setting differs from defaults. Changing one colour counts. No guidance on what to customise.
-
-**Fix:** Add a brief tip under the checklist item: "Upload your logo, pick your colours, and choose a font that matches your brand." (~15m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`
-
-#### 9. Clarify "Sync your products" checklist step
-Links to `/admin/providers` but user needs to click "Sync" on an already-connected provider. Confusing if they connected during the wizard.
-
-**Fix:** If provider is connected but no products synced, link directly to the provider detail page with a prompt to sync. If products exist, mark as complete. (~15m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`
-
-#### 10. Move email setup into checklist as optional step
-The orange "email not configured" banner appears on every page but isn't in the checklist. Email is needed for abandoned cart, order confirmations, contact form.
-
-**Fix:** Add as a non-blocking checklist item (doesn't gate "Go live" but shows as recommended). (~30m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod/setup.ex`
+**Files:** `assets/css/admin/components.css`, `assets/css/shop/` CSS files
 
 ## Task breakdown
 
-| # | Task | Priority | Est | Status |
-|---|------|----------|-----|--------|
-| 1 | Redirect to dashboard after wizard completion with welcome flash | High | 30m | planned |
-| 2 | Add shipping setup to checklist, gate "Go live" on shipping existing | High | 1h | planned |
-| 3 | Add shop settings to checklist (name, currency) | High | 45m | planned |
-| 4 | Make checklist collapsible instead of dismissable | Medium | 15m | planned |
-| 5 | Add test order guidance (test card number, what to expect) | Medium | 45m | planned |
-| 6 | Skip completed wizard steps on revisit | Medium | 1h | planned |
-| 7 | Better provider connection error messages with help links | Medium | 30m | planned |
-| 8 | Add theme customisation tips to checklist | Low | 15m | planned |
-| 9 | Smarter "Sync products" checklist link | Low | 15m | planned |
-| 10 | Add email setup as optional checklist item | Low | 30m | planned |
+| # | Task | Est | Status |
+|---|------|-----|--------|
+| A | Simplify initial setup to account creation only | 1.5h | planned |
+| B | Guided setup flow with progress bar | 4h | planned |
+| C | Forgiving API key validation | 1.5h | planned |
+| D | Email provider setup UX rework | 2h | planned |
+| E | Contextual prompts for skipped steps | 2h | planned |
+| F | Dashboard checklist and messaging rework | 2h | planned |
+| G | Coming soon page fixes (logo + admin link) | 30m | planned |
+| H | External links UX (new tabs, icons, aria) | 1h | planned |
+| I | Input styling — WCAG compliance | 1h | planned |
 
-Total estimate: ~5.5h
+Total estimate: ~15.5h
+
+## Suggested order
+
+1. **A** first — simplify the entry point
+2. **B** — the big piece, the guided flow
+3. **C** — validation improvements (can be done alongside B)
+4. **D** — email provider UX (part of the guided flow)
+5. **F** — dashboard checklist rework (depends on the flow being defined)
+6. **E** — contextual prompts (depends on knowing what's skippable)
+7. **G, H, I** — smaller fixes, can be done any time