Public Service Card & Customer Flows

Service Card — 🔴 Findings logged · Last reviewed 2026-07-19

File: prototype/service-card/ServiceCard.dc.html. The public qrsetu.com/<slug>/service-card page — the platform's core anonymous artifact.

Confirmed strong — the variant mechanism already answers the template-scalability worry

Business vs Individual is a single variant prop swapping one data object (biz/ind) over identical markup. This is exactly the "one structure, re-skinned by data" pattern the templating questions were worried about, confirmed by reading the render logic directly, not inferred. Real <a href> deep-links into ../customer-flows/Book.dc.html, Pay.dc.html, Review.dc.html. Brand rules (gradient "QR" + navy "setu", favicon, "Create your service for free on QR setu" growth CTA) are all present as designed.

Finding — the three uploads/*ServiceCard variants may be handcrafted, not data-driven

uploads/RealEstateServiceCard.dc.html and uploads/YogaTrainerServiceCard.dc.html sit alongside uploads/ServiceCard.dc.html as separate files. If these are separate handcrafted designs rather than the same variant-driven structure with different data, that's the exact anti-pattern the canonical ServiceCard.dc.html already avoids, and it will fragment template maintenance as more business categories are added.

Status: not yet independently confirmed — the three uploads/ files were noted as existing in the file listing but not read in this pass. Needs a direct read before writing a prompt.

Finding — public-page accessibility and performance need a pass

The card renders in a fixed 390px phone-frame with pixel font sizes; some icon buttons have aria-labels but the overall structure hasn't been checked for real responsive/semantic markup suitable for an anonymous, SEO-relevant, CDN-cached production page.

Design-fixable — copy-paste prompt for Claude Designs

Before prototype/service-card/ServiceCard.dc.html is treated as final:

1. Confirm whether uploads/RealEstateServiceCard.dc.html and uploads/YogaTrainerServiceCard.dc.html are meant
   to become new `variant` values consumed by the same ServiceCard.dc.html structure (recommended), or
   separate files. If they must stay separate files for now, at minimum make them share the same underlying
   block/data shape as ServiceCard.dc.html rather than being independently hand-styled, so a future merge into
   one variant-driven file is a data migration, not a rebuild.
2. Add a semantic, responsive layout pass for this screen: it needs to render correctly outside a fixed
   390px phone frame (this is a public, indexed web page, not only a mobile app screen), with real heading
   structure (h1/h2 hierarchy) for SEO, and confirm every icon-only interactive element has an aria-label.
3. Add the missing states: empty gallery (no photos uploaded yet), zero reviews, offer expired, and a
   temporarily-unavailable/paused business state (the business turned off their card temporarily).

Customer flows — ⚪ Not yet reviewed

prototype/customer-flows/Book.dc.html, Order.dc.html, Pay.dc.html, Review.dc.html. Flagged in the initial pass as likely missing failure states (payment decline, booking slot conflict, out-of-stock, review spam/dedupe) based on the flow structure described in the design project's SCREENS.md, but none of the four files have been directly read in this portal-logging pass. Needs a first read before any finding here is treated as confirmed.

Onboarding — ⚪ Not yet reviewed

prototype/onboarding/Onboarding.dc.html. The design project's own SCREENS.md describes it as a linear wizard: welcome → phone/OTP → business-or-individual → category → card basics → plan → success. Whether the "individual" branch is as fully designed as the business branch (the highest-leverage product gap per the locked 2026-07-14 product-vision decisions) has not been confirmed by reading the file directly.