Summer Sprint 3 — Build it Right

Hello from the CMU MHCI student loan team! For those who haven’t been following our journey, we are working for a large-scale national bank to design a solution that helps customers commit to one of their student loan products.

If you read our summer sprint 2 post, you know we finalized our solution concept — delivering guidance through resources in order to reduce parents’ anxiety and uncertainty as they help their child pay for college. We determined two ways of doing this:

  1. In-application guidance. We’ve identified the “resource gap” — financial institutions have worked hard to publish helpful videos, articles, and tools for their customers, but they are under-used. To close this gap, we’re mapping those resources directly to the application, making them available precisely where they are needed.
  2. The hook. An eye-catching tool on the lender’s webpage can deliver guidance to customers in the early stages of loan research (what we call “light browsing”) after committing to a college. A successful hook would establish the client as a trusted advisor and compel customers to consider the client as a lender contender.

In this sprint, we focused our attention on building it right by defining major features of the final in-app solution at mid-fidelity.

But first, alignment.

With Sprint 3 initiating the second half of the semester, it was important for us to articulate our solution direction to the client. Achieving alignment and receiving feedback that could inform our solution or refine our scope would allow us to forge ahead with confidence. To our delight, the client was completely aligned with our direction. They considered our solution concept — “integrating the most relevant info at the relevant stage of the process” — as an opportunity for customers to see them as a trusted advisor, right on brand. They also provided some notable constraints, such as only referencing resources example under the client’s control, and a reminder to design “mobile-first” due to a rise in mobile usage of their digital products.

Parallel research & prototyping.

Our primary goals for this sprint were to:

  • refine our prototypes for in-app resources
  • consider early “hook” concepts
  • locate specific resource gaps in the customer journeyWe needed to do two things — understand what We did this by working on form and content in parallel.

We achieved these by working on content and form in parallel.

  1. Two of us researched the content that parents need.
    What resources do parents need, and when? What answers are they seeking?
  2. Three of us designed mid-fidelity prototypes exploring the form of resource delivery.
    How and when would the resources appear? How would this affect the overall application flow?

Content — Card Sorting & In-App Decision Analysis

In order to build the right “hook,” we needed to understand what questions & student loan concerns parents have at this early stage after committing to a college. That’s where [remote] card sorting came in.

An example of a customer’s third card sort, mapping their useful resources to their journey

In a moderated study, we asked four anxious parents with private student loan experience to complete three card sorting activities, and explain their grouping rationales. In the first activity, we learned which resources parents found they found helpful. In the second, we learned what their questions and concerns were and when they occurred in the student loan journey. Lastly, parents combined the first and second activity to share which resources they would use to answer various questions, and when.

The most common unmet resource needs were onboarding tutorials & financial advising. Parents generally relied on informal social interactions (i.e., with friends & family or online forums) in early stages for light information gathering about loans before later relying on more professional or serious resources such as articles, when researching loan options. This may mean that guidance in the hook may be successful if “lighter” than in-application guidance. Some parents perceived the student loan journey to begin during college selection, while others perceive it to begin after committing to a school.

Will we qualify for as much as we need?” was a common concern, and cause for confusion and anxiety.

Beyond understanding resource needs in the broader customer journey, we also needed to understand the right intervention points inside the application. We asked 6 recent student loan customers (4 parents, 2 students) to proceed through a mockup of our client’s loan application, identify any notable decision points, and rate their anxiety for each one. This helped us understand the customer’s perceived major decision points and causes of anxiety within the application.

Application screens shown to participants
The primary in-application decision points identified by customers.

Customers identified five major decision points inside of the application, but the two that provoked the highest anxiety were confirming the requested loan amount, and choosing a repayment option. All participants understood that the “best” loan product was the one with the lowest overall cost (i.e., the loan that requires repayment in-school). Therefore, the customer’s task is not figuring out which loan is best, but if they can afford it.

Customers’ greatest anxiety was whether they could afford the monthly in-school payments of the lowest-cost plan

We mapped these key decision points — “how much to borrow” and “select repayment” — on the existing DSL application flow for us to target through design

Findings from both research methods showed a fascinating pivot in customer anxiety at the product selection page. Throughout most of the journey, parents are concerned with qualifying for enough in loans; however, after facing the reality of those numbers at the product selection page, their concern does a 180, to “wait, can I afford this?” This conflict represented a design opportunity for us to help parents understand how much to borrow in both the hook, and the in-app solution.

Form — Hook

We sketched two versions of a “hook.” Both function as visual roadmaps that anticipate the user’s student loan journey and provide helpful resources at each stages. Key considerations include

  • Is it more useful to have resources vary in form (ie, calculator, visualization, article, etc.), or stick to one type of resource?
  • How might we incentivize the customer to save their progress and return to the roadmap?
  • How can we integrate the roadmap with the application to increase customer conversion?
One hook design — a student loan roadmap with resources mapped to each stage.

Because the hook is a lower-priority design for us, we have temporarily put it on the back burner to revisit in the next sprint.

Form — In-App Parallel Prototypes

After sketching explorations of delivering in-application resources, we converged to design the following at mid-fidelity:

  • A modular view of the application
  • Application onboarding
  • Resource availability within the application flow

After internal critiques and synthesizing findings from the research described earlier, we converged again in round 2 of prototyping to explore two types of resource delivery:

  • Consolidated (providing tools at once, upfront)
  • Distributed (distributing tools across the application)

In-App Consolidated Resource Delivery

This exploration provides up-front and contextualized guidance in a birds-eye-view of the application.

Consolidated guidance prototype
  • Pros: we already know a birds eye view is appreciated; users may like the opportunity to “preview” the application.
  • Cons: will it be too zoomed out, lacking context? To what extent can users really “preview” the application?

By providing guidance ahead of time, customers are prompted to address the “too much/too little” loan amount conflict ahead of time. By resolving this ambiguity ahead of time, users will ostensibly will face less (or no) anxiety at the decision point inside the application, and be more likely to see the application through.

In-App Distributed Resource Delivery

Distributed guidance equips customers with tools embedded in the actual application flow at the key decision points.

Distributed guidance prototype
  • Pros: distributed guidance answers users questions exactly when they occur, which is direct and efficient.
  • Cons: will it slow users down and give rise to new questions and anxieties; will it backfire and cause users to exit the application?

Up Next

  • Test and converge on which prototype to build. Consolidated? Distributed? A hybrid?
  • Design an onboarding experience that can help reduce customer anxieties by preparing them for upcoming decisions
  • Iterate on the hook concept and bringing it into mid-fi (with interactions and features)

Stay tuned for sprint 4, our final sprint. dun dun.

--

--