Digitizing a Paper Process From The Ground Up

SchooLinks

Project Overview

Many features on SchooLinks seem simple on the surface, but are steeped in complexity the deeper you go. This is doubly so for the Transcript Center. We needed to take an archaic offline paper process and reimagine it digitally without sacrificing any of the flexibility and edge cases that offline processes can typically support.

User Research

Information Architecture

Interface Design

Desktop Web App

Interaction Design

My role: Lead Product Designer
Tools used: Draw.io, Sketch, Invision
Project Timeline: 4 Months

Introduction

When it comes to applying to college, the high school transcript is as important to the admissions process as an SAT or ACT test scores. It's a record of a single students high school academic history, containing every course they've taken, their grades, and what their overall GPA is.

Official transcripts are often sent out by a high school registrar, who processes student requests and send them out on behalf of the high school. This process verifies that a transcript is official and can accurately verify a student's academic history.

Problem

There are plenty of reasons a student need to send out a transcript. The most common one by far is for applying to college. Each college that a student applies to will need a transcript to be sent along with their application and additional materials.

Though it's not the only reason a student might need a transcript. Certain scholarships, sports activities, and extracurricular programs may need an official high school transcript as well.

The transcript request process is an essential, but often outdated process that all students will deal with at one point or another. Our challenge was to not only digitize this process for our partner school districts, but also figure out how to update it for the 21st century.

Avg number of applications per enrolled college student (2017)

6.8 college applications per student

Solution

Decoupling the most common and least likely scenarios.

Transcripts are mainly needed for two things: college applications, and everything else. By making this separation explicit, it allowed us to tackle the college application transcripts in a separate, more contextually relevant feature (our College App Tracker) and focus on getting the more complex but equally important "Non-college" transcript experience exactly right.

Challenges

Although we had decided to separate out college transcripts, that didn't mean all of our problems were solved right out the gate. A student's transcript can be the deciding factory in a college scholarship, and with tight deadlines and a growing number of scholarship applications we knew we couldn't mess up. There were a few key challenges that we focused on solving:

‍

1. Routing students (and staff) to the right place

Most students only know transcripts as they pertain to college applications. We needed to make sure that we were clearly communicating where they could request transcripts for non-college purposes, but also make sure that we weren't making things more confusing for those students who needed transcripts sent for college applications.

2. Creating a flexible but accountable sign off process

Though we could automate the entire transcript sending process, we knew that there were some gates that needed to be kept in place. We didn't want to add more to the already overstuff plate of counselors and registrars, but we needed to make sure we weren't too fast and loose with the request approval process.

3. Communicating updates with our transcript sending partner

Sending a high school transcript requires an outside partner with the technical capability and verified status to officially process these requests. Whether digital or physical, we needed to make sure that the information we got from their API was timely and accurate.

4. Avoiding inaccurate destination addresses

Not all transcript receivers are alike. Some aren't able to receive electronic transcripts. Some might be, but still prefer physical transcripts. We needed to do our best to help students avoid making mistakes when they entered the receiver information, but allow them the freedom to make a request to whomever might need it.

Research

1. User Interviews

Before we'd even found a transcript sending partner, we began our research by conducting user interviews with as many registrars we could talk to. Through this process, we learned a few things: mainly that no two school districts were exactly alike. Some districts had registrar for each of their high schools. Some had only one for their entire district. Others spread the responsibilities across their school counseling staff. Beyond learning about the different processes for each them, we knew we needed a system that was flexible enough to work for any and all of these scenarios.

2. Competitor Analysis

Our district partners wanted a better transcript sending process just as much as we did. Fortunately for us, that meant they gave us an intimate look into the current tools they used online to handle this process. From researching our competitors, we were able to draw out general abstractions that we could then reorganize later when designing our own transcript feature.

3. Transcript Partner API

Once we did secure a transcript sending partner, we were given access to their API documentation. Our engineering team was able to review it and bring their conclusions back to the larger product team to discuss technical feasibility. In addition to their assessment, we also look at our competitors public documentation to get an idea of what might be feasible improvements to make on our end, or to suggest to our transcript sending partner.

Sketches

During various stages of the research process, I began to sketch UI ideas to get things started. This helped take what was often complex user flows full of moving data and make it concrete and interactive. By starting with a potential end result, I was able to work backwards and see what this experience might actually entail architecturally.

Final designs for the

Non-College Transcript Center

In the end, we were able to achieve our goal. Our Non-College Transcript Center was a complex process on the back-end, but to our every day users on the front end it couldn't have been simpler. The experience was boiled down into three simple steps:

Student creates a transcript request
School Administrator approves the transcript request
Service Partner fulfills the transcript request

Student transcript portal

For students, we centered the transcript experience around their Transcript Request page. Knowing that some students would inevitably come here with a cursory understanding of how transcripts work, we focused on explicitly educating them on the topic and providing three options:

Transcripts for personal use
Transcript for college applications
Transcripts for non-college experiences

Student request modal

Once students understood the options available to them, those who chose non-college application option would be prompted to specify their destination. We provided them with 4 preset options:

NCAA Eligibility Scholarship: by far the most common option for non-college application requests.
Email Address: where students would enter a custom email address
Mailing Address: where students would enter a street adress which would then be verified using a USPS integration.
College Address: which would allow there students to search for a college and choose the specific destination from the options in our system.

Request fulfillment page

Once a request was made by a student, the school administrator with the relevant permissions would receive an update in their Transcript Request Fulfillment page. Here they'd see a FIFO table of student requests they could choose to fulfill, reject, or make changes to as they saw fit.

While the default view displayed outstanding requests, we also provided a fulfilled requests view for accountability and history.

Staff request modals

For electronic requests, the fulfillment process was simple. A school administrator approved the request and our transcript sending partner would make sure it is sent to its destination. Physical requests were not as easy.

We broke the process down into two steps: print and mail. While we had no way of updating our system to ensure that physical transcripts ever actually were mailed, we at least gated that status update by requiring that "Print Transcript" be clicked first.

Staff edit destination modal

Of course, we couldn't rely completely on the student to get everything right, and we didn't want a pass/fail system that caused too much back and forth between staff and student.

That's why we made sure to include the ability for staff to also edit the destination details of a particular request. This kept things moving and, for accountability reasons, put the onus of correct information squarely on the shoulders of the school administrators.

System feedback

After being fulfilled, we still needed to keep users on our side updated on the status of their requests. Our transcript provider's API gave us varying levels of feedback for each request, depending on the transcript type. Physically mailed transcripts, for instance, would show "Sent" as the final status, while electronic transcripts sent through email could display a status of "Opened."

Conclusion

When we launched this new feature, it was a resounding success. We saved our school district partners hours of time. Time that was previously spent on the logistical burden of managing and fulfilling requests was now being spent on 1-on-1 sessions with students.

That being said, I think this feature improved greatly as time went on. In future updates, we were able to simplify the school administrator side even further, and also provide a separate experience where they could search a particular student to view their own outstanding requests (and even create/fulfill a request in one form).