Music school website: where trial bookings stall

Someone who wants trial piano lessons for a child usually lands on a page about the school, not on the piano teacher. The instruments sit on one page, the teacher bios on another, and the trial form on a third. The form asks for a teacher name, and the visitor has to remember who teaches the instrument they picked. On a phone, the bios often sit in a row that swipes sideways, so the second teacher can be out of reach. The owner built the pages in an order that made sense to them, so the cost of the extra steps stays invisible from inside.

• Can a parent see which instruments you teach without leaving the page they landed on?
• On a phone, can you swipe the teacher bios and reach every teacher, or does the whole page move instead?
• Does the trial form ask for a teacher name before the visitor has seen the teacher list?
• Does any step ask for a card to hold a trial time, and does the page say so before the form?

A parent does not search for a teacher. They search for an instrument, a level and a town, and expect the page to match those. A school page that lists teachers alphabetically, with no instrument under each name, forces the parent to open every bio to find the one who teaches cello. That is a lot of tapping for a parent who is still deciding whether lessons are worth it.

Check it by choosing one instrument and counting the taps it takes to reach a bio that names a teacher for it. If the count is more than two, or the instrument is missing from the teacher section, the cause is the page structure. Repeat with an instrument that only one teacher covers, and check that the teacher's days show before the form.

Teacher bios are often built as a row of cards that scrolls sideways. On a laptop that works, because the scroll bar is visible. On a phone, a sideways swipe can move the whole page up or down instead, so the third card never comes into view. The visitor sees two teachers and assumes there are only two. The owner sees all the cards on a big screen and never notices the cut-off.

A simulated visitor opens the teacher section on a phone and tries each card. If it cannot reach one, the run shows the screen and a screenshot of the row. Fix it by stacking the cards on small screens, then check the change at the same phone width, since a row that fits a tablet can still cut off on a phone.

The trial form is where interest turns into a time on the calendar. Some schools ask for a card to hold a trial, with the charge taken later or refunded. A visitor who is not ready to give a card stops at that field. If the page never said a card was needed until the last step, the visitor learns that after they have already chosen a teacher and a time.

The card question is where a trial can end for a parent who was ready to book. Check it on your own phone before a parent does. Note whether a card holds the time, whether anything is charged, and whether the page says which before the form starts. A simulated visitor fills the text fields and reaches the card field. It stops there, because it cannot enter a real card, and the run ends with the screen and a screenshot. Check the card step with your payment provider's test mode if it has one.

A new teacher, a term change or an update to the booking tool can move an instrument off the list, bring back the sideways row, or add a card field to the trial form. The page still looks finished from the owner's side. Rerun the instrument path after each of those changes, and check each preview on a phone-sized screen, because the broken row only shows on a phone.