# Splitsy — Wireframe Guidelines (Low-Fidelity, Mobile) **Version:** 1.0 **Date:** July 2026 **Owner:** Dasha (PM) **Scope:** Low-fidelity wireframes for the Splitsy mobile app (iOS + Android) plus web admin. Built in Claude Design. **Language:** All wireframe content and copy is written in **English**. > **How to use this document.** These are the global rules every wireframe must follow. When writing prompts for Claude Design, paste the relevant sections — especially the **State Matrix (§5)**, the **Terminology Glossary (§11)**, and the **Per-Screen Prompt Template (§16)** — so screens stay consistent with each other. Think like a senior UX/UI designer for structure, and like a UX writer for every word on screen. --- ## 1. Design principles (the mindset) 1. **Flow over pixels.** Low-fi is about layout, hierarchy and logic — not visual design. Grayscale, no branding. 2. **Every scenario, not just the happy path.** For each screen we design the full set of states and the negative outcomes (see §5 and §15). 3. **One primary action per screen.** Exactly one primary CTA; everything else is secondary or tertiary. 4. **No dead ends.** Every error or negative outcome states the cause in plain language and offers a clear next step. 5. **Real copy, not lorem ipsum.** Use the actual microcopy so we can validate meaning and text length. 6. **Generic, reusable components.** Nothing golf-specific baked into shared components — the same "activity card" must work for tennis or padel later. --- ## 2. Canvas & frame spec - **Orientation:** portrait only. - **Frame size:** ~375 × 812 (standard phone). Respect the safe area (status bar top, home indicator bottom). - **Persistent chrome:** status bar; bottom tab bar where applicable (Activities · Notifications · Profile). - **Grid & spacing:** consistent spacing scale; do not invent new margins per screen. - **Touch targets:** minimum 44 × 44 px. --- ## 3. Component library (define once, reuse everywhere) Reuse the same components across all screens; do not create variants without reason: - Buttons: primary, secondary, tertiary/text, destructive. - Inputs: text field, field with inline validation error, dropdown/selector, stepper (e.g., player count). - Cards: activity card, booking card, participant/slot row. - Lists & list items; empty-list state. - Modals, bottom sheets, confirmation dialogs. - Toasts / inline banners (success, info, warning, error). - Loaders / skeletons. - Countdown timer (hold deadline). - Cost breakdown block (price + service fee + total). --- ## 4. Navigation, deep links & session - Define back behavior for every screen. - **Deep links:** an invite link opens a specific screen (the participant "You're invited" screen). Design what a **logged-out** user sees when opening it — this depends on the MFA vs. guest-payment decision (client question Q7); wireframe both branches if unresolved. - Make it explicit when a screen requires authentication and what happens if the session is expired. --- ## 5. State Matrix — MANDATORY per screen For **every** screen, design the applicable states. Treat this as a checklist: - **Default / populated** — the normal, happy state. - **Empty** — no data yet (no friends, no bookings, no results). - **Loading** — skeletons/spinners; never a blank screen. - **Error** — network, server, timeout; with cause + recovery action. - **Success / confirmation** — action completed. - **Partial** — e.g., some participants paid, some not. - **Offline / connection lost** — especially mid-payment. - **No permission / access denied** — wrong role or not signed in. If a state doesn't apply to a screen, note "N/A" so we know it was considered, not forgotten. --- ## 6. Accessibility (a11y) - Touch targets ≥ 44 px; adequate contrast even in grayscale. - Support large/dynamic text without breaking layout. - Meaningful labels for screen readers. - **Never rely on color alone.** Payment statuses (paid / unpaid / released) must also carry an icon or text label. - Inclusive, gender-neutral visuals and language (per PRD: ~40% of new golfers are women). --- ## 7. Payment & trust UX - **Fee transparency:** show every fee as a separate line **before** payment (share + Splitsy service fee [+ processing fee if applicable] + total), on both organizer and participant screens. - **Hold vs. charge:** use precise language. When we authorize, say the card is "held", not "charged". State when the actual charge happens. - **Confirm before charge;** show a receipt/summary after. - **Trust cues:** "Powered by Stripe", "We never store your card details". - Clear states for: card declined, insufficient funds, retry. --- ## 8. Time-sensitive UX - Show the **hold deadline** as a visible countdown on the booking. - Reminder patterns (24h and 4h before expiry). - Dedicated states for: deadline passed, slot released, invitation expired. --- ## 9. Feedback on every action - Every action produces visible feedback (toast, banner, or state change): invite sent, card added, payment held, booking cancelled. - No silent taps. Distinguish optimistic UI from confirmed results. --- ## 10. Microcopy / UX writing rules - **Tone:** clear, warm, human, confident. Short sentences. Plain words a first-time user understands. - **Buttons are verbs / actions:** "Pay my share", "Send invites", "Add card" — not "OK" / "Submit". - **Benefit-oriented, not technical:** explain what the user gets or must do next. - **Consistency:** use the glossary (§11) everywhere; the same concept always gets the same word. - **Error messages:** say what happened, why (briefly), and what to do next — no codes, no blame. - **Empty states** motivate the next action ("No friends yet — add one to invite them faster next time"). --- ## 11. Terminology glossary (use these exact words) - **Organizer** — the person who creates the booking and pays first. (Not "booker/host".) - **Participant** — an invited player who pays their share. (Not "guest/friend" in system copy.) - **Share** — the amount one participant owes. - **Slot** — one place in a booking. - **Hold / held** — a temporary authorization on the card (money not yet taken). - **Charged / captured** — the actual charge after the group is confirmed. - **Service fee** — the Splitsy fee, shown separately. - **Deadline** — the time by which all shares must be paid. - **Released** — an unpaid slot returned to the venue. - **Venue / provider** — the business hosting the activity (the golf club). --- ## 12. Formatting rules - **Money:** USD, symbol + 2 decimals ($42.00). Always show the currency context. - **Dates/times:** consistent, human format (e.g., "Sat, 12 Jul · 8:30 AM"). - **Timezone:** always the **venue's local time**, never the device timezone. Label if there's any ambiguity. - **Numbers of people:** "You + 3 others", "2–4 players". --- ## 13. Legal & consent surfaces - Terms of Service / Privacy consent at sign-up. - Fee disclosure wherever fees appear (ties to the surcharge/legal question Q4). - Any card-surcharge language only if/when legally cleared. --- ## 14. Fidelity boundaries (what low-fi means here) - Grayscale; placeholder blocks instead of real images; no logo/brand, no final typography. - **Real English copy** (not placeholder text). - Focus reviewers on structure, hierarchy and flow. Add a "Low-fidelity" marker on frames for client presentation. --- ## 15. Negative / edge-case catalog (Splitsy-specific) Design for these across the relevant flows: - Card declined / insufficient funds. - Network loss during payment. - Duplicate payment attempt. - Invitation expired. - Slot already released. - Booking already full. - Participant declines the invite. - Organizer cancels the booking. - Refund in progress. - Venue/provider API unavailable. - Trying to pay after the deadline. - Invited person already has an account vs. is new. - Paying from the wrong account. - Authorization expired before capture. --- ## 16. Annotation & naming convention - **Screen IDs** follow the master list: `A-01 … A-10` (onboarding/account), `B-11 … B-19` (organizer flow), `C-20 … C-22` (participant flow), `D-23 … D-27` (Platform Admin), `E-28 … E-31` (Vendor Admin). - Name each frame `[ID] Screen name — State` (e.g., `B-16 Organizer payment — Error: card declined`). - Add short annotations/notes on each frame and arrows for transitions, so both client and engineering can follow. --- ## 17. Per-screen prompt template (paste into Claude Design) Use this structure when prompting for each screen: ``` Screen: [ID + name] Platform: mobile, portrait, ~375x812, low-fidelity, grayscale, real English copy. Role: [Organizer / Participant / Platform Admin / Vendor Admin] Goal of this screen: [one sentence — the single primary user goal] Primary CTA: [one action] Key elements: [list the components from §3 this screen needs] Content/copy: [headline, body, button labels, empty/error microcopy — plain, human English] States to include: [pick from §5 — default, empty, loading, error, partial, success, etc.] Edge/negative cases: [pick from §15 relevant to this screen] Transitions: [where each action leads] Rules: follow Splitsy Wireframe Guidelines (fee transparency, hold-vs-charge wording, status not by color alone, no dead ends, venue-local time). ``` --- ## 18. Presenting low-fi to the client (kick-off) - **Primary format:** live walkthrough of the clickable HTML prototype (screen-share), walking the client through the flow (sign up → book → invite → pay). - **Leave-behind:** an ordered PDF or slide deck of the screens with short annotations. - **Async:** a short Loom walkthrough (fits the existing weekly-Loom cadence). - **Optional link:** host the HTML (Netlify/Vercel/GitHub Pages) for self-clicking — but for the first showing, guide it yourself. - **Set expectations up front:** state clearly this is low-fidelity — we're reviewing structure and logic, not visuals or colors. Keep a "Low-fidelity" marker on every frame. Hi-fi comes later (Figma).