RESPONSIVE WEBWORK WITH ENGINEERSDESIGN SYSTEM

ApplyGrad

Improving the online application experience for the MHCI program at Carnegie Mellon University.

Date March - May 2019
Platforms Responsive Web
Team Dale Shanefelt, Engineer; Mike Hanley, Engineer;
Gillis Bernard, Product Designer; Dylan Smith,
Product Designer; Wuyang Wang, Product Designer
My Role Product Designer; Project Manager
INTERACT WITH INVISION PROTOTYPE

PROBLEM SPACE

How might we create an application process that embodies the design principles we teach in the MHCI Program?

The existing application to the MHCI program hadn't been updated since 2008. As one can imagine, applicants often expressed confusion and skepticism about the program's UX focus. Ultimately, it led to a disconnect between applicants’ first impression of the MHCI Program and what it actually entails. How might we bridge this gap and create a better system for all parties involved?

SOLUTION

Before & after: confusing to clear.

Tasked with a complete overhaul of the existing system, our team completely revamped ApplyGrad's UX & UI, creating a seamless application experience that accurately reflects the design principles taught in the MHCI program.

FEATURES

A checklist on all pages gives applicants consistent feedback.

Allowing applicants to know where they are in the application at all times establishes trust that was missing in the original interface.

Transparency between recommenders and applicants reduces the need to call administrators.

Previously, administrators manually updated Letter of Recommendation status for each applicant, when the letter(s) were received. Our new design drastically reduces time spent manually updating ApplyGrad, as applicants can see where their recommenders are in the system, and can reach out to them individually if a deadline is approaching.

Backend logic makes ApplyGrad a personalized experience.

By collaborating closely with engineers, we were able to add skip logic such that ApplyGrad recognizes whether or not someone is an international applicant, and includes or excludes information accordingly. This creates a more streamlined experience for all applicants.

INTERACT WITH INVISION PROTOTYPE

WHAT I DID

What I contributed to the project

As a Product Designer and Project Manager, I worked closely with engineers to understand technical constraints and ensure that our project remained within scope. Here are some of my most notable contributions:

  • Conducting interviews and Think Alouds to empathize with users and identify specific pain points
  • Leading a heuristic evaluation of the existing system and extracting common themes
  • Parallel prototyping lo-fi concepts alongside fellow designers to decide key features
  • Creating a prioritization matrix with engineers to prioritize features and screens
  • Working with engineers to understand backend logic; integrating feedback into site
  • Leading visual design; creating a design system of reusable components implemented throughout
  • Creating pixel-perfect screens, Invision prototype, and annotated Figma file for hand-off to engineers

RESEARCH METHODS

Background Research
Competitive Analysis
Expert & User Interviews
Heuristic Evaluation
Think Alouds
User Testing

DESIGN METHODS

Feature Prioritization
Lo- to High-Fidelity Prototypes
Sitemap & User Flow
Value-Effort Matrix
Invision Prototype
Design System

INITIAL RESEARCH

Administrators are bombarded with phone calls about the application process.

Our background research consisted of: 
1) Interviews with past applicants & administrators, &
2) A competitive analysis of application software such as The Common App.

We heard that administrators and applicants alike are frustrated by ApplyGrad's current design, and users struggle with understanding application requirements.

HEURISTIC EVALUATIONS

We evaluated 14 screens of the current state based on Nielsen Norman's Heuristics.

We ran an extensive heuristic evaluation of all screens in the existing application, analyzing characteristics such as error prevention, recognition vs. recall, and user control & freedom.

We found that ApplyGrad most regularly violated the following heuristics:

THINK ALOUDS

6 Think Alouds taught us that the system's tabular navigation causes confusion.

Through Think Alouds, we heard that the tabular navigation makes the application seem sequential. This was a major pain point, as applicants want to upload required materials at their own pace. Furthermore, the instructions were so lengthy that users skipped over them, often missing crucial pieces of information.

→ INSIGHT #1

Applicants rely heavily on feedback to ensure that their materials have gone through.

Think Alouds also taught us that the system lacked feedback after saving the application. Users were nervous to move forward, worried that they would lose their progress.

→ INSIGHT #2

Users do not complete application materials sequentially.

Applications require many different materials, from transcripts to a statement of purpose to a resume. Users wanted to jump around in the application, but the current design felt constrained.

→ INSIGHT #3

If directions are too long, users won't read them.

Users ran into many hiccups throughout the application because they skipped over the directions. Moving forward, we decided to design to prevent errors to hopefully eliminate the superfluous instructions in the app. We also chunked the existing copy into more digestible sections.

EARLY ITERATIONS

Our low- and medium-fidelity wireframes focused on progressive disclosure of information.

Our initial designs focused on establishing overarching design elements. These included an accordion-style list for progressive disclosure, a side navigation to jump around, and more feedback.

Usability testing allowed us to tweak details such as button placement, color, and visual hierarchy.

Through several rounds of design & testing, we improved upon details such as spatial grouping, conveying actions through color, and placing text above rather than to the right of buttons.

DESIGN DECISIONS

1. Interactive checklist on homepage.

Action: Checklist of sections to complete & documents to gather to inform users where they are in the application process.

Rationale: Users heavily rely on feedback, especially in high-stakes situations like a grad school application.

2. Progress bar to depict recommenders' status.

Action: "Fed Ex" style status bar that shows what progress recommenders have made within their side of the Letter of Recommendation process.

Rationale: Relying on recommenders can be stressful— giving users an overview of where their recommenders are in the process keeps things transparent, establishing trust with the system.

3. International considerations for inclusion.

Action: Create international options for fields, like phone number. Apply backend logic so TOEFL section is skipped if someone's first language is English.

Rationale: Over half of the program applicants are international and have phone numbers that require a country code.

4. Personalizing Letter of Recommendation cancellation.

Action: If a user decides to cancel a recommendation request, they can add a personalized message to apologize to the recommender and thank them for their time.

Rationale: Receiving a cancellation can be a frustrating process for a recommender who already wrote a letter. Adding a personalized message makes it less harsh.

STYLE GUIDE

We created a style guide to ensure consistency across ApplyGrad, and to pass off to future designers tackling the administrator view.

Our style guide blends Applygrad's sleek, modern identity with Carnegie Mellon's traditional colors.  

1. Color Palette

2. Typography

3. Icons

MEASURING IMPACT

Less questions = more time for administrators.

As our revisions are launched this fall, we expect our design to impact both applicants and administrators. We expect an increase in completed applications. Administrators should gain more free time, as applicants have less ambiguity about their application.

REFLECTION

Don't reinvent the wheel - use design patterns.

We spent the majority of the design phase of this project researching well-supported design patterns, like where to situate text in relation to form fields, and how to effectively convey progress. These were such simple concepts in theory, but they quickly became paramount for optimal usability.

Good design is simple.

Our final design is simple and straightforward, with few bells & whistles. The application didn't need anything fancy to be effective.

Gather requirements from engineers.

We collaborated extensively with engineers throughout the course of this project. It was essential to get their input on our design decisions so that we could understand technical constraints and feasibility. They were also incredibly insightful about skip logic and helped us understand how our designs would fit into a larger backend system.

< PREVIOUS PROJECT
NEXT PROJECT >
OVERVIEWPROBLEM SPACESOLUTIONWHAT I DIDINITIAL RESEARCHHEURISTIC EVALUATIONSTHINK ALOUDSEARLY ITERATIONSDESIGN DECISIONSSTYLE GUIDEMEASURING IMPACTREFLECTION

"Let the beauty of what you love be what you do." –Rumi

© Molly Vierhile 2019