Testing Wireframes, Round 2

As a refresher, we have been testing wireframes using a method called ‘think-aloud testing’ in which participants are asked to complete tasks in our prototype banking app while vocalizing their stream-of-conscious thoughts. Over the last couple of weeks, we added financial modeling functions to help users better budget their money. The new functionality was the focus of our second round of user testing and I learned significantly more than I expected.

Participant Overview

Screen Shot 2019-02-13 at 3.50.52 PM

With the help of the four interviewees above, I was able to identify many problem areas with my prototype. If I were to elucidate all the issues the users found, this post would be a novel. So I will focus on the problem areas that were most common among all participants, and what I learned from their feedback.

Stay Away From Making Things Too Text-Heavy

The first bit of feedback was that some elements are too wordy. With banking and finances, there is a thin line to walk between too much and not enough confirmation. My prototype has several modals, which are windows that sit on top of an application’s main window (think, pop-up). Too many modals make the app feel burdensome and clunky while too few could lead to actions a user might wish to undo. Based on the user feedback, I used too many modals and the windows themselves are unnecessarily verbose.

Create Budget (pre-enter info)

The screen to the left shows information a user sees when manually creating a budget. One thing I noticed was that several participants were clicking ‘continue’ without reading the text. When Andrew came upon this screen he said,

“I don’t even read this stuff. I just click continue.”

Sam echoed this sentiment, saying,

“That’s kind of a lot of text for me right now. I can probably just figure this out on my own.”

One way to fix this issue would be to relocate this information. For example, I could make an info icon ( ⓘ ) that users could click if interested. Another way to address the issue would be to create a tutorial that walks the user through the beginning of the budget creation process.

My takeaway from this problem area is that the general public has come to expect simplicity. There is a certain elegance that comes with not having to explain something in a paragraph of text. Moving forward I will embrace a less-is-more mentality when thinking about how to introduce new functions.

Presenting Information in an Intuitive Way

The next problem area came from participants’ confusion when looking at the budget overview screen. Specifically, users did not find the pie chart that shows a high-level overview of their budget to be helpful or meaningful.

Budget Dash (new saved budget)Most people don’t think about their finances in terms of percentages. Adam summed up the feeling of several other participants when he said,

“I don’t think of spending 37.5%, I think of spending $2,000 or something, you know?”

This was something I overlooked while making design decisions for this screen. I personally like seeing what percentage of my income I am spending on different budget categories, and this is why testing with others is so important to the design process.

One way to address this issue would be to replace the percentages in the chart with dollar values. However, this could make the screen look too busy, especially if more budget categories are introduced. Therefore, I believe replacing the pie chart with another graphic that shows dollar values would be the best course of action.

I learned that what I think is interesting might not resonate with others (or possibly anyone other than myself). A good way to get a pulse on how others feel would be to make a list of assumptions and test those with users before putting a lot of time into building a product/prototype.

Screen Layout Should Do More Than Look Good 

It seems that where something sits on a screen is proportional to how much it gets used. How often do you look at the second or third page in a Google search? If you are like me, it’s not very often. Many users noted that the budget overview screen is too long and that important functions were hard to find.

The screen above allows users to create ‘what if’ scenarios and save the new state as their budget if desired. However, most of the participants had trouble finding the button, as it was near the very bottom of the screen. Andrew told me,

“Looking at this, I wouldn’t even know that a scenario analysis is available. It’s way down here at the bottom.”

For such an important function, a lack of accessibility hurts the product’s credibility. In fact, multiple participants worried they would have to calculate a budget scenario in their head before finding the tile that would navigate to the tool.

The fix for this issue is seemingly simple: move the important functions/tools to the top of a screen to increase their visibility.

The main takeaway here is that critical elements should be ranked hierarchically and the screen should reflect that hierarchy starting at the top. Gauging what is important to a user, and why, could also be done with a round of testing on the front end of a project.

In summary, I learned:

  • too much text is a burden, and that some users don’t read text when it pops-up,
  • presenting information (text, numbers, etc…) in a way the user is most comfortable with is critical to the user’s experience, and
  • design decisions around layout can significantly affect a product’s credibility

I have a lot of work cut out for me after this round of user testing and I intend to apply the lessons learned to future iterations of this product.

I’d like to sign off by saying a huge THANK YOU to all the people that helped along the way: the think-aloud test participants, fellow AC4D students, and the teachers/mentors that generously give their time to help us all become better designers.