Category: design

I worked as the UX design lead for the U.S. Department of Education’s overhaul of the entire income-driven repayment (IDR) application and introduction of a new, more affordable IDR plan.

Problem

The FUTURE Act was a new law that cleared the way for Federal Student Aid (FSA) to build new back-end integrations with the Internal Revenue Service (IRS) to more quickly connect to a student loan borrower’s tax information to calculate family size and adjusted gross income. This was groundbreaking for borrowers, as this new integration allowed seamless transfer of information and more quickly determined eligibility and payment amount right in the application. This was a forcing function for FSA to build a new application process, and launch a feature we call “autorecertification” meaning that an IDR borrower would only need to apply once, and we’d recertify your income each year and recalculate their payment annually without the need for any forms.

Approach

Given the legislative mandate of a new IRS integration, we needed to understand the entire student loan servicing environment (the companies FSA contracts to actually collect/process student loan payments) and what our limitations where. As with most government projects, we were working under tight deadlines.

I started with an initial discovery sprint working with others to interview student loan borrowers on the current experience with repaying loans under an IDR plan. We also conducted usability testing on the legacy application, and held several interviews with student loan servicers to unpack their back-office operations. Our main insights were:

• Borrowers are often surprised to find there are multiple IDR plans; 50% have their servicer pick a plan
• Paper application volumes are higher than expected, with up to 30% being processed as paper
• Critical IDR concepts, like when to enroll and requirements to “recertify” confuse borrowers
• IDR borrowers top reason for calling is to get a status update on their application as they wait until their servicer processes their app
• Providing documentation of income after the application can be a cause of fallout and requires lots of back and forth with a loan servicer. Servicers spent a considerable amount of time manually calculating plans with and processing paper apps
• IDR forgiveness is often misunderstood; many don’t understand remaining balances may be counted as income. Borrowers want more clarity on their progress toward IDR forgiveness

Initial Recommendations

These helped FSA save time and cost early on as the it was before the work was under contract with the development vendor and servicing teams.

• Allow borrowers to save applications along the way to gather necessary income documentation (if needed)
• Include the option for borrowers to upload income documentation in the application vs. having to mail/process it afterwords
• Allow loan servicers to access manual uploaded income documentation within an electronic application; provide a way for borrowers to report their income/pay frequency
• Allow borrowers to track their apps via their FSA account
• Provide IDR borrowers a payment count and progress toward ID
  forgiveness. Provide more clarity around IDR forgiveness to reduce false hope around early forgiveness
• Remove the cosign flow (aligns with new IDR regulations)

Results

After rounds of usability testing, we felt confident in several new aspects of the application and flow.

High-Fidelity Mockups

Autorecertification

In addition to launching a new application, business process, and a new user experience, we also launched a new “autorecertification” process. This process allowed us to “recertify” a borrower’s income without them needing to do anything. We would simply email them and let them know if it was happening. If their income changed since their last tax return, they could simply do a recertification on their own and override the automatic one. We knew we needed to:

• Provide proper notification to a borrower about payments that are changing and give them time to adjust and recertify on their own
• Reduce the burden on borrowers that don’t need to take any action (one win was getting approval to place the monthly payment amount in an email so a borrower doesn’t actually have to log in to view anything)
• Make the process feel natural and keep the borrower in control

Results

• Developed and implemented an entirely new income-driven repayment plan and application which reduced the overall time to completion by 5 minutes.
• Increased the overall satisfaction score from 82% to 89%.
• Designed an “autorecertication” process where student loan borrowers don’t have to reapply each year, saving borrowers millions in lost hours filling out forms.
• Significantly reduce paper submissions by marketing the new IDR application and ensuring loan servicer customer service reps drive callers toward the online application.
• Helped increase IDR enrollment to more than 10 million student loan borrowers.

Lessons Learned

• Early stakeholder interviews were critical to establish trust with the project team, as well as loan servicers back-office processing folks.
• Allowing an initial discovery research sprint saved development costs because we could focus on drafting contract requirements with a high confidence in knowing what the system needed to support to deliver a user experience that matches user needs and goals.
• Opening up usability testing sessions to the entire project team helped create early buy in for our research efforts.

I worked as the UX design lead for the Student Loan Debt Relief project at the U.S. Department of Education’s office of Federal Student Aid.

Problem

The U.S. Department of Education wanted to implement a broad student loan forgiveness program for most student loan borrowers. Borrowers under the 120k income threshold would receive up to $10,000 in forgiveness and some borrowers who had received a Pell grant would get $20,000. We had less than 3 months to design, develop, test and launch an application for 30+ million student loan borrowers.

Approach

Our goals were to:

• Make the form as usable and accessible as possible to maximize forgiveness opportunities for borrowers
• Minimize burden on the public by having to document income
• Move quick to implement an entire forgiveness program within 3 months
• Ensure the system can handle the volume and built trust with the public

We knew we needed to develop a simple application and form but were nervous about the tremendous amount of traffic from people applying for forgiveness. It was decided the form would be available to unauthenticated users and our back-end systems would match personal identifiers in the application to a borrower’s loan records. Due to time constraints and reducing the burden on borrowers to provide income documentation, it was decided to build an “attestation” form, basically a form where you are agreeing you make under a certain income threshold. Then on the backend, a predictive model would flag certain borrowers who would need to provide additional income verification to reduce fraud.

Starting off with Legalize

As with government forms, our initial concept was a 2-page form but loaded with dense text that our team were told was necessary to include.

Realizing the form’s rather simple logic, we worked to refine the design and worked with our policy team to reduce text where we could.

Usability Testing Before Launch

We recruited dozens of student loan borrowers and conducted usability testing in English and Spanish. We learned that some borrowers felt the form was “so easy they thought they missed something.” We were able to tweak some language and helped build out a splash intercept page that we deployed to studentaid.gov.

Results

The form was launched in fall of 2022 during a “beta” period. There were 24 million submissions in the first week. But we were not done refining the user experience.

End to End Experience

In order to ensure borrowers were properly notified about progress we built additional elements into the student loan debt relief process.

First was ensuring that after each application submission, borrowers got a clear and concise message confirmation email. We tested the language of the next steps with borrowers and revised to improve comprehension and clarity.

Proper Status of Forgiveness Requests

The other element we made sure to build was proper status since we knew it would take a few weeks to process the forgiveness requests and actually have it applied to borrowers accounts. We quickly built an ability for customer service representatives to be able to check application submissions in Salesforce, and we created a plan to launch a “status tracker” for a borrower’s application on studentaid.gov.

Ability to Verify Income if Needed

One last piece of the puzzle in the entire service delivery and design of student loan debt relief was to create an easy process for borrowers who were chosen for income verification to be able to easy upload their documentation. The challenge was the initial application was not behind a log in, so we had to connect the application request to a borrower’s account so they could securely upload income documentation.

Lessons learned

• While there wasn’t a lot of time for upfront discovery research we were able to leverage past usability testing on studentaid.gov forms and flows and leverage existing design patterns that had been properly vetted with users.
• Cross team collaboration was critical in the projects success, despite the Supreme Court striking down the program
• Ensuring the application was user tested before launch was initially difficult as folks were nervous about the application leaking to the public, but we ensured testers knew the sensitivity around the form
• Forms don’t need to be complex or even muti-step to be successful. Sometimes people just appreciate how easy something is and this can increase trust and confidence in the system.
• We got some much needed good praise about our efforts!

This website project was part of a grant with a team of five faculty members at James Madison University with a goal of educating the community on health policy. The goal of the initiative is to educate the community about JMU’s health-related civic engagement in the community and the world.

The Problem

As the lead project designer, I worked with various stakeholders to conduct information gathering sessions. While a relatively new initiative from James Madison University — the Health Policy Collaborative had little visibility and lacked a dedicated website.

Approach

I conducted research which included meeting with faculty, nurse practitioners, state policy experts, and local politicians. These meetings and interviews helped get a sense of what the newly formed group, the Health Policy Collaborative, would want to showcase on the website and how the general public would receive the information.

We learned users’s top tasks and goals as well as clear goals from our stakeholders.

Results

After identifying target audiences and developing user personas, I explored an information organization activity, attempting to piece together the various themes and information needs of the site.

Working inside the JMU content management system was limiting, but we were able to do certain things on the site, like pull in outside news sources. I led an effort to include an interview I conducted with a health policy expert on Medicaid expansion in Virginia.

This relatively short project meant the site’s needs were going to change in the future. My goal for this group was to create them a foundation website, that presented their information clearly and professionally.

This meant creating a information architecture framework that could grow, and not impact the discoverability factor for users.

Considering JMU’s site wasn’t responsive at the time, performance and usability on a phone or tablet still remains an issue.

Lessons learned

• Logistics of scheduling interviews with stakeholders can prolong the time necessary to get information critical for a website.
• Content management systems (CMSs) often have limitations and it’s important to understand the technology behind it in order to not waste time designing something you know will not work.

Public libraries serve an important community role. Having a website and services that work well for people helps libraries meet their missions. I researched how users want to use a library website and generated ideas and recommendations on how to improve a local library site.

The Problem

As it was understood, the current Billings Public Library’s website had grown over the years and information became increasingly difficult to find. The site’s organization schemes and structures didn’t appear to be working and wasn’t supporting users’ key tasks. With focused research, iterative design and clear communication, we’ve developed research and design artifacts that will help improve the site and focus it more on users’ main goals.

This project was for a graduate school assignment.

Approach

Conversations were held with librarians at the downtown branch of the Washington, D.C. Public Library.  User interviews helped determine target users and their behaviors, patterns, and goals.

Our research goals were to:

• Identify target users
• Learn about users goals and top tasks on library websites
• Understand user challenges or limitations 
• Identify any content holes or enhancements to the site

In addition to interviews, we conducted research into other library websites, industry research around best practices and common uses, and UX case studies on library website projects.

Results

What we learned about users

Library websites are used by a variety of audiences, and our four personas describe likely library site users. (see detailed personas on the next page)

• Isabella the mother who leads a busy life but enjoys reading and listening to audiobooks.
• Wayne the retiree who uses the library as a community meeting space.
• Lisa the student who likes to read and use library computers to do homework.
• Martin the new resident that wants to learn about the local library.

What users want to do

Based on our research, users top priority tasks are to:

• Browse or find a book
• Place a hold on a book
• Find an ebook or audiobook

Following the primary tasks, the site needs to easily support users that want to:

• Reserve a conference room
• FInd out when the library is open
• Find out how to get a library card
• FInd out about events
• Look up a specific class offering
• Find out information about volunteering

Task priority: by primary and secondary personas

recommendations

There are a number of ways to organize and classify information on a website. In the case of the Billings Library, using an ambiguous organizational scheme with both audience and topical schemes will support users in finding key information and offer a simple way to navigate through the website.

Considering the current site uses an audience scheme to segment certain content for seniors, adults, teens, and children, continuing an audience based scheme works because content is very audience specific. However, we’ll combine Teens & Children and Adults & Seniors into two groups.

The rest of the information on the site fits nicely into a topic-based scheme, based on several key categories. The proposed main categories for the Billings Public Library navigation:

• My Account
• Digital Services
• Job Training & Education
• Library Services
• Research
• About
• For Kids & Teens
• For Adults & Seniors

Homepage Features

In addition to the new navigation, enhancements to the homepage will help promote the site’s primary tasks discovered during research.

• “How do I feature,” which lists common how-to tasks (get a card, renew a book, etc.)
• Hours and Locations
• Browse the catalog
• Site search
• Events
• Featured books (We Recommend, Awards, Bestsellers, New Titles

Lessons learned

• The value of content audits can not be overstated. They help you identify what types of content you currently have on your site and can help reduce the content on your site.
• Complex site maps can be difficult to make but are an important artifact to communicate your site’s information architecture to key stakeholders.

I was given the opportunity to research and design improvements to a organization-type app that focused on reminders. Using UX research methods and design iteration, I helped to re-think the direction for the app.

The Problem

The ReminderX mobile app was in need of a re-think. The clients wanted to find out what direction the app should take, and ways it can be improved. My role was to help build out a road map for the app based on research. From there, I was tasked with re-designing the app.

Approach

Conversations were held with four separate participants. User interviews helped determine target users and their behaviors, patterns, and goals.

Research areas explored:

• Identifying digital tool (reminder apps, calendars, etc.) usage by participants
• Understanding behaviors of participants in relation to creating lists and setting reminders (note-taking, digital apps, etc.)
• Understanding challenges or limitations of current processes

Additionally, participants offered feedback on the ReminderX app, which helped identify future enhancements and improvements help increase the overall user experience and adoption.

Results

Analysis of the research helped identify findings and recommendations for ReminderX. Based on research, a user persona was developed to help the design process. Additionally, I created design tenets, or guiding principles for the app.

1. Keep onboarding simple – many users are currently using Google apps that offer lists or event reminders, which don’t require additional logins or accounts. Where possible, leverage other app’s logins (Google or Facebook) for ReminderX. In general, keep the signup process simple.
2. Make information accessible – users expect their information to be stored and saved on the cloud where it’s easily accessed from device to device.
3. Allow collaboration to encourage adoption – in the professional world, team’s need to share information effectively, and this includes tasks and reminders for team projects or related disciplines. The app should offer sharing or collaboration features.
4. Keep to-do lists flexible – users have a variety of needs when it comes to list types. Certain lists are for short-term related tasks or reminders, like grocery lists, to longer term lists of personal or work-related goals. Additionally, users may just want to create a simple note to jot down ideas. Categories or labels may be important for users to organize lists.
5. Think post-it notes – emulate the positive experience people feel while checking off an item on their handwritten lists.
6. Allow users to declutter lists – people often make many notes and lists throughout the week, and allowing them to easily organize them is paramount. Archiving of old information should be considered.
7. Consider offline use – many users are creating lists for shopping. Lists should be cached or locally saved in the app so in the event of poor reception, lists still load in a store.

Design and interaction

Using the research findings as a foundation, I started to sketch new ideas about the app’s workflows and task flows. I iterated these sketches and concepts into digital wireframes. From there, I passed the designs along to the development team to build.

Lessons Learned

Sketching can be a really effective method for iterating ideas. It allowed me to not be too worried about how the design actually looked. Instead, sketching kept me focused on the workflows and overall larger picture.