Student Registration Hunter Ed

Introduction

Hunter Ed is one of the many courses that Kalkomey Enterprises offers for people who are seeking outdoor safety education certification. For this project, I was tasked to address an ongoing issue new customers encounter when registering for a new student’s account. The scope of this project involved mapping out three possible user flows to tackle this problem. I then translated these flows into clickable hi-fi prototypes that would be ready for user testing. Since I was bringing in existing visual branding, this project placed less emphasis on visual style and brand decisions and more on task flow mapping, wireframing, and prototyping.

What's The Problem?

When students create a new account to take a course, they must enter their date of birth on the registration form. After successfully completing the course, they receive a state-licensed Hunter Education card with their DOB reflected on them. So far, this process seems straightforward enough, right?

Sample Michigan Hunter Ed Card with a Birth Date
‍

However, parents or guardians who are registering new accounts for their children seem to run into a bit of confusion. Though the form states that individuals must “create an account for the person getting certified,” parents often bypass this message and type in their own birthdates on the forms instead of their children’s birthdates. Again, it’s their children who need Hunter Ed certification, not the parents.
‍

First page of the student registration form.
‍

Because the Hunter Ed course offers a state-issued hunting certificate, it’s crucial to have the correct information reflected on these documents. Upon their children completing their courses, the parents then realize that they’ve been issued cards with the incorrect DOBs. When the parents log back into their accounts to change the DOBs, they’ll find that they cannot do this themselves, because these certificates are official licensed documents. Kalkomey’s customer service department then receives a flood of panicked inquiries requesting a birthdate change on these certificates.

And because the cards are state-licensed documents, the fix isn’t as simple as erasing and inputting the updated DOBs by the customer service representatives. They need to submit a ticket to the licensing agencies, wait for processing, approve mailing, and then update the parents, etc… all for a birthdate change! As you can imagine, these DOB change requests have comprised a primary chunk of customer service backlog for quite some time now.

"Hunting" for the Solution 🦌

I thought a good place to start was defining the user goal and mapping out a simple task flow of the sign-up process. I decided to focus solely on the initial stages of the current registration process for the wireframes, because the entire flow would involve progressing through the extensive Hunter Ed course material. The initial stages of creating a student account is where I identified the users would need more guidance.

By highlighting these gaps in the flow, I was able to suggest building in a “checkpoint.” This “check” would prompt users to really consider for whom they were registering the account, before proceeding to the payment page.

TLDR

When parents register their children for the Hunter Ed course, they often submit their own birthdates instead of their children’s birthdates. They then have to call the Customer Service department to request a DOB change on the hunting certificate. This can all be prevented if there was some "checkpoint" to force the parents to catch this mistake early on in the sign-up process!

Prompting the Parents: Three Approaches

I then created alternate flows as mid-fi wireframes. I did this to visualize the different ways in which the prompt component could become part of the existing flow. This new checkpoint component requires the users to select if (a) the user is the one getting certified, or (b) if the user is filling out the form on behalf of someone who’s getting certified. The three possible flows were:
‍
Option 1 The “Catch All” method. When parents select the “My child is getting certified” button, the form requires information from both the parent and the child. The child’s information is then coded to appear on the final certificate.
‍
Option 2 Altering the text copy. When parents select the child option, they are issued a text prompt at the top of the form.
‍
Option 3 Inserting a pop-up modal with a checkbox. A modal requires the user to check and read the conditions before they proceed with the sign-up form.

Then, I presented three possible user flows as high fidelity prototypes to the Product Team.

Talking with the Product Team

After a few iterative discussions with the product team, I decided Option #1 was the most favorable for the users. This was for a few reasons. By choosing a “catch all” method where the information is required from both parties (the parent and the child), it was a foolproof approach to obtain all the data we need. Mistakes could potentially still happen with Option #2. And thirdly, I wanted to ultimately limit the number of steps a user would have to bypass to reach the sign-up form. By using Option #3, we would be adding an additional screen.

I then proceeded to create a high fidelity prototype using Option #1’s approach, bringing in the existing visual designs of the Hunter Ed website and branding guidelines. I chose to build a full flow of the student registration and course completion, so that the stakeholders could experience the end-to-end process for the demo. This prototype can be viewed here, or below!

Closing Thoughts

This project would have gotten out into user testing and development. However, due to corporate restructuring and reorg, my role at the company was dissolved and my time at Kalkomey was unfortunately cut short. It would have been extremely interesting to see how user testing would have further informed design iterations.

After development, it would have also been exciting to see how this would minimize the work for the Customer Service department so that they can better address user issues and allocate time for other inquiries. And, ultimately, we would create happy Hunter Ed users because it saves them an unnecessary phone call!

Other improvements would have included adapting the text field to be more inclusive —in the case that some adults aren’t necessarily parents, but guardians of minor students (ex: uncle and aunt registering for their niece or nephew, etc) and working on microcopy with the content team.

Nevertheless, this project was a worthwhile opportunity in facing real-life user challenges head-on. It was definitely a head-scratcher and a creative exercise in putting myself in our users’ shoes.

Thank you for reading!

New Student Registration Form