mark/vibn-frontend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
vibn-frontend/prd-template/campreg-ui-requirements.md

39 KiB
Raw Permalink Blame History

CampReg + CampMatch UI Requirements

Version: 0.1
Date: 2026-06-01
Scope: Desktop SaaS, parent mobile, staff mobile, provider mobile, CampMatch-to-CampReg marketplace flows
Related Documents: campmatch-campreg-master-prd.md, campreg-provider-os.md, campreg-mobile-experience.md, campreg-api-and-integrations.md, vibnai-growth-automation.md

1. Purpose

This document defines the user interface requirements for CampReg and the connected CampMatch ecosystem.

CampMatch is the parent-facing discovery and matching layer. CampReg is the provider-facing registration, operations, payments, forms, attendance, communication, and growth layer. VibnAI and the Missinglettr API power provider growth automation.

The UI must be designed as a modern, mobile-capable SaaS product for three primary user groups:

  1. Parents / Guardians — discover, compare, register, pay, complete forms, receive communications, and manage their child’s camp experience.
  2. Kids / Campers — represented through parent-controlled profiles, interests, matching preferences, needs, attendance, and feedback.
  3. Providers — camps, schools, clubs, coaches, recreation organizations, youth programs, and activity providers who manage listings, registrations, operations, payments, communications, staff, and growth.

The UI must support two connected but distinct product surfaces:

  • CampMatch: public marketplace and parent discovery experience.
  • CampReg: authenticated SaaS operating system for providers, parents, and staff.

2. Reference Products and Lessons

The UI should reference the market without copying any competitor directly. The goal is to learn from established patterns and then design a more modern, clearer, mobile-first experience.

2.1 Campium

Campium positions itself around registration, billing, attendance, medication tracking, communication, reporting, parent portal, and mobile apps. Its product architecture reinforces that camps need one system that connects registration, payments, attendance, health data, and family communication.

UI lessons:

  • The provider UI needs strong module separation: registration, billing, attendance, communication, reporting, health.
  • Parents need a portal that clearly shows balances, outstanding forms, announcements, and payments.
  • Medication and health workflows need restricted, visually distinct access.
  • Reporting should be easy to filter and export.

CampReg implication:

CampReg should use a modular SaaS navigation model but make the flows feel more modern, faster, and more mobile-aware than traditional camp management tools.

2.2 CampMinder

CampMinder is a mature camp management platform with API services positioned around moving camp data into tools like spreadsheets, marketing platforms, dashboards, and accounting/reporting systems.

UI lessons:

  • Mature camps often have multiple systems and need integration visibility.
  • Data syncs, API connections, and exports should be visible to non-technical admins.
  • Camp data is operationally valuable and should be surfaced in useful dashboards.

CampReg implication:

CampReg should have an Integrations and API area that feels like a first-class product surface, not a hidden enterprise add-on.

2.3 CampSite

CampSite offers camp management workflows and makes API access available as a paid integration capability. Its API references include families, campers, enrollment, medical, financial, bunking, transportation, and staff-related data.

UI lessons:

  • The underlying data model must support complex camp operations.
  • UI modules should map cleanly to API resources.
  • Administrators should be able to reason about families, campers, sessions, forms, payments, bunking, transportation, and health as connected objects.

CampReg implication:

The UI should make the relationship between family, camper, session, registration, payment, forms, attendance, and communication visible from any relevant screen.

2.4 UltraCamp

UltraCamp emphasizes flexible registration, parent dashboards, mobile-friendly design, custom payment plans, group checkout, document centers, authorized pickups, communication, reporting, check-in/out, medication recording, POS, store deposits, and multi-language support.

UI lessons:

  • Registration must be flexible enough for different provider workflows.
  • Parent dashboards must centralize reservations, payments, documents, upcoming charges, and required tasks.
  • Mobile-friendly design is table stakes.
  • Check-in/check-out must be extremely fast and operationally safe.
  • Multi-child and group checkout flows are important.
  • Documents and forms should be organized in a clear task-oriented way.

CampReg implication:

The parent UI should be task-driven, not database-driven. The staff UI should be action-driven, not admin-heavy.

2.5 ACTIVE Network

ACTIVE’s camp/class products focus on online registration, e-signature, secure payment processing, attendance tracking, marketing tools, merchandise/store functionality, reporting, transaction history, and exports. ACTIVE also has a public developer platform, although the public-facing API is more useful as a discovery/reference pattern than a full camp operations API.

UI lessons:

  • Program search, activity listing, registration, checkout, and merchandise add-ons are established flows.
  • Reporting needs to support filtering, sorting, grouping, and export.
  • Add-ons such as meals, merchandise, transportation, or extended care should be purchaseable during registration.

CampReg implication:

CampReg registration should support add-ons natively, and CampMatch discovery should be structured enough that program/session data can be syndicated or exposed through API endpoints.

2.6 eCamp Open Source

The eCamp project is an open-source camp/course planning app focused on planning activities, schedules, printable plans, mobile access, autosave, and camp/course structure.

UI lessons:

  • Camp planning requires calendar, timetable, activity, and print-friendly views.
  • Autosave reduces friction in complex planning workflows.
  • Mobile access matters during camp operations, not just before camp.

CampReg implication:

When CampReg expands into activity scheduling, the UI should borrow the planning metaphors from camp-specific tools like eCamp: timetable, printable plan, daily schedule, activity blocks, and role assignments.

2.7 Hi.Events / Attendize Open Source

Hi.Events and Attendize are open-source event registration/ticketing systems. They provide useful references for event creation, checkout, ticketing, custom questions, attendee management, QR-based check-in, reporting, webhooks, products/upsells, offline payments, and event dashboards.

UI lessons:

  • Event setup wizards can make complex configuration manageable.
  • Checkout should be simple, fast, and confidence-building.
  • QR check-in can work through web-based scanning rather than requiring a separate native app at first.
  • Webhooks and integrations should be part of the operator experience.
  • Event dashboards should surface registration velocity, revenue, attendance, and conversion.

CampReg implication:

CampReg should treat programs/sessions like richer, child-centered events: each has capacity, dates, price, forms, questions, add-ons, staff, roster, waitlist, attendance, communications, and reporting.

3. UI Product Surfaces

CampReg/CampMatch requires the following UI surfaces.

3.1 Public CampMatch Marketplace

The public parent-facing discovery experience.

Includes:

  • Homepage
  • Search results
  • City pages
  • Category pages
  • Camp/provider profile pages
  • Session/program detail pages
  • Comparison views
  • Saved camps
  • Parent sign-up/sign-in
  • Lead capture
  • Registration entry points

3.2 Parent Portal

Authenticated parent experience connected to CampMatch and CampReg.

Includes:

  • Family dashboard
  • Child profiles
  • Saved camps
  • Recommendations
  • Registrations
  • Payments
  • Forms
  • Documents
  • Waivers
  • Waitlists
  • Schedules
  • Messages/announcements
  • Authorized pickups
  • Emergency contacts
  • Notification preferences

3.3 Provider Desktop SaaS

Authenticated provider admin experience.

Includes:

  • Provider dashboard
  • Listings
  • Programs and sessions
  • Registration builder
  • Forms builder
  • Family CRM
  • Camper records
  • Payments and ledgers
  • Attendance
  • Waitlists
  • Communication
  • Staff
  • Health/medication
  • Reports
  • Growth automation
  • Integrations/API
  • Settings

3.4 Staff Mobile Experience

Mobile-first field operations interface for staff.

Includes:

  • Today view
  • Session roster
  • Check-in/check-out
  • Authorized pickup verification
  • Emergency contacts
  • Allergy/medical flags based on permission
  • Incident reporting
  • Attendance notes
  • Announcements
  • Tasks
  • Offline/degraded-mode support for critical data

3.5 Provider Mobile Experience

Mobile admin companion for owners/directors.

Includes:

  • Enrollment snapshot
  • Revenue snapshot
  • Attendance snapshot
  • Underfilled sessions
  • Urgent notifications
  • Broadcast communication
  • Approval tasks
  • Listing/growth suggestions
  • Campaign approvals

4. Global UI Principles

4.1 Needed Means Included

The product will not use a traditional “P0/P1/P2” priority model in this PRD. If a workflow is required for a complete, credible camp operating system, it is in scope. Phasing can still be handled in build plans, but the PRD should document the complete needed product.

4.2 Mobile Is a First-Class Experience

The system must not treat mobile as a shrunken desktop app. Parent and staff mobile experiences should be designed around real moments:

  • Parent browsing camps on a phone.
  • Parent registering one child while waiting in a car.
  • Parent uploading a document from their phone.
  • Parent receiving an urgent weather or pickup update.
  • Staff checking in 80 children quickly.
  • Staff verifying an authorized pickup at the gate.
  • Staff accessing emergency information in the field.
  • Provider approving a marketing campaign from mobile.

4.3 Camp CRM at the Core

Every UI should reinforce that CampReg is not just a registration form. It is a CRM around families, children, providers, sessions, and engagement history.

Every relevant screen should make it easy to answer:

  • Who is this family?
  • Which kids are attached to this family?
  • What have they registered for?
  • What have they paid?
  • What forms are outstanding?
  • What communications have they received?
  • What is their history with this provider?
  • What did they discover through CampMatch?

4.4 Safety and Trust Over Cleverness

For child-related workflows, health data, payments, and pickup authorization, clarity beats creativity. UI states must be unambiguous. Dangerous actions must be confirmed. Sensitive data must be permission-gated.

4.5 Reduce Repeated Data Entry

Parents should not repeatedly enter the same child, contact, medical, emergency, or payment data. Providers should not repeatedly build the same forms, schedules, or messages.

4.6 Use Wizards Where Configuration Is Complex

Use step-by-step builders for:

  • Provider onboarding
  • Listing claim
  • Program/session setup
  • Registration flow setup
  • Form builder
  • Payment plan setup
  • Campaign creation
  • API/webhook setup

4.7 Use Dashboards for Ongoing Monitoring

Use dashboards for:

  • Provider health
  • Registration velocity
  • Revenue
  • Forms completion
  • Attendance
  • Underfilled sessions
  • Waitlists
  • Campaign performance
  • Operational alerts

4.8 Use Tables for Operational Control

Use dense, filterable tables where providers need to manage many records:

  • Families
  • Campers
  • Registrations
  • Payments
  • Sessions
  • Forms
  • Staff
  • Attendance records
  • Waitlists
  • Messages
  • Incidents

Tables must support filtering, saved views, columns, search, bulk actions, export, and permission-aware visibility.

4.9 Use Cards for Parent Discovery

Use cards for browsing and comparison:

  • Camp cards
  • Session cards
  • Saved camp cards
  • Recommendation cards
  • Child match cards

4.10 Design for Seasonal Urgency

Camp operations have spikes. The UI must surface time-sensitive work clearly:

  • Registration opening day
  • Payment due dates
  • Form deadlines
  • Waitlist openings
  • Session start dates
  • Drop-off and pickup windows
  • Weather/emergency communications
  • Underfilled weeks
  • Staffing gaps

5. Visual and Interaction Style

5.1 Brand Feel

CampMatch should feel warm, trustworthy, local, parent-friendly, and kid-centered.

CampReg should feel modern, operational, efficient, and confidence-building.

The combined system should avoid feeling like enterprise HR software. It should feel like a modern vertical SaaS product designed for busy humans.

5.2 Layout Style

Provider desktop SaaS:

  • Left-side primary navigation.
  • Top bar with organization switcher, search, notifications, help, and user menu.
  • Main workspace with cards, tables, builders, and detail panels.
  • Right-side contextual panel where useful for selected records.
  • Breadcrumbs for nested workflows.

Parent portal:

  • Dashboard-first layout.
  • Child selector or family overview.
  • Clear outstanding tasks.
  • Mobile-first cards.
  • Minimal admin language.

Staff mobile:

  • Bottom navigation or simple tab structure.
  • Large touch targets.
  • Minimal typing.
  • Fast status changes.
  • Clear color/status states.
  • Offline/degraded indicator.

5.3 Typography

Requirements:

  • High readability on mobile.
  • Large enough labels for field use.
  • Strong hierarchy between page title, section title, card title, metadata, and action text.
  • Avoid dense paragraphs in task-heavy screens.

5.4 Status Patterns

Use consistent status badges across the product.

Examples:

  • Draft
  • Published
  • Open
  • Full
  • Waitlist
  • Enrolled
  • Pending Payment
  • Paid
  • Payment Failed
  • Forms Complete
  • Forms Outstanding
  • Checked In
  • Checked Out
  • Absent
  • Needs Review
  • Approved
  • Declined
  • Expired
  • Synced
  • Sync Failed

5.5 Empty States

Every core module needs useful empty states that teach the next action.

Examples:

  • No sessions created → “Create your first session.”
  • No registrations yet → “Share your CampMatch listing or open registration.”
  • No saved camps → “Start searching for camps.”
  • No forms required → “Add forms if parents need to complete waivers, medical info, or permissions.”
  • No campaigns → “Let VibnAI suggest a campaign to fill open spots.”

5.6 Loading and Saving States

Requirements:

  • Autosave for long forms and builders.
  • Draft state for registration flows and campaigns.
  • Clear save confirmation.
  • Prevent accidental loss.
  • Show sync status for integrations.
  • Background processing feedback for imports, exports, and campaign generation.

6. Provider Desktop SaaS Information Architecture

6.1 Primary Navigation

Recommended provider desktop navigation:

  1. Dashboard
  2. Listings
  3. Programs & Sessions
  4. Registrations
  5. Families & Campers
  6. Payments
  7. Attendance
  8. Forms & Documents
  9. Communications
  10. Staff
  11. Health & Incidents
  12. Reports
  13. Growth
  14. Integrations
  15. Settings

6.2 Dashboard

The provider dashboard should answer:

  • Are we filling our sessions?
  • Are we collecting payments?
  • Are parents completing forms?
  • Is anything operationally urgent today?
  • Are any sessions underperforming?
  • Are there actions VibnAI recommends?

Required dashboard sections:

  • Enrollment summary
  • Revenue summary
  • Registration velocity
  • Open capacity
  • Upcoming sessions
  • Forms outstanding
  • Payment issues
  • Waitlist summary
  • Today’s attendance snapshot
  • Urgent alerts
  • VibnAI recommendations
  • Recent activity

Required interactions:

  • Filter by season.
  • Filter by location.
  • Filter by program/session.
  • Click through to underlying records.
  • Export key dashboard data.
  • Dismiss or resolve alerts.

6.3 Listings

Providers use Listings to manage how they appear on CampMatch.

Required screens:

  • Listings overview
  • Listing detail editor
  • Media gallery
  • Categories/interests
  • Location and service area
  • Ages/grades served
  • Schedule/date summary
  • Pricing summary
  • Provider verification status
  • SEO preview
  • CampMatch preview
  • Claim/ownership status
  • Listing performance

Required fields:

  • Camp/provider name
  • Short description
  • Long description
  • Activities/categories
  • Age range
  • Grade range
  • Location
  • City/region
  • Photos
  • Logo
  • Contact info
  • Website
  • Registration mode
  • Safety/trust information
  • Inclusion/accessibility notes
  • Refund/cancellation summary

Required actions:

  • Save draft
  • Preview listing
  • Publish changes
  • Request verification
  • Sync programs/sessions to listing
  • Launch growth improvement workflow

6.4 Programs & Sessions

Programs are offerings such as “Soccer Camp,” “Art Camp,” or “Leadership Camp.” Sessions are specific date/time/capacity instances.

Required screens:

  • Program list
  • Program detail
  • Session list
  • Session calendar
  • Session detail
  • Capacity view
  • Pricing/add-ons view
  • Staff assignment view
  • Registration settings

Program fields:

  • Name
  • Description
  • Category
  • Tags/interests
  • Age/grade eligibility
  • Default location
  • Default pricing
  • Default forms
  • Default add-ons
  • Default refund policy
  • Listing visibility

Session fields:

  • Session name
  • Program
  • Dates
  • Times
  • Location
  • Capacity
  • Waitlist capacity
  • Price
  • Deposit requirement
  • Payment plan availability
  • Add-ons
  • Staff assigned
  • Forms required
  • Registration open/close date
  • Status

Required interactions:

  • Create program
  • Create session
  • Duplicate session
  • Bulk edit sessions
  • Calendar view
  • Capacity indicators
  • Publish/unpublish
  • Open/close registration
  • Sync to CampMatch
  • Export roster

6.5 Registration Builder

The registration builder is one of the most important desktop SaaS flows.

Required builder steps:

  1. Select program/session scope.
  2. Define eligibility rules.
  3. Configure price, deposit, payment options.
  4. Add required parent/camper data.
  5. Attach forms, waivers, uploads, and signatures.
  6. Configure add-ons.
  7. Configure waitlist rules.
  8. Configure confirmation emails and next steps.
  9. Preview parent registration flow.
  10. Publish.

Required UI patterns:

  • Stepper navigation.
  • Live preview.
  • Autosave.
  • Validation checklist.
  • Draft/published state.
  • Warning before publishing incomplete flows.
  • Version history for major changes.

Required registration settings:

  • Registration open date
  • Registration close date
  • Capacity
  • Waitlist behavior
  • Deposit/full payment/zero deposit
  • Payment plan schedule
  • Discount/coupon support
  • Sibling/group registration
  • Required forms
  • Required documents
  • E-signatures
  • Confirmation message
  • Cancellation/refund policy

6.6 Forms & Documents

Required screens:

  • Forms library
  • Form builder
  • Form submissions
  • Document upload requirements
  • Waiver templates
  • Signature records
  • Completion dashboard

Form builder requirements:

  • Text fields
  • Number fields
  • Date fields
  • Dropdown
  • Multi-select
  • Checkbox
  • Radio buttons
  • File upload
  • Signature field
  • Paragraph/instruction blocks
  • Section grouping
  • Required/optional settings
  • Conditional logic
  • Parent/camper/staff target
  • Reusable templates
  • Autosave
  • Preview

Completion dashboard:

  • Completion by session
  • Completion by family
  • Missing forms
  • Incomplete forms
  • Approved/rejected forms
  • Bulk reminder action

6.7 Families & Campers CRM

Required screens:

  • Families table
  • Family profile
  • Camper profile
  • Timeline/activity history
  • Communication history
  • Registration history
  • Payment history
  • Form status
  • Notes
  • Tags/segments

Family profile must include:

  • Guardians
  • Children
  • Contact details
  • Emergency contacts
  • Authorized pickups
  • Balance
  • Registrations
  • Forms/documents
  • Communications
  • Notes
  • CampMatch source/referral history

Camper profile must include:

  • Name
  • Age/date of birth
  • Grade
  • Interests
  • Needs/preferences
  • Registrations
  • Attendance history
  • Forms
  • Medical/allergy flags based on permission
  • Authorized pickups
  • Incidents based on permission
  • Notes based on permission

Required interactions:

  • Search family/camper
  • Add note
  • Send message
  • View registration
  • View payments
  • View forms
  • Merge duplicate family
  • Export record
  • Restrict sensitive fields

6.8 Payments and Ledgers

Required screens:

  • Payments dashboard
  • Family ledger
  • Invoices
  • Transactions
  • Payment plans
  • Failed payments
  • Refunds
  • Discounts/coupons
  • Financial aid/scholarships
  • Reconciliation/export

Required UI behavior:

  • Every family has a ledger.
  • Every invoice links to registration/session.
  • Every payment links to payer, method, processor, invoice, and ledger entry.
  • Refunds require confirmation and reason.
  • Failed payments create clear follow-up tasks.
  • Staff with permission can make manual adjustments.
  • Adjustments require audit notes.

6.9 Attendance

Required screens:

  • Daily attendance
  • Session attendance
  • Check-in/check-out mode
  • Absence list
  • Late pickup list
  • Attendance reports

Desktop requirements:

  • Filter by date/session/location/group.
  • Bulk mark present/absent.
  • See check-in/check-out timestamps.
  • See staff attribution.
  • Export attendance.
  • Print roster.

Mobile requirements are defined separately in this document.

6.10 Communications

Required screens:

  • Message composer
  • Audience builder
  • Templates
  • Campaigns
  • Announcements
  • Message history
  • Delivery status
  • Parent replies/contact records if supported

Audience builder filters:

  • Session
  • Program
  • Enrollment status
  • Payment status
  • Form status
  • Waitlist status
  • Attendance status
  • Age/grade
  • Location
  • Tags
  • Custom fields

Channels:

  • Email
  • SMS
  • Portal announcement
  • Push notification where available
  • Missinglettr-powered campaign distribution for growth content

6.11 Staff

Required screens:

  • Staff directory
  • Staff profile
  • Role assignments
  • Schedule/shift assignments
  • Staff forms
  • Staff documents
  • Staff mobile access settings

Required interactions:

  • Invite staff
  • Assign role
  • Assign session/group
  • Restrict data access
  • Deactivate staff
  • View activity logs

6.12 Health, Medication, and Incidents

Health data must be permission-gated and visually separated from general camper data.

Required screens:

  • Health dashboard
  • Medication list
  • Medication schedule
  • Dispense log
  • Incident reports
  • Allergy/medical flags
  • Health notes
  • Health exports

Medication requirements:

  • Medication name
  • Dosage
  • Frequency
  • Instructions
  • Start/end dates
  • Parent-provided source
  • Staff-entered notes
  • Dispense timestamp
  • Dispensing staff member
  • Missed/overdue state
  • Exportable log

Incident requirements:

  • Incident date/time
  • Camper
  • Staff reporter
  • Location
  • Type
  • Description
  • Actions taken
  • Parent notified
  • Follow-up required
  • Attachments
  • Permission restrictions

6.13 Reports

Required report categories:

  • Registrations
  • Revenue
  • Payments
  • Attendance
  • Forms
  • Waitlists
  • Families/campers
  • Programs/sessions
  • CampMatch attribution
  • Growth/campaign performance
  • Health/medication exports based on permission

Report builder requirements:

  • Select data source
  • Choose columns
  • Apply filters
  • Group/sort
  • Save view
  • Export CSV/XLS/PDF where appropriate
  • Schedule delivery in later versions

6.14 Growth / VibnAI

The Growth section should be a core provider UI, not a hidden AI gimmick.

Required screens:

  • Growth dashboard
  • Opportunities
  • Campaign recommendations
  • Listing improvement suggestions
  • Campaign drafts
  • Missinglettr campaigns
  • Local SEO/content ideas
  • Underfilled session campaigns
  • Reactivation campaigns
  • Approval queue
  • Campaign performance

Required opportunity types:

  • Underfilled session
  • High search demand / low supply
  • Past families not re-registered
  • Listing missing photos
  • Listing missing age range
  • Poor conversion from listing to registration
  • Waitlist demand suggests adding a session
  • Payment/form friction causing drop-off

Required interactions:

  • Review recommendation
  • Edit AI-generated content
  • Approve campaign
  • Send to Missinglettr API
  • Schedule campaign
  • Track performance
  • Dismiss recommendation

6.15 Integrations and API

Required screens:

  • Integrations overview
  • Missinglettr connection
  • Stripe/payment connection
  • Email/SMS provider connection
  • Webhooks
  • API keys
  • Data exports
  • Sync logs
  • Integration errors

API UI requirements:

  • Create/revoke API keys
  • Name API keys
  • Scope API keys
  • Display last used time
  • Display webhook events
  • Retry failed webhook
  • View sync status
  • Provide developer docs link

6.16 Settings

Required settings groups:

  • Organization profile
  • Locations
  • Users and roles
  • Permissions
  • Branding
  • Billing/payment processor
  • Notification settings
  • Registration defaults
  • Form templates
  • Privacy/compliance settings
  • Data export/deletion settings
  • API/integrations

7. Parent Mobile and Web Portal Requirements

The parent experience must work fully on mobile web. A native app may come later, but the web experience must be good enough that parents can complete the lifecycle from phone.

7.1 Parent Dashboard

Required sections:

  • Children overview
  • Upcoming camps/sessions
  • Outstanding tasks
  • Payment due
  • Forms due
  • Messages/announcements
  • Saved camps
  • Waitlist status
  • Recommended camps

Dashboard principles:

  • Show what needs action first.
  • Use plain parent-friendly language.
  • Avoid admin terms like “ledger entry” or “session object.”
  • Make next steps obvious.

7.2 Child Profiles

Required fields:

  • Name
  • Age/date of birth
  • Grade
  • Interests
  • Activity preferences
  • Skill level
  • Schedule needs
  • Medical/allergy info where appropriate
  • Emergency info
  • Authorized pickups
  • Past registrations
  • Saved preferences

Parent-controlled kid matching inputs:

  • Interests
  • Things they want to try
  • Things they do not enjoy
  • Skill level
  • Social preference
  • Indoor/outdoor preference
  • Energy level
  • Accessibility/support notes
  • Friend/sibling considerations

7.3 Camp Search and Discovery

Required mobile/web features:

  • Search by location
  • Search by date
  • Search by age/grade
  • Search by interest/category
  • Search by price
  • Search by schedule type
  • Search by provider
  • Map/list toggle where useful
  • Save camp
  • Compare camps
  • View match reasons
  • View availability
  • View registration mode

7.4 Camp Detail Page

Required sections:

  • Hero image
  • Camp name
  • Provider name
  • Location
  • Age/grade range
  • Dates/times
  • Price
  • Availability
  • Description
  • Activities
  • What kids will do
  • What parents need to know
  • Safety/trust info
  • Refund/cancellation info
  • Provider contact
  • Reviews/testimonials where available
  • Sessions
  • Register/save/share actions

7.5 Parent Registration Flow

Required steps:

  1. Select child or create child profile.
  2. Confirm eligibility.
  3. Select session/program.
  4. Choose add-ons.
  5. Complete required information.
  6. Complete forms/waivers/uploads.
  7. Review price, deposit, payment plan, and policies.
  8. Pay or submit registration depending on mode.
  9. Receive confirmation and next steps.

Requirements:

  • Must support multiple children.
  • Must support returning family prefill.
  • Must autosave progress.
  • Must be mobile-friendly.
  • Must show progress.
  • Must make outstanding tasks clear.
  • Must support parent consent and e-signature.

7.6 Payments

Parent payment UI must show:

  • Balance due
  • Due dates
  • Deposit paid
  • Upcoming payments
  • Payment plan
  • Receipts
  • Refunds
  • Failed payment alerts
  • Payment method

Actions:

  • Pay now
  • Add/update payment method
  • View receipt
  • Download invoice
  • Contact provider about payment

7.7 Forms and Documents

Requirements:

  • Show outstanding forms.
  • Show completed forms.
  • Allow mobile form completion.
  • Allow upload from phone camera or files.
  • Allow e-signature.
  • Autosave long forms.
  • Reuse prior answers where permitted.
  • Show provider approval/rejection if required.

7.8 Communications

Requirements:

  • View announcements.
  • Receive email/SMS/push where supported.
  • Notification preferences.
  • Session-specific messages.
  • Urgent alerts visually distinct from normal updates.
  • Provider contact options.

7.9 Authorized Pickups and Emergency Contacts

Requirements:

  • Add authorized pickup.
  • Edit authorized pickup.
  • Remove authorized pickup.
  • Add relationship and phone.
  • Optional photo in later versions.
  • Emergency contact management.
  • Clear warning that changes may affect pickup permissions.
  • Audit trail for provider.

7.10 Waitlists

Requirements:

  • Show waitlist status.
  • Show next action when spot opens.
  • Allow payment/registration completion when promoted.
  • Show deadline to accept spot if provider sets one.

8. Staff Mobile Requirements

Staff mobile is a dedicated operating experience. It must not expose full admin complexity.

8.1 Staff Mobile Home / Today View

Required sections:

  • Assigned sessions today
  • Roster count
  • Check-in status
  • Urgent notes
  • Medical/allergy flags count based on permission
  • Tasks
  • Announcements
  • Emergency contacts shortcut

8.2 Roster View

Requirements:

  • Filter by session/group/activity/location.
  • Search camper.
  • Display name, age/grade, photo if available, status.
  • Show key badges: checked in, checked out, absent, allergy flag, pickup note, form issue.
  • Tap camper for quick profile.

8.3 Camper Quick Profile

Permission-aware fields:

  • Name
  • Photo
  • Age/grade
  • Guardian contacts
  • Emergency contacts
  • Authorized pickups
  • Attendance status
  • Notes
  • Medical/allergy flags if permitted
  • Incident history if permitted

8.4 Check-In

Requirements:

  • Fast check-in action.
  • Timestamp automatically recorded.
  • Staff attribution automatically recorded.
  • Optional note.
  • Bulk check-in where safe.
  • QR scan support in later/native/PWA phase.
  • Prevent duplicate check-in confusion.

8.5 Check-Out

Requirements:

  • Verify authorized pickup.
  • Display authorized pickup list.
  • Allow staff to select pickup person.
  • Record timestamp.
  • Record staff attribution.
  • Capture note if needed.
  • Flag unauthorized pickup attempt.
  • Escalation instructions if pickup is not authorized.

8.6 Incident Reporting

Requirements:

  • Start incident from camper profile or today view.
  • Minimal required fields for fast entry.
  • Save draft.
  • Add details later.
  • Attach photo where permitted.
  • Mark parent notified.
  • Escalate to admin/health staff.

8.7 Attendance Notes

Requirements:

  • Add note to camper/day.
  • Mark absent.
  • Mark late.
  • Mark left early.
  • Add reason.
  • Sync to attendance report.

8.8 Offline / Degraded Mode

Required for critical field workflows:

  • Cache today’s assigned roster.
  • Cache emergency contacts for assigned campers.
  • Cache authorized pickups for assigned campers.
  • Allow local check-in/check-out queue when offline if technically feasible.
  • Display sync status.
  • Warn if data may be stale.
  • Sync when connection returns.

8.9 Staff Mobile Security

Requirements:

  • Role-based access.
  • Session-based data limitation.
  • Sensitive health data restricted.
  • Device session timeout.
  • Re-authentication for sensitive actions where appropriate.
  • Lost device risk mitigation through account logout/deactivation.

9. Provider Mobile Requirements

Provider mobile is not a full desktop replacement. It is a control panel for owners/directors/admins on the move.

Required features:

  • Enrollment snapshot
  • Revenue snapshot
  • Today attendance snapshot
  • Underfilled sessions
  • Waitlist alerts
  • Payment failure alerts
  • Forms outstanding summary
  • Urgent broadcast composer
  • Campaign approval
  • Listing issue alerts
  • Staff assignment overview
  • Incident notification

Provider mobile should answer:

  • Is anything wrong today?
  • Are registrations on track?
  • Do I need to approve something?
  • Do parents need to be notified?
  • Are there sessions that need growth help?

10. CampMatch-to-CampReg Cross-Product Flows

10.1 Provider Claim Flow

Required steps:

  1. Provider finds existing CampMatch listing.
  2. Provider clicks claim listing.
  3. Provider verifies ownership.
  4. Provider creates CampReg account.
  5. CampReg imports listing details.
  6. Provider reviews details.
  7. Provider chooses registration mode.
  8. Provider completes missing fields.
  9. Provider publishes improved listing.
  10. Provider sees listing performance dashboard.

10.2 Registration Mode Selection

UI must clearly explain three modes:

  1. External Link-Out — CampMatch sends families to the provider’s existing registration page.
  2. Lead Capture — CampMatch captures interested parents and sends them to the provider.
  3. Full CampReg Registration — parents register, pay, and complete forms through CampReg.

Each mode should show:

  • What parents experience.
  • What provider must configure.
  • What data CampReg captures.
  • What reporting is available.
  • Whether payments/forms are handled by CampReg.

10.3 Listing Performance

Required metrics:

  • Impressions
  • Clicks
  • Saves
  • Registration starts
  • Registrations completed
  • Leads generated
  • Revenue attributed
  • Search terms
  • Category performance
  • City/location performance
  • Conversion by session

10.4 Growth Loop

Required UI flow:

  1. CampMatch detects demand or conversion issue.
  2. CampReg surfaces opportunity.
  3. VibnAI recommends improvement or campaign.
  4. Provider reviews content.
  5. Provider approves.
  6. Missinglettr distributes campaign.
  7. CampReg tracks results.

11. Accessibility Requirements

The UI must be accessible and usable by parents, staff, and providers with varied technical comfort.

Requirements:

  • WCAG-informed design.
  • Keyboard navigation for desktop.
  • Screen reader-friendly labels.
  • Sufficient contrast.
  • Clear focus states.
  • Large touch targets on mobile.
  • Error messages tied to fields.
  • Forms that are easy to resume.
  • Avoid color-only meaning.
  • Support for translated UI in future.

12. Error, Validation, and Edge Case Requirements

12.1 Registration Errors

Handle:

  • Session fills during checkout.
  • Payment fails.
  • Required form missing.
  • Child not eligible by age/grade.
  • Duplicate registration.
  • Parent loses connection.
  • Upload fails.
  • Waiver unsigned.

12.2 Provider Errors

Handle:

  • Publishing incomplete listing.
  • Payment processor not connected.
  • Registration flow missing forms.
  • Session over capacity.
  • Waitlist misconfiguration.
  • API sync failure.
  • Missinglettr connection failure.
  • Staff permission conflict.

12.3 Staff Errors

Handle:

  • Unauthorized pickup.
  • Duplicate check-in/check-out.
  • Offline sync conflict.
  • Staff lacking permission.
  • Stale roster data.
  • Missing emergency contact.

13. UI Components Required

13.1 Shared Components

  • App shell
  • Side navigation
  • Mobile navigation
  • Top bar
  • Organization switcher
  • Season selector
  • Search bar
  • Notification center
  • Breadcrumbs
  • Cards
  • Data tables
  • Filter panels
  • Saved views
  • Status badges
  • Progress indicators
  • Stepper
  • Modals
  • Slide-over panels
  • Toasts
  • Empty states
  • Confirmation dialogs
  • File upload
  • Signature capture
  • Date picker
  • Time picker
  • Calendar view
  • Map/list toggle
  • Rich text editor
  • Audience builder
  • Form builder
  • Report builder
  • Payment summary card
  • Ledger table
  • Roster list
  • QR scanner interface

13.2 Parent Components

  • Camp card
  • Session card
  • Comparison card
  • Child selector
  • Family dashboard card
  • Outstanding task card
  • Saved camp card
  • Recommendation card
  • Payment due card
  • Form completion card
  • Waitlist status card

13.3 Staff Components

  • Today card
  • Roster row
  • Camper quick profile
  • Check-in button
  • Check-out button
  • Authorized pickup panel
  • Emergency contact panel
  • Incident quick form
  • Offline sync banner

13.4 Provider Components

  • Enrollment metric card
  • Revenue metric card
  • Capacity bar
  • Registration velocity chart
  • Forms completion tracker
  • Payment issue queue
  • VibnAI recommendation card
  • Listing score card
  • Integration status card
  • Webhook event log

14. Analytics and Instrumentation Requirements

The UI should be instrumented from the start.

Track parent events:

  • Search performed
  • Camp viewed
  • Camp saved
  • Compare started
  • Registration started
  • Registration abandoned
  • Payment started
  • Payment completed
  • Form completed
  • Waitlist joined

Track provider events:

  • Listing claimed
  • Listing published
  • Session created
  • Registration flow published
  • Campaign approved
  • Message sent
  • Report exported
  • API key created
  • Integration connected

Track staff events:

  • Roster viewed
  • Check-in completed
  • Check-out completed
  • Incident created
  • Emergency contact viewed
  • Unauthorized pickup flagged

Track mobile quality:

  • Load time
  • Form abandonment
  • Upload failure
  • Payment failure
  • Offline sync success/failure
  • QR scan success/failure

15. Implementation Notes for Design and Engineering

15.1 Recommended Frontend Approach

Recommended stack for UI execution:

  • Next.js or Remix for web app.
  • Responsive design from the start.
  • Shared component system.
  • Type-safe API layer.
  • Server-rendered public marketplace pages where SEO matters.
  • Client-heavy authenticated SaaS where interactivity matters.
  • PWA capabilities for staff mobile before native app.
  • Native/Expo app only when push, camera, and offline requirements justify it.

15.2 Component System

The component system should support:

  • Marketplace public UI.
  • Parent portal UI.
  • Provider SaaS UI.
  • Staff mobile UI.

These can share foundations but should not all feel identical. Parent UI should be warmer and simpler. Provider UI should be denser and operational. Staff mobile UI should be fast and minimal.

15.3 Design System Tokens

Define tokens for:

  • Typography
  • Spacing
  • Border radius
  • Shadows
  • Status colors
  • Semantic colors
  • Form controls
  • Table density
  • Mobile touch targets
  • Breakpoints

15.4 Data Model Alignment

Every major UI screen should map to one or more core data entities:

  • Provider dashboard → Organization, Season, Session, Registration, Payment, Attendance
  • Listing editor → MarketplaceListing, ProviderProfile, Program, Session
  • Registration builder → RegistrationFlow, Form, Session, PriceRule, PaymentPlan
  • Parent dashboard → Family, Camper, Registration, Payment, FormSubmission, Message
  • Staff roster → Session, Camper, AttendanceRecord, PickupAuthorization

This alignment is important for future API design and AI agent actions.

16. Summary

CampReg should not look or behave like legacy camp software. It should combine the operational completeness of mature camp platforms, the conversion focus of event registration tools, the planning awareness of camp-specific open-source tools, and the mobile expectations of modern parents and staff.

The desktop SaaS should be a serious provider operating system.

The parent mobile experience should make discovery, registration, payment, and forms easy from a phone.

The staff mobile experience should make attendance, pickup, safety, and incidents fast and trustworthy in the field.

The CampMatch integration should create a marketplace-to-registration loop.

The VibnAI and Missinglettr integration should turn operational data into automated growth.

Reference in New Issue View Git Blame Copy Permalink