Category: research

Categories
design research

Making FAFSA work better for students and families

I led UX research and design work for the U.S. Department of Education’s Free Application for Federal Student Aid, better known as the FAFSA. My work included leading nationwide research with students and families, supporting the phased launch of the 2025–26 and 2026-27 form, and helping redesign one of the most difficult parts of the experience: inviting a parent or other contributor to complete their portion of the form.

Problem

Each year, millions of students and families complete the FAFSA to apply for grants, loans, and work-study funding for college.

The FAFSA is not a typical online form. Its requirements are shaped by legislation, tax policy, financial-aid regulations, and complicated family circumstances. Dependent students must also coordinate with a parent or other contributor, who may need to create an account, provide consent for federal tax information, complete a separate section, and sign the form.

Following the difficult launch of the redesigned 2024–25 FAFSA, FSA needed to rebuild confidence in the experience and identify issues before the next form was released to the entire country.

For the 2025–26 FAFSA, the Department used a phased beta launch. Starting in October 2024, the form was released to limited groups of students and schools before becoming generally available on November 21, 2024.

Our challenge was to build a research program that could identify problems in real time, help teams distinguish isolated incidents from systemic issues, and turn findings into changes before millions of families began using the form.

Approach

I helped develop a continuous research program that combined moderated usability testing, field research, survey monitoring, contact-center feedback, and product data.

Instead of relying only on controlled usability studies, we wanted to observe students and parents completing their real FAFSA applications in the environments where they normally seek help.

Our research included:

  • More than 20 moderated usability sessions with 31 students and parents
  • Direct observation of hundreds of families at FAFSA completion events
  • Research a schools and community-based organizations around the country
  • Daily analysis of post-transaction surveys and beta issue reports
  • Review of contact-center feedback and product data
  • Interviews and feedback from financial-aid professionals
  • Follow-up sessions after participants’ applications were processed

Participants included dependent and independent students, parents, first-generation students, English learners, veterans, adult students, foster youth, students experiencing homelessness, and families with lower incomes.

The participant mix helped us evaluate whether the FAFSA worked across a wide range of circumstances—not simply for students with straightforward family and financial situations.

FAFSA beta events gave us an opportunity to observe hundreds of students and parents completing real applications.

FAFSA “Beta Nights” across the U.S. in 2024. I led UX research efforts and a team of UX researchers to gain insights on the ground with students and families across the U.S. in preparation of the 2025-26 FAFSA launch.

Research at FAFSA events

FSA partnered with schools and community-based organizations to hold FAFSA completion events around the country.

I led a team of UX researchers (FSA folks, U.S. Digital Service, and Accenture contractors) who all attended events in cities including Atlanta, Birmingham, Dallas, Fort Lauderdale, Minneapolis, New York City, Northern Virginia, and Santa Maria, California.

At each event, researchers:

  • Observed students and parents completing the form
  • Conducted short contextual interviews
  • Documented technical and usability issues
  • Gathered feedback from counselors and financial-aid professionals
  • Submitted an end-of-day summary of emerging findings

We instructed UX researchers to “observe first, ask questions second, and help third.” These were real students completing a consequential government form, not participants working through fictional scenarios.


Students and parents complete the FAFSA form at an event at Santa Maria High School in California. 

The events revealed behaviors that were difficult to reproduce in traditional usability testing. Students frequently drove the process for their families. Some completed portions of the form through a parent’s account. Others called parents to obtain authentication codes or personal information.

We also saw how important counselors and community organizations were to successful FAFSA completion. Their support sometimes concealed confusing questions or interaction problems that would have blocked a family completing the form alone.

Observing families complete real applications helped us uncover issues that did not always emerge in a controlled research session.

What we learned

Feedback on the 2025–26 form was largely positive. Students and parents frequently said that it was faster and easier than they expected. From November 1 through November 20, satisfaction for initial submissions remained between 91 and 94.

Research also identified several areas where the experience continued to create confusion:

  • Students had difficulty inviting and matching parent contributors
  • Legal-residency and financial questions were difficult to interpret
  • Students did not always understand whether a college had been added successfully
  • Blank answers on the review page made families worry that their form was incomplete
  • Participants frequently overlooked help text and tooltips
  • Parents struggled to locate invitations on their StudentAid.gov dashboard
  • Students did not always understand their form status or submission summary
  • Participants could not easily find actions such as canceling a correction

The research produced more than 30 recommendations for improvements to the form and its surrounding experience.

Several findings led to immediate content updates and bug fixes. For example, research uncovered a critical issue in the college-search interaction that sometimes displayed or added the wrong institution. The development team addressed the issue in a code update.

Top Findings

  1. Continued issues with inviting a parent contributor, especially among non-SSN parents due to strict data matching and poor conceptual model
  2. There continues to be slight confusion on a few questions such as date of legal residence question and number of family members in college 
  3. Adding colleges and selecting the correct one sometimes didn’t work as expected and discovered a critical bug affecting the college search typeahead 

We consolidated findings from usability testing, FAFSA events, surveys, and contact-center feedback into a shared set of recommendations.

Contributor invite

Inviting a parent or other contributor was one of the most significant problems we identified.

In the existing experience, a student had to enter personal information that exactly matched the contributor’s StudentAid.gov account. This could include the contributor’s name, date of birth, address, and Social Security number.

Students frequently did not know this information. Minor differences—such as “Road” instead of “Rd.”—could prevent the invitation from matching the correct account. The problem was especially difficult for parents without Social Security numbers.

Our analysis showed the scale of the issue:

  • Approximately 5.7% of applications—about 850,000—stopped at the contributor invitation
  • Funnel data showed a 16% drop between the preceding form step and successful creation of a parent contributor
  • Up to 40% of students may have needed to pause the form to obtain a parent’s Social Security number
  • More than 10,000 contributor-invitation contact-center cases were opened during one two-week period

The invitation process placed the burden on students to know and accurately enter information belonging to someone else. It also did not match the way familiar invitation systems work on other digital products.

Contributor invite research

During the FAFSA beta, we showed early concepts to eight students and parents to gather directional feedback.

We then developed mid-fidelity prototypes and conducted 45-minute usability sessions with an additional group of dependent students and parents.

We tested several approaches:

  • The existing personal-information matching process
  • An invitation sent by email with a one-time code
  • A link that students could copy and send themselves
  • Email and text-message options
  • Codes requiring additional identity information
  • Different locations for the invitation within the form
Proposed new consumer-friendly email invite for the FAFSA form.

Personal information was a barrier

Every participant said that they—or their student—would not know all the information required by the existing invitation.

A parent’s Social Security number was the most significant barrier, but participants also raised questions about dates of birth, account email addresses, and last names.

Requiring this information could force students to leave the form before completing their own section.

Students wanted to finish their section first

All participants preferred to invite a contributor after completing and signing the student section.

The existing invitation appeared partway through the student experience. Participants saw the end of the student section as a more natural handoff between the student and parent.

Participants preferred an invitation code

Participants generally preferred a familiar invitation-code model over exact matching based on personal information.

Email felt familiar and secure. Participants also appreciated having a link or code that they could share manually if the email did not arrive.

Replacing personal-information matching with a one-time code removed the need for students to know a parent’s Social Security number.

Initial Recommendations

Based on the research, we recommended:

  • Replace personal-information matching with a one-time contributor code
  • Allow a student to initiate an invitation using an email address
  • Give students the option to copy and share the link or code manually
  • Move the invitation to the end of the student section
  • Carry the code through the authentication process when possible
  • Take contributors directly to a clear “Accept invitation” action
  • Make it clear whether the student or contributor is expected to act
  • Design states for canceled, expired, and previously accepted invitations
  • Conduct additional testing with English learners and people with disabilities

These recommendations combined usability findings with product analytics, survey feedback, contact-center data, legislative requirements, and technical considerations.

Early concepts explored different ways to invite a contributor without requiring the student to enter the contributor’s personal information.

New for 2026-27 form, an easier invite model for the FAFSA form.

Building Empathy

Research findings can easily become another presentation that product teams review and then forget.

To make the findings actionable, I helped organize a large “Building Empathy” session for the FAFSA team. Staff worked in cross-functional groups to review specific problems observed during the beta and develop recommendations for product leadership.

Topics included:

  • Contributor invitations
  • Confusing financial questions
  • College search
  • The FAFSA review page
  • Form corrections
  • Application status
  • The submission summary
  • Account creation and identity matching

The workshop gave staff from design, policy, product, engineering, operations, and communications a shared understanding of what students and parents had experienced.

Cross-functional groups used evidence from research to develop and prioritize recommendations for FAFSA leadership.

Results

Our research and design work helped FSA:

  • Observe hundreds of students and parents completing real FAFSA applications
  • Conduct more than 20 in-depth usability sessions during the 2025–26 beta
  • Establish a continuous feedback loop across research, surveys, contact-center feedback, and product data
  • Produce more than 30 recommendations for immediate and longer-term improvements
  • Identify content issues and product bugs before the national launch
  • Maintain initial-submission satisfaction scores between 91 and 94 during the later beta period
  • Establish field research as a central part of the FAFSA launch process

For the 2026–27 FAFSA, FSA implemented a new contributor invitation process using a one-time code. Students could initiate an invitation with an email address instead of having to know and accurately enter a parent’s Social Security number and other personal information.

The release also included improvements to the FAFSA review page, transactional emails, account verification, account recovery, and authenticated navigation.

The most important result was not a single interface change. We established a new way of evaluating FAFSA: observing the service in real environments, combining multiple sources of evidence, and working with product teams to address problems before they affected millions of families.

Lessons Learned

  • Field research revealed family dynamics and workarounds that were difficult to reproduce in a traditional usability session.
  • Partnering with schools and community-based organizations helped us reach students who are often left out of government research.
  • Combining qualitative research with survey, contact-center, and behavioral data made our recommendations more persuasive.
  • Daily synthesis during the beta allowed product teams to respond while research was still underway.
  • Opening research sessions and workshops to the larger product team helped create shared understanding and buy-in.
  • Research was most valuable when we translated findings into specific product and technical recommendations.
  • Even when legislation limits the solution space, observing users can reveal better ways to implement those requirements.

Categories
design research

Income-Driven Repayment

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)
Provide borrowers an easy and understandable application Educate prospective IDR borrowers about important IDR concepts Build trust with borrowers that FSA is handling personal and financial information securely Empower borrowers to pick a plan that suits their needs Consider how we're communicating new program changes --what's our communication strategy? What happens post submission? Build an experience that helps borrowers understand new IDR rules (consent, taxes, recertification) Design an an experience that accommodates borrower's life situations (married, multiple loans, no income) that doesn't compromise UX Provide delighters throughout the application to reduce users' anxiety of the process (illustations, animations, toast notifications) Aim for the same time it takes to complete the current IDR app
Early draft of experience goals, our driving design tenants as we shifted into early prototyping.
A user flow of the different audiences for IDR
Mapping the initial experience.
Sticky notes that define the success criteria with the product team.
Defining success criteria with the product team.

Results

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

Early concept showing a borrower an initial summary page.
Early concept showing a borrower an initial summary page.
early wireframes of the IDR app
Early concepts of the IDR application, showing the integration with the IRS.
Early concept showing a repayment plan selection page. We tested this version against a horizontal card option.
Early concept showing a repayment plan selection page. We tested this version against a horizontal card option.

High-Fidelity Mockups

A simple splash page serves as an orientation on what a borrower will do in the form, reducing the chances their expectations are misaligned as they begin.
A simple splash page serves as an orientation on what a borrower will do in the form, reducing the chances their expectations are misaligned as they begin.
A loading page indicates the application is securely connecting to gather a borrower's tax information. Borrowers really appreciated this feedback and transparency in the application.
A loading page indicates the application is securely connecting to gather a borrower’s tax information. Borrowers really appreciated this feedback and transparency in the application.
The select a repayment plan page on the IDR app.
The IDR application shows a borrower the exact amount they will pay under the plan and also does several “out year” calculations to estimate the total paid. IDR plans are difficult since each year you may pay something different deepening on what your income was. We added status pills that call out the cheapest monthly payment and the plan with the lowest total paid over time.
The final page of the IDR application
A borrower can be done in as little as 8 minutes (average time to complete).
A borrower's dashboard with an action required IDR app
A borrower with a “action required” status on their application.
An IDR app in the "in review" step
A borrower can easily track their application status at any time and get email updates on when it’s processed. This feature’s goal was to significantly reduce the times a borrower called a customer service rep for a status check.
processed IDR application
An application that was successfully processed.

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
Early concepts on the customer journey and back-stage actions relating to autorecertification.
Early concepts on the customer journey and back-stage actions relating to autorecertification.
Mapping the email and service design for borrowers in an IDR plan.
Mapping the email and service design for borrowers in an IDR plan.
Draft email for a borrower who successfully “autorecertifies”

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.
Categories
design research

Student Loan Debt Relief

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.

student loan debt relief form spanish

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.

Application details page within a borrower’s account.
The different statuses we developed.

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!
Categories
research

Federal Student Aid Top-Task Testing on StudentAid.gov

view studentaid.gov

Problem

Federal Student Aid, an office of the Department of Education, manages StudentAid.gov, the main website that supports Title IX higher education funding in the country. One of the most visited federal government sites, StudentAid.gov handles more than 20 million FAFSA (Free Application for Federal Student Aid) submissions per year, and supports other relevant tasks like a personalized dashboard with student’s aid summary, digital, self-paced counseling for student loans, and applications for income-driven repayment plans.

Approach

This was the first top-task usability test to be conducted on the production site. Various individual products and features on StudentAid.gov have been usability tested independently, either during design sprints or after release. This was an opportunity to take a holistic view of the site and incorporate more content-based pages.

Our goals were to:

  • Evaluate 10 common tasks and scenarios with users
  • Uncover any navigation pain points and unexpected issues
  • Test on both desktop and mobile devices
  • Evaluate the site’s content in context with top tasks on content pages

We tested with a diversity of students, parents, and student loan borrowers in repayment with different incomes, ethnicities, and geographic location across the U.S.

Results

Key Takeaways

Mobile navigation: The “Log In” and “Create Account” links are swapped with several logged-in tasks/links once a user logs in. Many participants didn’t notice this is where key authenticated pages were located since the menu’s hierarchy focuses more on broad topics and content pages.
  • Most users don’t associate Federal Student Aid with the FAFSA. The term FAFSA has much stronger household recognition than Federal Student Aid, despite Federal Student Aid’s efforts to consolidate most of its program sites into one website.
  • The site’s main mega-menu on desktops has room for improvement. A lot of users misunderstood categories such as “Manage Loans” which users thought was more personalized to them.
  • When users log in, there is a utility menu that appears. Many users didn’t notice it since it was not prominent in the main navigation area and on mobile, it appears below other sections within the navigation.
  • Long content pages meant users often hunted and pecked for information, resulting in longer than expected time on task metrics. Very few users used the site search, despite its prominence.
  • The mobile website’s navigation proved difficult for users. Many felt the menu was overwhelming and they couldn’t easy find the logged-in pages, such as Dashboard, My Aid, My Docs, and Settings.

Key Recommendations

On mobile, the site’s logged-in menu prioritizes Help Center and Contact Us over a user’s main pages like Dashboard and Aid Summary.
  • Continue mobile testing as part of a core user research approach
  • Redesign the in-page navigation for content pages to better support anchor/jump links within the page and to provide mobile users a better experience
  • Improve the mobile website’s navigation and consider how the logged-in links interact with the main site’s navigation. Consider a robust, secondary navigation on logged-in pages.
  • Conduct a card sort on the site’s main topics to evaluate the site’s information architecture and navigation schemes. Consider condensing the amount of links in the site’s main navigation.

Lessons learned

  • Remote testing with mobile devices proved easier than anticipated. Using Microsoft Teams, we were able to easily have participants share their phone screens
  • Top-task testing, outside of feature-based testing, is a helpful activity and should be part of any evaluate user research approach. Developing a cadence for this type of testing insures a regular interval for continuous improvement discovery
Categories
design research

JMU’s Health Policy Initiative

view health policy site
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.
view health policy site
Categories
blog research

What conducting nano usability testing for Marriott.com is like

Usability testing is one of the most useful tools to uncover how well a website is supporting users’ main goals and tasks. Testing can occur anytime during a development of a new system, but it also can be used to discover how well a system is performing; this is often called benchmark usability testing. For the purposes of this testing, we conducted a nano usability test with three users of Marriot.com using the production live website.

Our nano usability test is a great first start to evaluating how well Marriott’s online booking system is working for users. Testing helps to uncover usage patterns, challenges encountered by users, as well as additional research questions. The purpose of testing is to not walk away knowing how to fix every issue with the system. Rather, it’s a first step to understanding where improvements might be made within the online booking system.

To kick things off, we generated three major tasks and recruited three participants.

Task completion

Overall, participants performed well. Only participant 2 had trouble understanding the larger concept of Marriott.com offering different hotel brands within the same booking experience. Users commented that the process felt “easy, and relatively quick” given two users knew a destination and dates they desired. Two out of three commented that they most likely would first compare prices with another travel website like Kayak or Priceline before purchasing. 

TaskParticipant 1Participant 2Participant 3
Select destination, date and detailsCompletedCompletedCompleted with difficulty
Select hotelCompletedCompletedCompleted
Select roomCompletedCompletedCompleted with difficulty

Participant 1: Had very little trouble picking a destination and dates from the main homepage. On the results page, they noted they liked how different hotel chains within the Marriott brand were displayed, but they couldn’t find a way to sort by price, a filtering option they often like to use. On the room selection page for the Park Central Hotel in San Francisco, they said they liked the different price options, and the prepay and save would be a feature they’d use. Often, they would pick the cheapest room option.

Participant 2: This user was using a smaller laptop and didn’t initially see the homepage call to action booking feature. They selected “Find and Reserve” which dropped down the same selections to pick a destination and date. Once they searched for Austin, Texas, on the results page, the user was briefly confused as why there were multiple hotel brands displayed. “I guess Marriott must own them,” the user questioned. Another thing the user noted on, was why the the results list showed hotels not available on the dates selected. They noticed a checkbox that filters to hotels available, but was confused why that wasn’t the default option. They selected a downtown Austin hotel and selected a prepay room; although commented on how long the title of the room was.

Participant 3: This user didn’t have a destination in mind, so they selected the Deals and Packages page, and selected the Hawaii vacations link. The system sent the user to the vacations by marriott site, a separate site with a different booking experience. On this page, featured hotels were listed but with no price. The user selected the first option, then was prompted to input a date and departure city. Once the list of results was returned, the user selected the first option for the king room. While they successfully booked a room, albeit through the vacations website, they did ask “Am I on the right site? Did I do this right?”

Main findings: user challenges

  • Finding an option to sort by price was difficult
    • Participant 1 had difficulty finding an option to sort the list of hotels by price, which doesn’t appear to be an option within the results page. Sorting by price is a common organization scheme that most travel sites offer. On the results page, the default scheme is to sort by distance.
  • Deciding on a room type took special care, since the room’s titles are often long
    • While choice is often good for users, too much can overwhelm them. In this case, selecting a room at a particular hotel was somewhat difficult. This was due to the fact that hotel rooms have long titles, with a strong font that makes it difficult to read. This can increase users cognitive load and easily lead to frustrations. One room for a Courtyard Marriott was titled, “Cool Weekend Getaway, 10 percent off 2 night stay, prepay in full, non-refundable if cancelled less than 1 day before arrival, no changes, based upon availability” in a large, bold font.
  • The Marriott vacations experience is completely separate from the main Marriott.com booking experience
    • One user that didn’t have a destination in mind selected the deals section of the website. After browsing about Hawaii, they were taken to the Marriott Vacation website, a separate experience that had a different look and feel. This separate site may confused users and there wasn’t any indication that you were leaving the main Marriott site.
  • The hotel results list often included hotels not available or coming soon
    • Even though a user selected dates for a trip, the results page often displayed hotels that were not available or “opening soon.” The option to display only available hotels was not selected by default. Showing all hotels in the list may be helpful for someone that is browsing, but could be frustrating to someone that knows the dates they want to travel. More results in the list means more items users have to scan through, which can increase cognitive load.

Additional user research questions

Our test stopped at the payment section and was narrowly focused only on the booking process. Since we were running a quick nano usability test, we didn’t have time to prepare fake information to use in the payment step. However, this is a critical step that deserves to be tested in the future. In addition, further research questions may surround:

  • What additional challenges are encountered by user attempting common tasks on Marriott.com? Tasks could include:
    • Changing or canceling a reservation
    • Signing up for loyalty program/credit card
    • Contacting customer service
  • What substantial usability impediments exist? (items that may influence a user to abandon the website or booking process)
  • What are additional customer insights that may help Marriott’s digital strategy?

One of the most important next steps is to ensure Marriott’s website has clearly identified and measurable goals. Understanding Marriott’s goals and business strategies will help determine research activities to further improve Marriott’s digital products.

Conclusion

Conducting user research helps designers conceptualize systems and processes that match how users think. Designing an experience that just plain works well doesn’t happen with luck. Through proven research methods and user engagement, organizations can build products with users, rather than “for” users. Involving users in prototyping, development, and testing, is a necessary step that helps give a product a higher chance of success.

As demonstrated with the nano usability test, research doesn’t have to be a long, drawn-out process. With only three users, we were able to quickly identify areas of the booking process to explore. This quick testing method gave us insights that we didn’t have before. Testing often allows a continuous check-in on how a design is performing and gives organizations insights into how to improve their products. Research is a great way to ensure designs match user expectations. Any form of research, big or small, assists with improving the user experience for users and helps to align digital products with the goals of an organization.

Categories
research

Brightline App Mobile Usability Testing

Brightline is a new high speed train service in Florida. We were tasked with testing the booking app and related top tasks. Using moderated in-person usability testing, we recruited nine participants and generated a findings and analysis report based on our analysis.
view UX brief
view test script

The Problem

We wanted to conduct usability testing to identify potential improvements for the booking app.

Our research goals were to:

  • Observe user patterns and behaviors as they attempt a set of common tasks using the mobile application
  • Identify how easily users accomplish common tasks
  • Understand users’ experiences and expectations as they work with the app
  • Gather user attitudes and perceptions as they relate to this type of booking app

Approach

Our formative usability study followed the “think aloud” protocol by asking test participants to describe their thoughts as they attempted to complete three separate tasks. We recruited nine participants for this study. We used a moderated in-person testing method.

Video screenshot of conducting in-person mobile usability testing.
Video screenshot of conducting in-person mobile usability testing.

Results

  • Each video was observed, which helped surface patterns and themes based on how users navigate the app and attempt the tasks.
  • From the initial observations and findings, themes were sorted and given prioritization based on frequency of the issue and other qualitative feedback. Post-test questions also help to influence the findings.
  • We then developed recommendations that address several of the findings.
Main takeaways:
  • The booking process is clear and the app gives users a straightforward entry point to begin booking a trip.
  • The app’s overall performance and technical issues can easily frustrate users.
  • Aspects of the seat selection task in the booking process has room for improvement.

Lessons learned

  • Usability testing on mobile apps can be difficult to see how a user is interacting with the app. Having a way to record the phone screen or video record the phone is important so you can later view how the user is interacting with the app.
  • If possible, make users comfortable and allow them to use their phone. If they are not comfortable downloading an app, have a backup phone ready for them to use. People are often the most familiar with their own devices.
  • Probing users to “think aloud” is an important reminder when conducting in-person moderated usability testing.
view UX brief
view test script
Categories
research

Weather Underground Usability Testing

view full report
I conducted remote unmoderated usability testing for the Weather Underground website. We tested top tasks on the site and gained user insights into how well the site works for them.

The Problem

We tested Weather Underground’s website based on common tasks with the intention to see how well the site performs.

Our research goals were to:

  • Observe user patterns and behaviors as they attempt a set of common tasks
  • Identify how easily users accomplish common tasks
  • Understand users’ experiences and expectations as they work with the website

Approach

Our formative usability study followed the “think aloud” protocol by asking test participants to describe their thoughts as they attempted to complete three separate tasks. We recruited five participants for this study. We used an unmoderated remote testing service called Validately, which recorded participants screens and audio. Four out of five testers check the weather regularly.

While five participants may appear small, most common usability issues can be identified with a small sample since we are more focused on qualitative feedback and general experiences.

How we analyzed the data:

  • Each video was observed, which helped surface patterns and themes based on how users navigate the website and attempt the tasks.
  • From the initial observations and findings, themes were sorted and given prioritization based on frequency of the issue and other qualitative feedback. A set of questions were asked after the test, which also influenced the findings.
  • Using the findings, we developed recommendations or identified further areas of research.

Results

Main takeaways include:

  • Users easily found a way to find local weather forecasts.
  • Navigation groupings and labels confused users for two of the tasks.
  • The website features large ads that can affect how users find information and use navigation.
  • Static content pages and their organization could be improved.

Lessons Learned

While unmoderated remote usability testing offers an efficient way to test, its not as personal as in-person and you may have to test more remote users due to technical issues encountered during testing.

Categories
design research

Billings Public Library Site Redesign

view full report
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.
Example persona for Isabella, one of our primary personas.

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
 Isabella (P)Wayne (P)Lisa (S)Martín (S)
High Priority Tasks 
Browse or find a bookYesYesYes 
Place a hold on a bookYesYes  
Find an ebook or audiobookYesYesYesYes
Medium Priority 
Reserve a conference room YesYes 
FInd out when the library is openYes YesYes
Find out how to get a library card  YesYes
FInd out about events Yes Yes 
Low Priority 
Look up a specific class offering  Yes 
Find out information about volunteering Yes  
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
Initial site structure based on card sorts conducted with users.

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
An early sketch of the Billings Public Library homepage with revised navigation and key homepage features.
A higher-fidelity version of the homepage was created. We tested five tasks with a first-click test, seeing where users would go to find out information. Users had nearly 100 percent success rates, demonstrating the proposed information architecture, homepage experience, and overall site is working for users.

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.
view full report
Categories
research

Marriott Booking Process Research Study

view full report
Hotel bookings in the age of Airbnb — I look into how the Marriott Bonvoy consolidates nearly 30 brands of hotels under one site and what the user experience of the booking process is like. With UX research, I find discover insights into the booking process as well as recommendations for Marriott to improve its overall digital strategy.

The Problem

As part of a user research study for graduate school, I investigated the Marriott Bonvoy’s booking process and overall customer experience with the web-based booking process and Bonvoy rewards program.

Driving the user research was clearly identified business goals

  • Increase hotel bookings via digital properties by 10% 
  • Increase reservations for their Luxury and Lifestyle Collection hotel categories 
  • Gain 10,000 incremental members of the Marriott Rewards loyalty program in the first quarter after the redesign 
  • Decrease by 20% the number of people starting and then abandoning a reservation 
  • Increase by 5% the number of people choosing a hotel and flight package (vs. just booking their hotel alone)

Approach

Our research goals were broad and designed within the context of the Marriott redesign project. Not only were we curious about how users interact with Marriott services, but we were also interested in more about how the public travels, uses travel sites, and rewards programs.

Research goals:

  • Understand user patterns, processes, and challenges in booking a hotel room through a digital service
  • Discover customer satisfaction and opinions of hotel loyalty programs
  • Understand user usage patterns of desktop/mobile sites vs. smartphone apps for travel related services and information
  • Learn about customer attitudes and behaviors toward booking more than just a hotel room (airfare, etc.)

We conducted user interviews with target users. In each interview, we asked a series of questions relating to booking travel, rewards programs, device usage, and vacation packages. 

About the participants

  • Our three participants ranged from late 20s to early 60s
  • All participants travel and stay in a hotel at least 3-4 times a year
  • Only one participant regularly books travel through Marriott.com; same participant has Marriott’s app
  • All participants have some sort of travel app on their phones, and use their phones regularly to manage travel bookings

Results

The recordings and notes from the three user interviews were analyzed using summarization and deconstruction methods. Summarization involves collecting similar observations from the interviews. Generalization involves taking specific insights from the interviews and applying them as larger statement to form a research finding.

In total, 13 major themes emerged as well as subsequent recommendations. Our initial research provided useful insights into user behaviors, attitudes, and goals.

Booking hotels

  • Location of hotel in relation to city attractions is often an important factor when picking a particular hotel. Other items users mentioned: free wi-fi, breakfast options, on-site restaurant or coffee shop
  • Users who may appear to “abandon” their hotel bookings are most often conducting research for their trip and not yet ready to reserve a room.
  • Third-party travel sites like Expedia are often used and trusted for booking travel arrangements. Better deals and clear methods for customer service were noted as reasons users prefer these sites.
  • Hotels generally don’t do a great job at being transparent about room type; photo displays of hotels are often more focused on the business traveler and not the leisure traveler

Vacation packages and deals

  • Vacation packages and deals are not widely used; many feel they are not great value or find it too difficult to determine if they actually save you money

Hotel rewards programs

  • A loyal Marriott rewards member feels as though Marriott keeps “upping the ante,” making it more difficult to redeem points and free night offers
    •  “[Marriott is] making you jump through hoops to redeem a free night for the credit card offering”
  • The Marriott Bonvoy app can be helpful for rewards members to quickly check point values and look back at old trip itineraries

Mobile apps and usage

  • While mobile usage is increasing, users noted that for complex trip planning and comparisons they prefer to use a laptop with a larger screen
  • Mobile check-in is not a commonly used feature; most prefer to check in at a counter with a person

Hotel rewards programs

  • Simple perks like free water at check-in for Marriott rewards members can go a long way to demonstrate customer appreciation
  • Loyalty reward programs are widely used but many feel as though they never reap benefits from them; often don’t travel enough to get any perks
  • Infrequent travelers feel as though the rewards programs aren’t designed for them; although still would be willing to sign up for one that gave them benefits

Hotels vs. Airbnb rentals

  • Hotel rooms often don’t feel as good value as larger accomodations found on Airbnb. Group travel or families looking for a hotel suite often feel priced out of a hotel and will instead look at renting an apartment or house. Hotels don’t do a great job catering toward this market.
Users commented that they like how extensive Airbnb’s filters are, specifically allowing to input the number of beds in a listing.
RECOMMENDATIONS

Further research may be required, but there are some key recommendations that could be addressed now. These are not in any particular order and some may be more complex than others.

  1. Explore the concept of better advertising cost of vacation packages so that users can quickly identify its “value” in comparison to traditional booking costs
  2. Identify non-frequent traveler rewards perks and better communicate them to travelers. This may help increase sign-ups and usage of these reward programs.
  3. Add option to filter by price when users are browsing for hotels
  4. Conduct a content audit of imagery used throughout hotel brands; ensure image selections are designed for the average traveler (more photos of room types, less of conference rooms spaces)

Consider integrating the map view of hotel listing more prominently to support users trying to select a hotel in a particular area of a city. Support users picking a hotel near local attractions.

Marriott’s slideshows for room images feels outdated and is slow to control. Consider redesigning this feature and testing with users.
Price was identified as one of the most important factors when deciding between hotels. The Marriott site doesn’t currently support the option to filter by price. We recommend they add this feature.
Additional research activities

In addition to the exploratory research and related findings, I recommended further research studies.

  • Conduct a comparative analysis of competing hotel brands’ apps and services to better understand their offerings and features.
  • Perform more extensive usability testing with users that are familiar with the Marriott brand to discover current customer behaviors, opinions, and attitudes.
  • Perform a card sort or tree test to see how well the current site structure and app structures match how users think about the information.

Lessons learned

  • Remote interviewing can be prone to technical difficulties that can affect the quality of information you collect
  • Having a script and moderation guide can greatly assist in conducting user interviews and helps you stay consistent with the information and questions asked of participants
  • Developing pre-research assumptions (or hypotheses) is a method of guiding your research to either validate/in-validate an assumption. Collecting these from stakeholders can make the process participatory.
view full report