Summer camp landing page: why parents stop

A parent searching for summer camp is comparing dates, not reading about the program. They have a child who turns nine in June and a week in August that may or may not be open. The landing page often shows a photo of kids at a lake. The age range sits in small type under the session list, and the list does not say whether age is measured on the first day or today. The registration tool then asks for a parent account and the child's birthday before it shows that a session is full. The parent cannot compare anything until they have already committed.

• Does the first screen show session dates and the age range without a scroll on a phone?
• Does the age note say whether age is measured on the first day or on today's date?
• Is a full session marked full on the list, or only after the parent fills in the form?
• Can a parent see the price and what is included before they create an account?

Parents often arrive from a search or a social ad on a phone, late in the evening, with a child's age and a week in mind. The first screen usually holds the camp's name, a lake photo and a sign-up button. The session dates sit one tap down, under a list that may be collapsed by default. A parent who has to scroll past the activities and the staff bios to reach a date often opens another tab.

You cannot see this from inside. You know which sessions have room, so every date looks obvious to you. Open the page on your own phone in a private window, the way a parent arrives from a search. Count the taps before a session date and an age range are both on the screen. If the count is more than two, the page is making a parent hunt, and that is the first thing to fix.

Age ranges fail quietly. The session list says ages eight to twelve, the registration form asks for a birthday, and the form measures age on a date the list never names. A parent whose child turns eight in July sees a yes on the list and a no at the end of the form, after an account already exists. Compare the wording on the list with the message the form gives for a child one year outside the range on each end.

Full sessions cause the second failure. A session can show as open on the list while the registration tool has no spots left. The parent fills in the child's details, reaches the last step, and gets an error or a waitlist form with no confirmation. From the parent's side, the same session should read the same way in both places, with the same dates and the same open spots.

Send one simulated parent from your homepage with this task: find an open session for a 9-year-old and start a registration. The visitor is a parent who searches for a summer camp on a phone, with a child inside the age range you advertise. Leave your session codes out of the task, because a parent does not know them yet. Put the child's age in the visitor profile, so the run meets the age note the way a parent does.

The run follows the parent through the session list, the age note, the registration start and the form. It stops at the first step that needs a real card, a Google sign-in or a text code, and the report names that step. If the run stops at the age note, put the cutoff date beside the range, then send the same nine-year-old through again on a phone and see whether the registration form opens.

How a signup flow test works

Every new season adds sessions, dates and a new cutoff day, and each one is a chance for the list and the form to disagree again. Rerun the same parent after each change, and after you rename a session. If registration sits behind a parent login, give the visitor a test account so the run can reach the sessions behind it.