Redesigning the flow to confirm grant requirements

Background

Mano a Mano is a nonprofit whose mission is to empower immigrant families to become full participants in their community. Serving various parts of Illinois, they have various programs, including Healthy Families, Engaged Citizens and Productive Parents, that provide support to immigrant families.

High-Level Design Objective: Redesign the current flow to solve current frustrations and improve user experience.

Duration: 7 weeks

The problem area

Mano a Mano, like most nonprofits, relies heavily on grants and financial donations.

Every month, Mano a Mano has to send a report to confirm that they are meeting the requirements for their grants. Some of the requirements they need to confirm include number of applications sent and number of initial consultations.

The problem is that employees have trouble navigating the current database platform to find the numbers they need to confirm requirements. This had led to employees having to spend a large amount of time creating separate spreadsheets instead to keep track of the numbers.

The challenge then became: How can we help Mano a Mano more easily confirm the numbers they need for their grants?

Learning a new ‘language’

“I feel like I’m almost learning a new language. It doesn’t come naturally to me”

When I first started speaking to the team, I realized that there were many ongoing frustrations with the platform they were using. The legal coordinators were inputting data for every client into the platform, and then also into several separate spreadsheets because they knew they would struggle confirming requirements using the platform. They then had to continuously update the numbers in the platform and the spreadsheets, doubling the work for them.

But management’s desire to lessen the workload and improve the process led back again to the platform.

Understanding the team’s frustrations

My next step was familiarizing myself with their current system. Being able to dive into the platform helped me understand its functionality. Later, my interviews with the team helped me understand their experience while using the entire system.

Their current process while navigating the platform was fragmented, they were having to click multiple buttons in different places to complete the process. One participant summed it well:

“At a certain point, I feel like I’m just clicking around trying to make something happen.”

There were other frustrations as well: too many options when choosing filters and columns, which was overwhelming for them. And some participants weren’t too sure about what columns and filters to use, which led to countless guesses trying to find the right combination of columns and filters.

Based on the interviews with the team, I was able to put together a current service blueprint that pinpointed where in the process the frustrations lied.

Redesigning to solve frustrations

Based on user frustrations, our goals for the new flow were to:

1. Take out much of the guessing to make the process easier

2. Eliminate the clicking around to make the process more efficient

3. Minimize the amount of options available to prevent cognitive overload

To eliminate the clicking around, I chose to use overlays that would provide a step-by-step guided experience for the user. Adding a dark background behind the overlays would also help reduce the amount of information on the screen, helping the user focus on the most important task.

Then, I moved into minimizing the guessing work and the amount of options available for filters and columns.

By analyzing the different types of grant requirements and the columns and filters needed for each, we realized that there were about 3 main columns and 4 filters that are most commonly used. This helped us create a ‘Previously used filters’ and ‘Previously used columns’ section at the top of the list. This section would include these commonly used columns and filters, along with any other recently used ones.

Previous system…

New system…

Ideation

I then started sketching and developing the wireframes for the process.

Prototyping

Next came the development of the prototype, which would help us test the new design with users to gain feedback.

User testing

Once the prototype and usability test plan were finalized, I began testing the prototype with the team.

My hypotheses were:

1. If we guide the user through the process with overlays, the user will more easily and quickly be able to confirm requirements for the grants. 

2. If we provide a ‘Previously used filters’ and ‘Previously used columns’ as systems of recollection, the user will more easily be able to identify what columns and filters they need.

Making changes based on feedback

By asking the team about their first impressions and how they would improve the system, I was able to gain great insight into how we could make it better for them.

For example, it took them a couple seconds to identify the ‘Add a new section’ button, which helped me see that although what we had was contrasting and visually pleasing, we needed to increase the contrast so they could see the first step faster.

Users also mentioned that they would like to see the filters and columns all in one place, rather than splitting them up in two separate screens. “I’m more of a visual person, so I like seeing everything all in one place.”

Lastly, for the ‘Previously used Columns’ feature, participants said that they wished the they could pick and choose from the subcolumns. Instead of always having to use all the subcolumns inside a main column, users wanted to pick specific subcolumns, like for example, zip code or country of origin.

Based on the feedback provided, I was able to make iterations needed. If more time allowed for it, I would schedule another round of testing with participants to confirm that the new changes improved their experience and process.