Recommendation Portal Redesign

Recommendations are an important part of the college application process. Many of the applicants who used our products were required to submit contact information for references. This means that we also had to support a way for the evaluators to manage and respond to recommendation requests originating from our applications.

I was the designer on a team of Product Managers, Developers and QA Analysts tasked with revamping the existing portal and improving its appearance and ease of use.

Please note: the information displayed in this case study has been significantly altered to adhere to confidentiality agreements.

Preview of Final Product

The final product ended up producing a streamlined way for evaluators to receive, manage, and complete recommendation requests:

Evaluating the Existing Portal

When looking through the existing portal, we noticed a few recurring themes:

Home Dashboard

The home screen, where all of the evaluation requests lived, was confusing to users because it was not set up to effectively guide users toward accepting a request, and then filling out and submitting recommendation.
No way to filter recommendation requests by status, to allow evaluators to see only “Accepted” requests, for example.
No room to display additional important info or accommodate more than 1 or 2 values with large character counts for each request because of the limitations of a tabular layout.
There were also numerous accessibility issues with the display and function of this screen, such as illogical keyboard navigation, improper labels for screen readers, and insufficient color contrast ratios.

Recommendation Form

Input types don’t always make sense for the questions being asked, such as text inputs being provided for long-form answers.
Dropdown menu item order was not always logical, making it difficult for users to find the intended answer in a long list of options.
Look and feel across components was inconsistent.
More accessibility issues were found, similar or related to those found on the home screen.

Understanding the Typical User

The typical user we identified for this new product is someone like a college professor, who frequently receives requests for recommendations to grad schools.

Compiling Requirements

In order for this product redesign to be considered successful, it needed to achieve the following:

The portal should work seamlessly on desktop web browsers.
The portal should meet WCAG 2.1.
It should be easy to create an account, as well as later modify the account info.
Upon account creation, the home screen should populate all other requests associated with that account’s registration email address.
The portal should support various request types including individual evaluations, group evaluations, and logged clinical hours.
Evaluators should be able to see, at a glance, the status of each request associated with their email address, along with any pertinent request info.
Requests should be sortable.
Evaluators should receive an email notification for each new request, with a link to create an account if this was the first time an evaluator was receiving a request through our portal.
If an evaluator chooses to decline a request, they should be able to attach a message to the applicant if they wish.
There should be an obvious way to continue working on a previously started request.
The evaluation forms should be easy to understand and use, including file upload functionality and rating scales.

Designing the Solution

In addition to the research done to better understand the existing product, as well as current users’ frustrations, we continued to dive into the nuances of each feature and component. We wanted to make sure that in addition to making sure each existing feature was accounted for in the redesign, that we also found ways to improve upon the features and components.

Home Dashboard

The color scheme was revamped, moving away from dark colors with gradients to a lighter palette of solid colors.
The information of each request was now displayed in a card view, allowing us to better organize each request’s info and introduce some hierarchy within the requests to make them easier for the evaluator to parse though.
Requests cards were now able to be expanded and collapsed, allowing the user to navigate the dashboard more easily.
Request cards could not only be sorted, but now they could be filtered by status, which reduced on-screen clutter as it was now possible to “hide” requests that were already completed or declined.
Status names were changed from “accepted”/”declined” to “Not Started”, “In Progress”, “Complete”, and “Declined”
A single request could display multiple program applications it was being used for, rather than creating a unique request for each program application.

Recommendation Form

The information was re-organized in a way that allowed the evaluator to more easily identify which parts of the screen were information for them and which parts were expecting input from them.
Input elements were standardized, and new input types were added to make filling out the form more intuitive for the evaluators.
The rating scale, previously a grid of radio buttons, was now converted to rating sliders. In addition to sticky headers to prevent the user from needing to scroll up to see what all of the rating options were, the sliders also contained inline reminders of the currently selected rating.
The file upload now allowed users to either drag and drop files directly onto the screen or browse their local files to attach.

Other Considerations

At the time of this project, there was only approval for developing a desktop-friendly solution. I did, however, put together some designs to present to the product managers and developers for making sure this product was usable on other devices with smaller viewports. My reasoning was that even though there weren’t any plans to make this product mobile-friendly, I would present those building it with my vision for mobile to encourage development decisions that allowed for responsiveness now and down the line.