A tutoring enquiry page

Key decisions

Moving the exclusions

The original structure had "who this is not for" at position 5. I moved it into Section 2.

Putting it after the price didn't make much sense. By that point, a parent has already spent time going through the page and understanding the service. The information about who I don't teach is more useful alongside the information about who I do teach.

Now the classes and subjects I don't take sit directly beneath the ones I do, with the same visual weight. A parent can immediately check their child's class and see whether the service applies to them.

The form versus WhatsApp

This was probably the most interesting problem on the page, because the way parents normally contact tutors isn't necessarily the same thing I wanted the portfolio project to demonstrate.

Parents in this market usually contact tutors through WhatsApp. That's simply how it works here. At the same time, I wanted to demonstrate a proper enquiry form, and a form lets me collect the same basic details from every enquiry.

I ended up using both, but giving them different roles.

The form is the main route. WhatsApp sits underneath it as a smaller alternative. The contact also works in one direction: the parent leaves their number, and I message them. My personal number isn't displayed on the page.

That also gives me more control over who receives my number. I can review the enquiry first and decide whether to contact the parent, while they still get the familiar WhatsApp conversation once I reply.

Errors that don't rely on colour

I didn't want errors to be communicated through colour alone, so I added a ⚠ symbol alongside the error message. That way, the warning is still clear even if someone can't distinguish the colours.

The five form states

These are the five states the form can be in. Most of the work on this page went into the four that aren't the happy path.

Empty

This is the form before anyone touches it.

Both dropdowns open on a placeholder rather than defaulting to Class 1 or English, so a parent can't accidentally submit a wrong answer by leaving a field alone. Required and optional are written out in the labels rather than marked with an asterisk, and the note under the phone label tells a parent I'll reply on WhatsApp before they've given me the number.

Validation errors

All four required fields are checked at once, so a parent sees everything that needs fixing in one pass rather than being corrected one field at a time.

Each message starts with a ⚠ so the problem isn't communicated through colour alone. The cursor moves to the first field that needs attention, which means a parent using a keyboard doesn't have to go looking for it.

The phone check is deliberately loose. It accepts spaces, hyphens and a country code, because someone writing their number the way they always write it shouldn't be told they've got it wrong.

Loading

The button changes to "Sending…" and stops working while the enquiry is on its way.

Without this, a parent on a slow connection presses the button again because nothing appears to have happened, and I end up with the same enquiry three times.

Success

The form is replaced by the confirmation rather than the page reloading, so the parent stays where they are and can see that what they did caused what happened.

It also tells them what comes next and when. "Thank you" on its own doesn't answer the thing they actually want to know, which is whether to wait or to chase.

Failure

Something went wrong on the way and the enquiry didn't send. Everything the parent typed is still sitting in the boxes, because clearing it would make them start again through no fault of their own.

The message says specifically that they're offline rather than implying they typed something wrong. The button is disabled while there's no connection, and it comes back on its own once they reconnect, so nobody is left pressing a button that can't work.

If the failure isn't a connection problem, the message is different and offers my email instead, so a broken form isn't a dead end.

What testing found

I found both of these while testing the complete enquiry process, from submitting the form to checking where the enquiry actually arrived.

Valid phone numbers were being rejected

The country-code validation was rejecting numbers beginning with 91. I found it because one of my failure tests happened to use 9123456789. The problem was that the code was stripping 91 without first checking whether it was actually a country code.

I fixed it so the code only strips the country code when the number of digits confirms that one is present.

Live enquiries were going to spam

Local submissions were reaching the inbox, but live submissions were going to spam. The form service sends emails from a randomised address, so filtering for one exact sender address didn't work. I changed the filter to use the domain instead.

Neither problem would have been visible from looking at the page. A parent would have typed a valid number and been told it was wrong, or sent an enquiry that sat unread.

What this page doesn't have

No user testing was conducted, and there isn't any conversion data yet. The three FAQs come from questions parents have actually asked me; I haven't conducted formal user research.

The page also hasn't been styled yet. Visual design is a later phase. At this stage, I'm focusing on the structure, content, logic and functionality.

See it

The page is live and taking real enquiries.

Open the tutoring page (opens in a new tab)