Liaison University: Applicant Journey Flows

Liaison University user flow research

Liaison University: Applicant Journey Flows

About this project

The challenge:

In order to make the best design decisions for future improvements, the team needed to understand what the current user journeys were through a notoriously confusing application process. The challenge lied within an inherently complicated system with several combinations of actions that resulted in many user scenarios with slight nuances. Sound confusing? Yes, it was.

Research phase:

To understand the complexity of the project I should explain what the product does first. Liaison University (some details changed to protect proprietary info) is a school that participates in the CAS (Centralized Application Service). In short, it allows applicants the ability to send one application to many schools, instead of the traditional route of sending an application per school which can result in dozens of applications. The CAS saves the applicant time and money and streamlines the application process. Not to mention, applicants were able to apply to program-specific CASes in categories such as Business, Engineering, Healthcare, etc.

Sounds super, doesn’t it? Except it wasn’t for some applicants who were applying for certain CASes that deviated from the original concept. Originally, the CAS was built in a way that simplified the application process by requesting that all programs participating in that CAS require the same things from the applicant. For example, DentalCAS would require all the dental programs participating in DentalCAS to require the same things like transcripts, references, and test scores from the applicant. The applicant was able to confidently send in all program requirements to each program they applied to because the list of requirements did not change per program.

However, the complications began when a CAS allowed the programs within the CAS to require whatever they wanted. This resulted in a sudden unpredictability in program requirements, which the system was not originally designed for. Which meant the design was not equipped to display all the different program requirements without confusing the heck out of the applicants. Which meant my project was going to be challenging since I first had to know where the design was failing, why it was failing, where the applicants were specifically getting stuck, and so forth.

I also had to really understand the differences of each CAS so that I could see where the user journeys branched off to fulfill each program’s requirements. So I embarked on my own journey to get answers by interviewing our Customer Support agents and Operations team numerous times. Many times more than once.

Once I felt I had the most typical user flows recorded, I set about digitizing the flows in Sketch so it could help the UX team whenever things got confusing, and also serve as documentation for onboarding new team members.