Appearance

Foundational Screen Prompts ​

Grounded, drift-free briefs for the core foundation of QRSETU. Each brief reflects the actual current implementation in the codebase plus the intended behavior, so the design team can create production-ready screens that engineering can build as-is. Read the Screen Coverage Mandate first, and apply the global rules from the PDPR Design Prompt to every screen below.

Which of these are actually built is tracked, and gated, elsewhere

This page briefs screens for design. Whether an approved design has been implemented is the Screen conformance ledger (npm run check:screens) — the machine source of truth, added 2026-08-13 after nine approved merchant-mobile screens were found unimplemented with nothing in the repo recording it. Do not infer implementation status from this page.

Applies to every brief on this page

Design each screen for both platforms (native mobile via Expo, and the installed-app desktop experience). Consume tokens only, never hardcoded colors. The current code hardcodes brand values (golden #FFE591, coral #FF6A3C or #FF6A3C, navy #213A57, and many gray shades). In the design system these become tokens: golden saffron primary, coral secondary, navy ink. Keep the 3XL rounded signature (the code already uses large rounded shells and softer inner panels). Design all states: empty, loading, success, error, permission, edge cases. Do not use em dashes.

Screen inventory (foundation) ​

This table describes the RETIRED Vite SPA, and the per-screen briefs below inherit that

The routes (/dashboard/*), the guards and the Edge Functions named in the Reads / writes column are from the SPA retired to legacy/ by ADR-0011. manage-profile and manage-settings were archived on 2026-08-09 because they wrote tables the ADR-0020 baseline dropped (QRS-445). Treat this inventory as the ORIGINAL foundation set, not as the current surface — architecture/current-state is the authority on what exists.

Per-feature specs that supersede or extend the briefs below live as their own pages and are the current source of truth for those features:

FeatureSpec
Store / Catalogue (merchant)Store / Catalogue Spec
Public Setu Card (customer)Public Setu Card Spec
Consumer Marketplace (category 3)Consumer Marketplace Spec
Consumer identity + Marriage Biodata (context, round 1)Consumer Context Prompt
Marriage Biodata editor - drawers and field controls (round 3)Biodata editor drawer prompt
Marriage Biodata reader - photograph viewing and the opening block (round 4)Biodata reader photo prompt
Admin Panel MVP - staff sign-in, Access control, Users, Leads, Overview (round 1)Admin Panel round 1 prompt
Admin Panel MVP - what round 1 left open, and the owner's three decisions (round 2)Admin Panel round 2 prompt
Admin Panel MVP - the last copy and presentation fixes (round 3)Admin Panel round 3 prompt
Account holds - the public and account-holder views of a suspended or blocked account (round 1)Account holds round 1 prompt
Jewellery rates & schemes (vendor + customer)Jewellery Rates & Schemes Spec
Onboarding (first-run)Onboarding Experience Spec
Profile / Settings / Onboarding fieldsProfile / Settings / Onboarding Spec
Affiliate programAffiliate Program Spec
Direct seller vertical (agent journey + Meetings / Leads / Media Library modules)Direct Seller Vertical Spec
Communication Hub (admin panel, WhatsApp channel mission control)Communication Hub Spec
Setu Card templates (manifest authoring, not a screen)Template Authoring
ScreenRouteStatusReads / writes
Landing page/ImplementedStatic, plus client-side QR generation
Sign up/signupImplemented (Google disabled)Supabase Auth signUp
Login/loginImplemented (Google disabled)Supabase Auth signIn, password reset
Password reset requestmodal on loginImplementedSupabase Auth reset email
Update password/update-passwordPlanned or partial (redirect target exists)Supabase Auth update
Admin login/admin/loginImplementedAuth + profiles.role check
Onboarding/onboardingImplemented (business-first)validate-user-input EF, manage-profile EF
Default dashboard/dashboard/homeImplemented (menu-centric)useDashboardData
Profile/dashboard/profileImplementedmanage-profile EF, validate-user-input EF
Settings/dashboard/settingsImplementedmanage-settings EF, manage-account EF
Authenticated app shellwraps /dashboard/*ImplementedNavigation, guards

Status reflects the codebase today. "Planned" items still need requirements before design.

1. Landing page ​

Route: /. Public marketing page. Also the entry point that routes signed-in users to /dashboard/home.

Sections (in order): header with navigation, hero, live QR generator, features, pricing, testimonials, blog highlights, FAQ, footer, and a floating WhatsApp action.

QR generator (interactive, client-side): the hero generator supports these QR types, which must all be represented: URL, Contact, Email, SMS, WiFi, Location, Event, Payment, Social Media, Menu, Business Card, Coupon, App Download, Video, Document. Include a type picker, a form that adapts to the chosen type, a live preview, and download and share actions.

Features section: Instant Generation, Advanced Analytics, Secure and Reliable.

Primary calls to action: Sign up, and Login for existing users. Pricing should reflect the freemium model (free tier with ads, paid tiers remove ads and unlock advanced features), but do not invent specific prices unless documented.

States: default, QR generated, QR generation error or invalid input, and a loading state for the preview. Design the header for both a wide desktop layout and a native or compact mobile layout.

Notes: this is a marketing surface, so it may read more like a premium product site than the installed-app shell, but it must still use tokens and the brand language. Signed-in visitors are redirected away from this page.

2. Sign up ​

Route: /signup. Two-column card on a neutral background: form on one side, a rotating image carousel on the other (four lifestyle images, auto-advancing, with indicator dots).

Copy: title "Create an Account", subtitle "Start your journey with QR Setu".

Fields and actions:

  • Continue with Google button. It is present but currently disabled. Design both an enabled and a disabled state, and treat Google sign in as planned, not active.
  • Email (required).
  • Password (required, minimum 6 characters, shown with a hint).
  • Create Account button (loading label "Creating account...").
  • Link to Login for existing users.

Behavior: on success, show a confirmation message "Check your email for the confirmation link" and route to Login to wait for email confirmation.

States: default, submitting, field validation error, auth error (toast), and the email confirmation success message. Design the mobile layout as a single column with the carousel above or hidden.

3. Login and password reset ​

Route: /login. Same two-column card and carousel pattern as sign up.

Copy: title "Welcome Back", subtitle "Login to continue to QR Setu".

Fields and actions:

  • Continue with Google button, currently disabled (design enabled and disabled states, treat as planned).
  • Email (required).
  • Password (required), with a "Forgot Password?" trigger beside the label.
  • Login button (loading label "Logging in...").
  • Link to Sign up.

Behavior: on success, all users (including admins) route to /dashboard/home. The admin panel is reached only through the dedicated admin login.

Forgot password (modal): title "Reset Password", one Email field, and a "Send Reset Link" action (loading label "Sending..."). On submit it sends a reset email. Design the modal and its sending and sent states.

Update password screen (/update-password): this is the reset-link target. Requirements are not yet documented, so produce a brief and flag it: it should take a new password and a confirm password, validate them, submit the update, and show success then route to login. Mark as an open question until confirmed.

States: default, submitting, invalid credentials error (toast), and the redirect transition (do not flash the form after success).

4. Admin login ​

Route: /admin/login. Dedicated, noindex administrator entry. Two-column card: form on one side, a branded panel on the other with a QR icon, "QR Setu", "Admin Portal", and a short line about secure administrative access.

Copy: title "Admin Portal", subtitle "Secure access for system administrators only".

Fields and actions: Email, Password with a "Forgot Password?" trigger (admin reset modal titled "Reset Admin Password"), a "Login to Admin Portal" button, and a link "Not an administrator? Go to User Login".

Behavior and states: authenticate, then verify the account has an admin or super admin role. If the account is valid but not an admin, sign out and show an inline "Access Denied" alert. Design the inline error alert state ("Authentication Failed" with a message), the submitting state, and the success transition to the admin area. This screen must feel secure and restrained.

5. Onboarding ​

Route: /onboarding. A five-step wizard in a large rounded card centered on a warm gradient background. Shows a segmented progress bar with check markers and a "Step X of 5" label. Each step animates in horizontally. Business-first today (see the note at the end).

Steps:

  1. About you. Heading "Welcome! Let's get started", subtitle "What should we call you?". Fields: Full Name (letters and spaces, minimum 2), and Mobile Number with a country-code selector (options include +91, +1, +44, +49) and a 10 digit number.
  2. Brand. Heading "Tell us about your brand". Field: Brand Name (letters, numbers, spaces, minimum 2).
  3. Industry. Heading "What's your industry?", subtitle "We'll tailor features to your business type". Field: Business Domain, a searchable dropdown loaded from the business domains list, each option showing a name and a short description, with a search box and an empty "No domains found" state.
  4. Location. Heading "Where are you based?". Field: Country selector, defaulting to the default country.
  5. Unique URL. Heading "Choose your unique URL", subtitle "This will be your profile's web address". Field: Slug (lowercase letters, numbers, hyphens, 3 to 30 characters). It runs a live availability check (debounced) and shows checking, available, and unavailable states, a clear affordance, and a preview line "Your website will be available at: qrsetu.com/your-slug".

Navigation: Previous and Next buttons, and on the final step a "Complete Setup" button (loading label "Setting up..."), enabled only when the whole form is valid.

Completion: on submit, save the profile and mark onboarding complete, then show a celebration screen. Design the celebration and its error fallback.

States per step: default, inline validation error (with an alert icon and message), the slug checking, available, and unavailable states, the submitting state, and the celebration state.

Important planned variant (open question, must be designed): onboarding is business-first today (brand, industry, and slug are required). QRSETU also serves individuals with no business. Design a personal or skip-business path so an individual can complete a minimal onboarding (for example name only) and reach a generic dashboard without a business profile. Flag the exact minimal fields as an open requirement.

6. Default dashboard ​

Route: /dashboard/home. The landing screen after login. Data comes from a dashboard data hook (bio pages, QR codes, stats, digital menu stats, whether digital menu is enabled, business domain id, and subscription data).

Current implemented content:

  • Welcome hero at the top, aware of the user's business domain.
  • Digital Menu section (conditional on the digital menu being enabled): a heading "Digital Menu" and a grid of six stat cards, each with an icon, a value, a label, and an action: Active digital menus (Create New), Menu Categories (Manage), Dishes and drinks (View All), Hidden Menu Categories (View), Hidden Dishes and Drinks (View), Today's Special (View).
  • Below the stats, two placeholder panels: "Recent Orders" (empty state "No recent orders found", "Real-time order tracking coming soon") and "Top Performing Items" (empty state "Data insufficient", "Add items to see what's popular").
  • No active plan modal: for a free user on the relevant domain with no active plan, a blocking modal titled "No Active Plan" that invites the user to contact support, showing WhatsApp and Email contact rows and a response-time note. Design this modal and its dismissable and blocking behavior.

Planned content (design as future states): a top stats row (Card views, QR scans, Enquiries), primary action cards (Add a product, Share my card, Create a QR), and a recent-activity list. Design these so they can be turned on without a redesign.

⚠ Corrected 2026-08-08. This paragraph previously specified BioLinks, Service Cards, Create Website, Recent BioLinks — a stats row and action cards for two retired products. BioLink was retired in favour of the Setu Card (QRS-172) and its tables are deleted; the Studio website builder is out of scope. A dashboard tile counting BioLinks must never be designed.

⚠ And the stats row alone does not satisfy the brief. A row of numbers is a display of information, which the proactive-value gate rejects by name. The dashboard's primary content is an action item derived from stored state — "3 products have no photo, and products with photos get more enquiries", "Ganesh Chaturthi is in 3 weeks, refresh your card with the festival template" — dismissible, quiet-hours-aware, and never fabricated when the read model cannot support the claim.

States: loading (skeletons for the stat cards and lists), the digital-menu-enabled layout, a first-run or zero-data layout for a brand new user, and the no-active-plan blocking modal. Because the dashboard adapts by what the user has enabled and by plan, define these variants explicitly.

Consumer note (category 3): design a completely different dashboard for an individual with no business — bookings they have made, orders they have placed, vendor subscriptions they hold, saved businesses; later discovery and recommendations. Not a thinned-out merchant dashboard, and not "generic tools (QR generator, BioLink, digital card, forms)", which is what this note used to say. A consumer has zero workspace memberships, so merchant features are not applicable rather than locked — showing them greyed out teaches the user the app is not for them. Flag the exact composition as an open requirement; this screen does not exist yet and goes through Claude Design first.

7. Profile ​

Route: /dashboard/profile. A header card plus a four-tab form. Writes go through the profile edge function, with input validation.

Header card: avatar with upload, the brand name (or "Your Brand"), a subscription tier badge, the email, and an "Active" status badge.

Tabs:

  1. Basic Information. Owner Name (required, up to 30 characters) and Mobile Number (up to 10 digits). Save Changes button with validating and saving states.
  2. Business Details. Brand Name, Business Industry, City, State, Pin Code, and GSTIN. These are currently read-only in this tab. Design a read-only presentation and, as a planned state, an editable version, and flag which fields become editable as an open question.
  3. Business Hours. A seven-day hours editor (per-day open and closed times), with a loading skeleton for seven rows.
  4. Social Media. Links for Instagram, Facebook, Twitter, LinkedIn, YouTube, and WhatsApp.

States: loading (a full profile skeleton), per-section loading (lazy sections with skeletons), validating, saving, per-field validation errors, a section error boundary state ("Something went wrong, unable to load this section"), and saved success feedback.

Generic-audience note: for an individual with no business, the Business Details and Business Hours tabs may be hidden or replaced with personal fields. Flag as an open requirement.

8. Settings ​

Route: /dashboard/settings. Title "Settings", subtitle about preferences, account security, and billing. Three tabs.

Tabs:

  1. General. Account preferences, including default currency and advertising preference (these are the settings the general settings service manages). Design each preference control with its saving state and confirmation.
  2. Security. Two groups. Change Email: Current Email, New Email Address. Change Password: Current Password, New Password, Confirm New Password. Design validation, submitting, success, and error states for each.
  3. Danger Zone. Delete Account, with a clear, explicit confirmation flow (Cancel and Delete Account actions) that states the consequences plainly. This maps to the account and data deletion requirement, so treat it as a careful, non-accidental destructive flow.

States: loading (settings skeleton), saving a preference, a section error boundary state ("Section Unavailable, we couldn't load this settings section"), and the destructive confirmation and its progress and result.

Note: account and data deletion must follow the privacy guidance in the PDPR. Make public versus private and destructive consequences unmistakable.

9. Authenticated app shell and navigation ​

Wraps: all /dashboard/* routes. This is not a single screen but the frame every dashboard screen sits inside, so it must be designed for both platforms.

Desktop: a persistent app shell with a refined sidebar for primary areas, a quiet top bar for context and account, and a spacious content area. Include a command surface for power users if approved.

Mobile: native navigation, a bottom tab bar for primary areas, and native stack transitions for depth. Contextual actions use bottom sheets.

Requirements to confirm (open): the exact set of primary navigation destinations (for example Home, My Card, Store, QR, Profile, Settings) differs by which features resolve as applicable for that merchant's industry, and differs entirely for a consumer. Flag the final navigation model as an open requirement and design it to adapt without a redesign.

⚠ Corrected 2026-08-08: this list used to read Home, Digital Menu, BioLink, Website, QR, Profile, Settings — three of which are retired or out of scope. It also said navigation varies "by what the user has enabled", which is the wrong mental model: the user does not enable features. Applicability is derived from their industry's primitive composition, entitlement comes from their plan, and availability from release flags. Design the tab bar to render a resolved set, never a user-managed one.

Open questions to resolve before or during design ​

These are the gaps found while grounding these briefs. Each must be answered rather than assumed:

  1. The minimal personal or skip-business onboarding path and its exact fields.
  2. The generic-mode dashboard composition for individuals.
  3. Which Business Details fields become editable in Profile, and when.
  4. The update password screen requirements.
  5. The final primary navigation model for the app shell across business and generic modes.
  6. Confirmed pricing for the landing pricing section.

Log confirmed answers back into these briefs, then design. Do not fill these gaps with generic assumptions.

  • Desktop Journey Readiness - measured 2026-08-20: the merchant desktop console (16 screens) and desktop marketplace (3) are designed, the consumer desktop tier does not exist, and check:screens is blind to all 19.

Receptionist (car dealership) ​

⭐ Receptionist screen specification — a design REQUEST, not a pull: 🧮 search space established 2026-08-24 across both ledgers plus five keyword variants, and no Receptionist screen exists in either Claude Design project.

⚠ One constraint outranks the rest and is worth reading even if you never touch this screen: the paper register it replaces takes about ten seconds, so it is the only screen in the vertical that can fail by being merely slow. If logging a walk-in is slower than the book, the receptionist keeps the book and every downstream dealership screen is fed by nothing.

📘 Two owner decisions are baked in: the receptionist captures and suggests, never assigns, and they get no personal Setu Card (the desk gets a reassignable touchpoint QR instead).