Student Info Management Platform
Northeastern University needs to regularly collect or update the information it has on its students for a wide variety of stakeholders.
To get students to provide this information, the University devised a system it called “Blocks.” When a student logged into the University’s student portal they would periodically get presented with a page blocking their access until they filled out the required form.
Needless to say, students hated this.
While form design might not normally be a portfolio show-piece, this project had a lot of interesting problems to solve.
The challenge
I was asked to find a way to redesign the app to balance the tedious and interruptive student experience of filling out a dozen or so lengthy forms repeatedly with the need of the University stakeholders to frequently collect this data.
After spending time with various subject matter experts (including students), business analysts (Northeastern’s term for UX researcher, more or less) and University stakeholders (the interested parties for each form’s information), I found the following:
The blocking of access occurred with no forewarning.
The blocking forms were separate, discrete apps with no integration or communication between them and sometimes asked overlapping information.
The sheer number of forms along with the way they were being presented made the students feel kind of bombarded by them.
The forms’ schedules were not synchronized in any way.
The forms were very dated looking, had a lot of outmoded patterns and sub-optimal flows, resulting in a lot of effort to fill them out.
The blocks were absolutely not mobile friendly.
Some of the forms were long and took quite a bit of time to finish.
Selecting a form from the list on the blocking page opened a new browser tab that didn’t refresh the blocking page, creating a confusing flow.
I looked for ways to make filling out all these forms actually easier, and also looked for tactics to give the student the impression of less effort.
I also tried to shift the mind-set from blocking the student’s access to one of encouraging them to pro-actively manage their information. This shift was somewhere between P.R. spin and actual change, but the idea was to remove the negative connotation of blocking the student.
Let the user know what to expect
We wanted to be able to forewarn the student that a form was coming due, prior to their access being blocked.
To do this, we changed most of the forms’ scheduling from being tied to academic term dates to a “freshness of data” concept, where the form gets a timestamp when it is filled out (or confirmed that the info is still current), and then a countdown starts to the next time you have to respond to it.
Each time the student logs in to the portal, we check their timestamps to present them appropriate information.
When the due date approaches the student receives prompts, first gently and then more aggressively until the due date is reached and their access is blocked if they have not yet dealt with the request for information.
This removed the aggravating element of surprise as well as some of the seeming arbitrariness around the frequency with which forms were presented.
It also gently nudged the student to pro-actively deal with the form at a time convenient to them.
Transparency and control
A second strategy related to forewarning was to grant the students more transparency and control over their information by way of a dashboard.
This enabled them to:
See all the forms that pertain to them and their “freshness” statuses
Allow them to pro-actively update the forms
Since updating a piece of information resets the timestamp for that form, preemptively doing so reduces the likelihood that the student will ever be blocked at all.
We displayed this to them both as a dedicated card within the portal as well as in a sidebar any time they were in the app and engaging with a form.
Make the app smarter
Each form can still be served up individually and can have its own schedule, and different forms had different target audiences and University stakeholders, but several of the forms had potentially overlapping information such as various types of addresses.
While the current forms were all discrete apps with no connection to each other, by integrating them together we were able to make them a bit smarter and allowed the possibility to complete more than one form at the same time.
If, for example, your emergency contact’s address was also the same as your permanent home address, which might also be the address where your vehicle is registered, by employing a few checkboxes we could eliminate or auto-fill a couple of lengthy forms altogether. (Think of the ubiquitous checkout question about Shipping vs. Billing address, for a similar situation.)
In this particular example, the student could potentially skip a step of one lengthy form, auto-fill a step on another form, and complete another two forms without ever having to see them.
This was a legitimate time savings.
Another advantage of integrating them into a single larger app was that we could cascade forms together into a single flow if more than one was due.
This idea was sort of a balancing act of whether one longer flow of form was preferable to just doing the ones that are required right now, but it was optional and the student could always choose to skip and proceed to where they were trying to get to in the first place.
When the current form was completed, we could check and see if others were due or coming close to due.
If another was due, we could segue them directly into the next form.
If another was coming close to due, we could offer the student the option to complete the upcoming one, again pushing pro-active engagement.
Cascading the forms together gave the impression of fewer forms to fill out.
And of course, redesign the forms themselves
In an effort to reduce cognitive load and interaction cost (jargon alert), I spent time thinking about things like:
Can we help the user by pre-filling anything from what we already know?
What information is better picked from a selection of choices rather than typed in, and what is the best picker in each situation?
What questions don’t have to be displayed in certain conditions?
What might be looked up and suggested while a field is being filled?
What input types can we validate and reformat for the user?
Are the questions grouped in a logical order and laid out in a scannable manner?
Are fields sized according to expected input?
Can we shift all optional responses to a step that could be skipped to de-complicate the forms (or better yet, can the optional response be eliminated)?
Should some forms of unrelated information be regrouped in a different way?
Should very long forms be chunked into steps?
Have we prevented letting the user make mistakes, or provided specific, helpful error messages?
Is all the copy clear and succinct and does it sound like normal human speech?
To establish a coherent, cohesive experience across all the apps, I created a component/pattern/style document to work from, adhering to Northeastern’s brand guidelines.
This helped keep my designs consistent and also helped with developer hand-off, as the devs could pull styling, graphic assets and other information from a single source.
It’s not quite a design system or a style guide, but is at least a unified set of components. You can see it in action here.
Here are shots of some of the forms. The links will open the prototypes in a new browser tab.
In the end, we rebuilt about 17 separate applications. We succeeded in:
Shaving down the total number of forms and turning them into a single integrated app.
Reducing the frequency with which many of the forms were served up.
Creating a means cross-populating forms if information overlapped.
Encouraging the student to manage their information pro-actively via prompts, a dashboard and cascading forms together.
De-complicating the forms.
Improving the ease of which forms could be filled out.
Vastly improving the quality of the data collected.
Bringing the forms’ aesthetics into the modern era.
And of course, the apps were now designed to be responsive and mobile-friendly, in line with Northeastern ITS’s ethos of mobile-first.
We also created an admin interface for the various stakeholders to manage their forms, but this feels overly long already.