Best practices Examples User experience

User Registration in Admissions: Do's and Don'ts

Larry Grey

You’ve captured the attention of a prospective student. Congratulations, your marketing and recruiting efforts are paying off. Now, it’s time to get them on the path to becoming a new student.

For most institutions, this means having them complete an application, which generally means having them register as a user. As this is the first step of meaningfully engaging the candidate, it is critical that the user registration drives further engagement, and that your institution balances the competing goals of the process.

Competing Goals?

You may be asking what I mean by competing goals. Before answering that question, let’s provide a summary of why the user registration is a thing. Historically, all college applications were done via paper. You filled it out and mailed it in, and you would get letters (or phone calls) back as to what the next steps or results were.

Now candidates expect to complete the application and engage with the institution online. These expectations include the following:

To be able to complete the application in multiple sessions
To be able to verify that the application is valid and was received when submitted
To be able to check the status of the application
To be able to re-apply without re-entering all the data when desired

All of this means that the user needs a login, which is separate from the contents of the application. From an institution’s perspective, the user registration creates a number of considerations:

How simple or complex is the application? Can it easily be completed in a single setting?
When a candidate registers as a user, how is their identity managed before they are a student?
If a candidate is a current or prior student, what does that mean when registering as an applicant?
How does the institution protect the candidate’s personal information?
Once a candidate performs a user registration, where do they go from there? Do you have separate requirements for different types of students or degree programs?

Types of User Registrations

These considerations have caused institutions to come up with a number of different approaches (or optimization methods). These include:

Optimizing application to be completed in a single session
Optimizing for creation of a re-usable identity
Optimizing matching existing student records
Optimizing differentiation of application experience
Optimize to minimize registration entry
Optimizing candidate engagement

We’ll discuss the reasons and impact of each type. Of course, any regular blog reader will know that Mutara is partial to optimizing for candidate engagement (the last one).

1: Optimize application to be completed in a single session

Some institutions try to eliminate (or minimize) the need for a candidate to register. If it's possible to get an application completed in one setting, the candidate can get in and out without the additional step of creating a user account, providing a login, and managing password issues.

In theory, this approach makes sense. However, we've found that unless a candidate is planning to enroll in a single course (such as continuing education), the information needed by the admissions organization to process a candidate is more than 10 data elements. This means that the candidate is investing time and energy into the application.

This can create the following issues:

The candidate may have to re-enter data multiple times when they can't complete the application in one sitting (or when an error occurs)
The candidate may submit multiple applications to be processed by the admissions team not knowing whether a prior submission was successful
The institution may not be able to contact the individual because the contact information is not verified or because the candidate gives up before submitting the data to the institution.

2: Optimize for creation of re-usable identity

Some organizations optimize the registration process for re-use. In this circumstance, the candidate may have multiple applications over time attached to his/her profile. That ID is often stored in the school's identity management system to tie to the student record in the student information system.

From the candidate's perspective, this registration process asks them to create a user id that he/she should remember in the future for checking applications and/or applying again. One of the reasons an institution might take this approach is when there are concerns about the candidate changing his/her email address in the future or concerns about email addresses being shared across multiple people (such as family members).

This can create the following issues:

The candidate can get frustrated finding a unique userid that is not already used
The candidate could forget which user id he/she generated and then have to complete a "forgot my user id" process
The candidate could forget that he/she already registered and register a duplicate profile

3: Optimize matching existing student records

Screenshot asking for names, email address, birth date, and Social Security Number

Another strategy is to optimize the registration process to match existing student records at registration time. This helps match the profile of the applicant with other records in the student system -- even if the candidate doesn't remember previously applying (or attending).

This is a common approach for institutions utilizing PeopleSoft's application architecture to build their own online application. Because PeopleSoft already has functionality to create a login for course enrollment, there is less development effort to re-use that functionality when registering to perform the application. This means that the search / match functionality as part of creating a person in PeopleSoft would occur when a user registers as part of starting an application.

Therefore, the registration interface has to capture enough data to uniquely identify the candidate. In most circumstances this includes the following:

First, Middle, Last names
Prior names
Email address
Birth date
Social Security number

From the candidate's perspective, this can come across as being invasive. He/she is providing sensitive data to the institution as one of the first steps of engaging with it -- even before beginning his/her application. This could cause the candidate to reconsider how serious he/she is before completing the registration process.

4: Optimizing differentiation of application experience

Screenshot of dialog asking for your goals for applying and anticipated start date

Here, the institution asks the candidate his/her intent and/or goals as part of the registration process. The purpose of this is to tailor the steps following registration to capture information needed to admit the type of candidate for the type of program in which he/she is interested.

In that circumstance, the candidate is often directed to a different form based on his/her responses. Some of the challenges with this approach is as follows:

The candidate's identity is tied to a single degree program for application
The candidate may stop the registration process if confused about the implication of answering those questions a certain way

5: Minimal Registration

Screenshot of dialog asking for name, email address, and CAPTCHA

The next strategy is the minimalist registration. The candidate provides his name and email address, which is re-used as his user id to access the system. This makes the registration process extremely simple for the candidate and minimizes the opportunity for road blocks.

You may notice that the embedded screenshot has a captcha element. This is because a simplified form is also easy for a bot to complete and submit.

Mutara Strategy: Optimizing for candidate engagement

Our preferred method is to optimize the registration process for engagement with the candidate from that point forward. The strategy is that in the registration process, the candidate is raising his/her hand to indicate that he/she is interested in engaging with the institution. If all else goes wrong after the candidate registers, the institution still has the opportunity to address those issues and engage the candidate.

Therefore, the process is broken into 3 different components:

Name
Contact Information
Create Password and confirm

Each of the steps is simple and easy to complete:

Name

The candidate provides the bare minimum for his/her name.

Contact Information

The contact information is critical for engagement. Screenshot of dialog asking for email address, phone number, and permission to send texts

Because it's easier to reach most higher education candidates via their phones versus their email, we ask for both. However, we use the email address for their login ID so they don't have to create and manage another one.

We also validate the contact information to ensure that the institution can contact them following their use registration. In the screenshot above, the phone number is not a valid number registered to any telephone provider, which is why it's invalid and marked in red. You may also notice that we include a simple opt-in option for receiving texts to ensure that data privacy rules are followed.

Create Password and Confirm

Finally, we present the information provided to allow the candidate to review and change it and ask them to create a password for future logins.

Screenshot of confirmation dialog and setting registration password

At this point, the candidate has registered with a valid user id and password. Once the user clicks register, he/she will receive a welcome / confirmation text and email. This accomplishes the following:

The candidate receives welcoming language from the institution to (1) keep them engaged, and (2) set expectations as to next steps
The candidate can determine immediately whether there was an issue in the contact informatio they provided
The institution can determine immediately whether the email or text message bounced for any reason

How we handle scenarios of concern in other strategies

As a final note, I would like to cover how the Mutara solution handles the challenges for which other strategies optimize:

Duplicate Identities: We recognize that the candidate will organically provide information in the application that will match him/her to known identities when they exist. Therefore, we will match the people at the point in time that the information exists. This means that when the candidate has completed and is submitting his/her application, any duplicate issues will be addressed before the application is reviewed in the student information system.

Tailoring the application to goals: In a similar manner, the candidate's goals is captured organically outside of the registration process.

If the candidate clicks "apply now" from a page in the institution's website describing the program, that is defaulted into the application.
Once in the application, the options for helping the candidate choose a degree program where it makes sense.
Finally, the application dynamically changes based on what is needed for the selection by the candidate. This means that the institution doesn't have to maintain different forms to which the candidate needs to navigate

Managing re-usable identities: In a manner similar to how we handle duplicate identities, we will link known identities in the institution to the user registration. The identity management process at many institutions is a critical means by which security profiles are managed. However, we've found that registering a user too early in the school's Identity Provider (IDP) means that the institution has to either manage identities of candidates who never attend the school (with the associated costs), or the institution must clean up the repository. By managing the registered user separately, institutions can focus on managing the profiles in their master repository for only those candidates who enroll and attend classes.