Over a 7-week period, I am designing the screens and architecture of a mobile banking application to help people confidently manage their finances. I am particularly inspired by designing for recent US immigrants and refugees, and I plan on designing an application to help connect these groups to financial resources, such as Mission Asset Fund and the International Rescue Committee’s loan program. Above this, I aim to design a simple and intuitive application that will help overcome language barriers. By designing with more challenging use cases in mind, my vision is to create an application that will be simple and delightful for a much larger subset of the population.
Last week, I focused on creating the initial touch-points for my application: the landing page and a guide to getting started. Then, I prioritized flows for check deposits and credit history building – two elements I found in my research to be particularly important for people who are new to the United States.
This Week’s Feature Focuses and Testing Approach
This week, I decided to take a step back and develop strong flows for functions that satisfy the primary user goals: logging in, checking your balance, depositing checks, and transferring money between accounts.
Rather than building out the complete toolkit before seeking user feedback, I focused my efforts on the check deposit function, and then I executed three think-out-loud user tests that took my testers through the login and deposit pages.
Think-aloud-testing involves giving the user specific tasks to complete with no additional guidance. Simply and continuously asking the tester to “please keep talking” prompts him or her to express their reactions as they first experience the elements of your design. The method provides unfiltered reactions and highlights disconnects between your intentions and how your design communicates to users.
Think-Out-Loud Testing Findings
My primary takeaways from these think-out-loud usability tests, outlined below, informed my design modifications in my next iteration.
Takeaway 1: Moving seamlessly from one step to another is of paramount importance.
The word choice and visual layout of my deposit screens made sense to my testers, but they weren’t able to get to the next input prompt how they thought they should. The navigation design held them back. This caused my testers to second-guess what the screen was asking of them, and it confused and noticeably frustrated two of them.
One of those testers, Kristen, experienced a significant, negative critical incident when trying to move from her account selection to the deposit amount. I designed the navigation so one would need to tap on the account tab to collapse it before moving on, but all three of my users wanted to be able to tap right into the amount box to move forward.
Not helping Kristen through this 40-second challenge was the most difficult moment of my first round of tests. She looked distressed and nervous that she was failing, and her frantic taps were not moving her anywhere. I reminded her that we were testing the application, not her, and a rush of relief flooded over her – visible in her tone and body language. Yet, it still took some time before she happened upon the solution to her problem. This incident dampened Kristen’s enthusiasm and confidence for the remainder of the usability test. After this, I couldn’t wait to go fix the navigation. This is a simple fix that, left unaddressed, could discourage users into not completing the task and achieving their goal.
Takeaway 2: Only set defaults when there is little-to-no deviation from that default.
Defaults work for prompts like “when do you want your money?” – Most people will want is as soon as possible. When there isn’t an obvious choice, however, the default may obscure the fact that there is a choice to make.
I initially designed the check deposit page to list “Checking” as the default account in which to deposit the check. I wanted to watch my testers explicitly make the “Savings” account selection, so I instructed them to do so with the prompt “ Deposit a $250 check into your savings account.” The account selection was then the third choice the user had to make in the flow, so I assumed it would still be top-of-mind. However, since “Checking” was pre-selected, all three of my testers immediately moved to the second input on the screen: Amount.
Selecting the account in which you would like your funds is a relevant decision for users, and therefore it should be an explicit choice, rather than something users are encouraged to gloss over. This is a straightforward, yet important lesson that I carried forward in my next designs.
Addressing Takeaway 1 and Takeaway 2 with Screen Revisions:
Takeaway 3: Don’t take the “simple” flows like the Login for granted.
All of my tests got off to a rocky start with the unclear login flow. There were a couple navigation steps that should have been more evident, but I failed to address these nuances in the last version, assuming that the flow was so familiar that they would be intuitive enough. This was a great lesson in diligently thinking through each tap someone makes on the screen.
Next Week’s Plan
For my next round of think-out-loud usability testing, I plan on putting together a more comprehensive prototype of the application’s menu items and key flows. This will help me observe how people work through the system and pinpoint pain points in my information architecture.
In our Rapid Ideation and Creative Problem Solving class we are focusing on redesigning a mobile banking application. My design focuses on the Randolph Brooks Federal Credit Union mobile banking app. In previous blog posts, I highlight making concept maps and wireframes in order to understand how the current app works and what areas need to be thought out or changed.
This weeks process focused around usability testing and iterations to our existing wireframes and concept maps.Some important guidelines of usability testing are: to perform each test with strangers, instruct each person to verbally say their thoughts as they go through the task(s) given, and to not give input in any way during the test. We would do this by not answering any question or concerns during the test other than simply saying, “Please keep talking.” The usability testing process has these guidelines in order to minimize any biases or outside factor that might factor the feedback given.
The feedback from these test was almost completely unanimous that once they were in the “Schedule Payment” feature the app was fairly intuitive. However each of them experienced confusion getting from the “Home” screen to the “Schedule Payment” screen. Two of the participants pressed either the “$ icon” or the “menu” button first to begin the task. The feedback was that it was a decision based on prior experience that they chose those first initially because that’s the way they usually start to do a task in an app.
Perception of Utility
Another issue was that, because of the complexity of the home page, many clicked on the checking and savings buttons before choosing the “Bill Pay” Function. When asked why they made those decisions a majority of people said it was because it afforded clicking to open up for that accounts options. Many people also said that was how they schedule payments in their app.
“Where Do I Go From Here?”
Once they were in the “Schedule Payments” feature most of the participants were able to flow through the task seamlessly, however the first screen did give some pause to certain people. In the ideal flow the user would then click the text box at the top of the screen and input the mobile number, first and last name, or account number of the person they wish to pay. Participants became confused at this point because there was no indication for why they were doing that or how that relates to scheduling the payment.
The revisions based on this feedback as well as overall impressions of how center aspects of the app work started by changing the informational architecture concept map for the redesigned app. The map details options on each screen for how to progress through tasks. Based on the impressions of the first round of usability testing I learned that people did enjoy the layout of the interface and, with that in mind, I highlighted the key pages in the app, “Home” and, “Menu.” From these two screens the user will have access to every page in the app. The feedback given on the function of these two screens were that the complexities gave misguided perceptions. There are icons and sections within the “Home” page, specifically, that afforded clicking to perform a task when that’s not what they are used for.
I need to do more testing into the overall navigation of the app. As I mentioned earlier, most of the users I tested with gave specific feedback on changes within the actual features and many responded positively to how the app functioned in those cases. I will continue creating my features with this in mind. The main problems lie in the navigations. In order to understand what exact changes I need to make I will continue my usability testing this coming week but I will frame the test to focus on using the navigations.
My user testing included 6 people, in age ranging from 13 to 48. I was lucky to get a teenager — who is a very confident user of a smartphone, but he has never deal with a bank application. It showed me how a person with no previous experience in the industry and with no expectations like “in my usual mobile bank application this function is here and acts that way” deals with the system.
Why 6 users? The research has shown that 5 to 10 users is enough to discover most usability problems; I’m going to be sticking to ~6-8 people at a time to apply the limited amount of time we have in our hands most efficiently, extracting the most value out of it.
As a result of User Testing, I’ve discovered three main problems:
When people were tasked to deposit a check into a CPC Checking Account, first thing they do is they try to tap on that Checking Account from the main screen of the application (which is the “Accounts” tab) – all 6 people did that. One other person has also tried to open Activities to do that.
“I think that normally I can go in there because that’s how… my Wells Fargo works.”
I felt like I was testing the tool and the approach and not necessarily the flow or the scenario of the app usage. People might have considered the task as a hint, and hearing the word “CPC Checking Account” and seeing it on the screen, they immediately tried to tap on it without looking much at anything, even though the task was in depositing a check, and the name of the checking account didn’t really matter.
Either way, I saw that it’s some valuable observation and I decided to have a way to “Move Money” through an Account page. The only difference going to be that the opened account is going to be pre-chosen in the proper fields (“From” for transfers, “To” for check deposit, etc).
It’s worth noting that people were learning really, really fast. On the second assignment, they all knew they needed to tap “Move Money” tab and go from there. For the next User Testing I’ll change the order of tasks and will add other options that are outside of the “Move Money” tab to see if the learning has lasting effect. While I plan on testing it on new users, it might be interesting to see if the same users have remembered what they’re supposed to do.
Many applications are non obvious these days. Snapchat is an extreme example. Applications like Instagram and Facebook has a bottom tab bar (similar to my application) that, from the first try, is not really obvious – you can’t tell what’s behind the options. However, first time you try it, it becomes obvious and not a problem for further use. I feel like it’s the same with the banking app that you use often. I try to stick to iOS conventions to make sure application looks familiar to iOS users, and if there’s something non-obvious, it should not be something that is non-obvious every time. Users should be able to learn it very, very easily.
Getting back to the problem, it can also be simply a visual design problem. The buttons on the bottom aren’t sticking out enough. They are of a regular size for iOS tab bar and are similarly used in hundreds of popular applications, however there can be a way to emphasize it with color and icons, maybe using Chase color styling. Regardless, as mentioned above, having access to “Move Money” from the Account page is still very useful because that’s also how many people think – instead of starting a thought process from the actions, they start thinking from the account they want to perform the action on.
After completing a task, users saw an overlay with “Your transaction is successfully complete” which was, in my prototype, an “exit” back to the homepage (Accounts page). However, it was not obvious for users that they need to tap it. They tried to tap outside of the overlay in free space or on one of the tabs at the bottom or on the “Transfer Money” button again, but not on the overlay as I planned.
“I don’t understand how to get off of this screen… I know I need to go there but how? Yeah, see, that’s obviously… these buttons should always work basically, you should always be able to get through”
Even though some people mentioned that they very like big blue overlay telling them that transaction is successfully complete and found it’s easy to read this overlay as “exit” sign, for most of my participants it wasn’t so obvious. In this iteration I’ll tried to make it is more clear by having a button that simply says “OK”.
On the Calendar screen where you are supposed to click on a date, today’s date is highlighted with blue (and is chosen by default), people still click on it (sometimes multiple times) even though there is no action to be taken and you can just move forward.
“I would expect something like “Today” button here or something like that.”
“That is another thing. I hate when it’s always this “Done” option. Once you clicked a date or clicked under it should just go.”
I realized that “TODAY” is actually such a popular “Date” for any kind of transaction you want to do that it makes sense to just have it default on the transaction information screen, so that people don’t even have to click on it to get to the Calendar screen in the first place. And if they do want to change it then (want to set another date), clicking on dates outside of Today is what they will do and it will be actionable.
Regarding the note that you have to click Done after choosing a date, I think it is still important to have it the way it is, because users may want to “tap around” on the page and having it jump back to the Transfer info page with every tap would be very annoying. I will keep an eye on it in next user testings.
Even though I said there are 3 problems, there are a couple of problems with the testing tool and approach that I used, and not with the application design itself:
When users were going through depositing a check, they did not know what to do. In the prototype, they just needed to click on the Image area that it would just automatically get filled out without really taking a picture (Invision prototyping does not allow taking pictures anyway). But users were wondering: “I don’t have a check, what should I take a picture of?”.
“We just don’t have a physical check that’s why I’m not doing it.”
This seemed like a testing approach problem and an immersion problem. Next user testing, I’ll make sure to have a check prepared with me so that users feel confident they can go through the flow.
I only prototyped the “perfect plan” screen flow. But all screens should ideally be accessible so that users can surf around, get lost, try everything they want to try.
“I know where I need to go I just can’t get there.”
With all preparation and technical issues for all 3 tasks the testing were lasting from 3:04 to 7:29 with an average time of 4:55.
The System Usability Scale (SUS) score has calculated to the following numbers:
One user was exceptionally unhappy with the fact that you couldn’t just surf around like in the real application and the prototype was restricted to the “perfect plan” (and that overall it was a prototype, and not a real functioning application) – my guess is that it was the user who gave an overall very low score, which lowered the Average score significantly. I will work on finding ways to communicate what you can and cannot do with the Invision prototype so that there are no wrong expectations.
Next time I will try include people older than 65 into the user testing to find out how easy the application is for people who aren’t afraid of banking in general, but might not be comfortable specifically with technologies and smartphones.
Lastly, below is the updated concept map that reflects the current application structure, and also includes further expansion and features that are not fully designed yet.
Click to enlarge. Save the photo on your computer to see in full detail.
The third week of Rapid Ideation and Creative Problem-Solving course (see last week’s post about the initial wireframes) included user testing, information architecture concept map iteration, and revised wireframes.
I used the Think Aloud Protocol for the usability tests. The method evaluates the usability of an application by encouraging a person to think aloud as they use the product. By verbalizing their thought as they use the product, I was able to understand what they are thinking as they go about a task. As a person completes a function during the test, I provided one instruction: please keep talking.
The usability tests identified several incidents and areas for improvement. In several instances, the low-fidelity of the application seemed to hinder usability testing. Which was quite telling and instructive for me.
The three most critical incidents identified were: viewing and downloading a check; paying an existing bill, and sending a friend money. I determined these as significant since they are primary functions of a banking application. By addressing these areas, it will also improve the fidelity of other wireframes.
Findings: Please Keep Talking
Information Architecture Concept Map
Due to the low-fidelity of the wireframes, I did not make significant changes to the information architecture concept map this week. The most notable difference I’ve proposed, placement of deposit a check within a new area called Move $, did not cause problems during the usability test.
After further usability tests this week, I will revisit the information architecture concept map.
The most significant design decision I made this week were:
Navigation bar. I added two icons: home, and more (formerly called help).
Tab bar. I added five icons: Accounts, Move $, Bill Pay, Service, and Products.
Home page. The homepage is meant to allow a person to quickly go to their most visited areas of the application. While still under development, I redesigned the table and included preliminary icons for each section. I also designed a prompt for a person to customize the dashboard.
Usability test findings. Revisions were made to pay an existing bill, view and download a check, and send money to a friend.
My next steps in the project are to continue usability testing, to develop additional screens, and to revise the screens and flow based on critique and testing. My hope is that with the changes made this week, I’ll have a higher fidelity wireframes that are better suited for usability testing. Stay tuned!
As mentioned in my recent banking application redesign blog post, we are developing a mobile banking app in our Rapid Ideation and Prototyping class. We just finished our first round of redesigning the system, and we’ll be completing four more redesigns before the end of the term. Each one-week redesign entails a full sweep of revising and expanding on the application system.
The redesign process:
Information Architecture Redesign
In this week’s blog post regarding the banking application, I will review how I used these methods to evaluate and improve my own Wells Fargo banking app redesign.
After last week’s critique, we went straight into usability testing to begin the redesign process.
What is “usability”?
Usability is the quality that describes the ease with which a user can complete a task utilizing a designed system. A system is regarded as usable if the user is able to complete a given task, makes few errors in completing a given task, and does not take more time to complete the task than the designers intended.
Usability is expected in today’s world of software applications given everyday consumers are used to experiencing high quality usability in web, mobile, and desktop applications.
Designers should do methodical testing to determine how to improve a software application’s usability. The method of usability testing we employed is called think aloud testing.
Think Aloud Testing
The goal of think aloud testing is to learn about test participants’ thought process regarding the completion of tasks. This is done in order to identify critical breakdowns in the participant’s solutioning process. This process will inform re-designing the parts of the designed system that contributed to those breakdowns in usability. In order to understand participants’ thought process, they are instructed to describe what they are doing as they are manipulating the system in their attempt to complete the task.
One may wonder if talking about what one is doing actually changes the outcome of the solutioning process. This question is exactly what Herbert Simon and Allen Newell asked when they went about studying artificial intelligence back in 1972.
The conclusion of their cognitive psychology experiments was that verbalization does not affect the outcome of participants’ problem solving after all. This is great news for understanding how people think while problem-solving, but it does come with a caveat – the outcomes are affected if participants introspect during the process. To deter participants from introspection, they are encouraged to continue talking about what they are doing throughout the experiment.
I used paper prototypes for my user testing and tested five individuals in five separate test sessions. Though one may think that five participants in a study is too small a sample size, studies in usability testing show that the rate of finding additional usability errors drops off precipitously after completing testing with five to ten users. For the purpose of this one-week redesign, we determined that five users was sufficient.
I found those individuals at a local coffee shop and each of them agreed to test all six of the tasks I had created.
System tasks assigned to the user:
Send $48 to your friend, Alicia
Transfer $4,000 from your Savings account to your Charles Schwab account
Set a balance alert to send you an email when your debit account goes below $300
Use mobile-deposit to deposit a check for $25
Set-up a recurring monthly bill payment to Dr. Chalmers for $40
Check the balance of your debit account.
As users reviewed the screens and “clicked” on different parts, I stood by to hand them a new screen that would result from the buttons or areas that they clicked. They verbalized their thought process, and in all it took approximately fifteen minutes for each user to complete all six tasks.
The last part of the test was to review my notes and recorded transcripts in order to identify the most pressing problems I found in the tests. I identified three main problems and, for each problem, I describe below the problem and my recommendation for fixing it. I included a quotation from a user for each scenario as well.
Redesigning the System
With the usability results, critique feedback, and a set of my own notes on system improvement in hand, I set out to redesign the system.
Information Architecture Concept Map Redesign
Revising the information architecture (IA) concept map was the first step. Below you can see the initial IA map and the the new IA map side by side.
I made a number of changes as can be seen when comparing the maps.
Move functions from Account Services to Customer Services
As identified in usability testing, the term Account services is very broad and led users to look there for functions like transfers and check deposits. Rather than just change the name, I believe that the enclosed functions were better relocated to other containers like Customer Support and Manage Funds. I moved these functions to other containers, removed the Account Services container, and renamed Customer Support to Customer Services to imply that many services could be found in this new container.
Move Card-free ATM to Manage Funds
The Card-Free ATM feature is one of the features I moved from Account Services. Since this feature is about accessing funds, I moved it to Manage Funds.
Modify Manage Alerts Information Architecture
Individuals from my cohort said that the “More Alerts” sub-container was confusing, and I agreed. I moved the two alerts that was in “More Alerts” to the “Account Alerts” and I believe this will work well by centralizing the alerts.
I made modifications to the usability challenges regarding alerts in the wireframes as this IA map does not deal with those challenging elements.
Reorganize hierarchy on menu
I also reorganized the hierarchy in the menu so things like Set-up, which are usually one-time changes, are lower in the list than Financial Planning, which is a more often used feature given its access to Spending Reports and FICO Score updates.
Link Star to Starred tools
I included a link from the star in the Starred Tools area of the accounts overview page to the Starred Tool set-up sub-container. This will make accessing and modifying those tools easier. This change was inspired by a usability test participant who clicked on the star to see what it would do.
Link Account Details to Manage Fund functions
One challenge brought up in the usability test was the need to link the Account Details to Manage Fund functions like transferring money, sending money to a friend, or depositing a check. I created these linkages in response to fix this problem.
Add replace card and turn card on/off to Security
There was no “Replace Card” or “Turn Card On/Off” feature in the Security area, but I believe this would be one of the first places people look when they lose a card. In response to this observation, I added links to those features in the Security sub-container.
Once the information architecture map was complete, it made modifying wireframes easier by providing a roadmap for many of the changes I needed to make. As can be seen in the images below, I modified the containers and lists to reflect the information architecture map, and I also made additional changes to the visual design of the screens.
Below are images of the multiple task screen flows I created and updated this week.
One major change to the information architecture was the container hierarchy and list. As can be seen in the image below, I reflected this change in the menu as well as the naming of items like Customer Services. Account Services no longer exists.
Darken the text of the starred tools
By darkening the starred tool text, it will save users time by helping them see those tools before they go look elsewhere to access them.
Add a screen for links to manage funds functions from within the accounts details view
In response to users going to the Account Details area for functions like transfer, check deposit, and sending money, I created a new screen that allows users to access those functions from the Account Details.
Changed the process for Managing Alerts
The last major change made to the wireframes was to simplify the Manage Alerts process.
I modeled the indicators on the last version of the main alerts screen on the original Wells Fargo app. They were confusing to my cohort during the critique, and I removed these indicators so there is only an indicator light. Users don’t need to see if there is an alert for phone, push, or text from this screen. They can go into the alert to see which alert methods are used.
Remove Update function
The biggest challenge identified in the critique and during the usability test was the user’s confusion and errors in updating the alert settings. The Wells Fargo app requires users to click “Update” and save alert settings when changes are made. Rather than move this button around as I did in the first design, I changed the Manage Alerts function in this design by removing the Update button entirely. There is no need to manually save settings when modifying them in an app. I propose that these settings save automatically now whenever changes are made.
In order to make a change, a user will modify the settings. Since the message settings did not automatically update after changes before, I changed the interface so they would automatically update. For instance, when a user updates the balance alert as seen in the above Balance Alert Task screen flow, the email message setting automatically turns on. As can be seen when the user opens the drop-down box, the default primary email address is selected when this occurs. This automatic mechanism ensures that messages will be sent when a user modifies a new alert, even if they do not know or forget to modify the message settings. If they would like the message to go to additional or other places than the default, they can change it in the alert’s message settings.
This week we had a critique, did usability testing, redesigned the information architecture, and then redesigned our wireframes. This afternoon, we’ll start that process over with another critique. The process has revealed things I never would have identified on my own, and it reaffirms the lesson I’m learning here – show your work to others as often as possible. It’s the surest way to correct for blindspots, and it’s the only way to understand what users really think when they use the app – because, as it says up on the wall in the studio – “You are not the User”.
This week was all about usability testing and getting honest feedback from real users using the Think Aloud Protocol technique.
From my former set of wireframes, I integrated both the feedback that I gathered from my class peers and the one that I gathered from four different user testers.
The top three problems I found after this first round of testing were:
The main menu was not easily perceivable
There was confusion differentiating between Transfer, Send & Pay a friend
Check balance menu should be easier to read and provide the necessary affordances to make it more actionable.
With the wireframes we created last week, we came up with different tasks and asked our participants to complete them. If they felt really frustrated, they were allowed to quit – they are not the ones being tested.
The tasks provided were as follow:
Task #1: What is the next payment due for your credit account? Task #2:Pay your friend Ethan Baldwin $100.00 by Nov 15th for Basket Ball tickets. Task #3: Deposit a $300.00 check to your debit account.
Problem Area 1: Check Balance
“I just don’t see how “transactions” is going to take me where I want to go. I would like to go to details, but it’s not taking me anywhere. Yeah, I don’t know…” – User Tester #1
Problem Area 2: Main Menu
I built my mobile UI prototype with the iPhone components found on Sketch. This inspired me to add a redesigned bottom navigation bar with these same components. From my point of view, the bottom navigation bar is useful due to the proximity the user’s thumb would have to the main menu – also called “the friendly thumb area”.
But I soon realized that this feature presented a lot of problems:
“”Move Money” seems strange to me, what does that mean?” – User Tester #2
I tested the mobile app with two baby boomers and they both really struggled at comprehending that the bottom navigation bar was a menu, and what each of the options where – both also hesitated from randomly taping to look for more options.
From these group of users, User Tester #4 was not able to go past the list of accounts because he did not think the bottom menu was actionable. After the session (which he was not able to complete) he mentioned:
“I would like to see a first step that asks you what is the main action that you would like to take, and go from there. Kind of like a tutorial” – User tester #4
For those users that were able to find the bottom navigation bar, the menu options represented another concern. First, “Move Money” did not mean anything to User Tester #2, and as she struggled to accomplish Task# 3, I was able to observe that the reason why she was struggling so much was also because the option she was looking for actually fit to “Send / Request Money”. She did not take the time to go through the rest of the options where she could have found “Pay a Friend” – these options didn’t adequately map to the options she normally uses, and were misleading due to the word choice.
“I think I’m struggling with this system because I’m not used to it yet, but I know that a couple of days from now I will probably know my way around it pretty well. I don’t mind exploring and tapping” – User Tester #2.
Problem Area 3: Deposit Check
“I would like to see a series of steps instead of everything on the same screen. Having all of this is overwhelming to me.” – User Tester #3
After this first round of usability testing, I synthesized the findings and attempted to implement the changes to the application, but first, I started by modifying my initial concept map.
With all of the feedback I received, I worked on a few suggestions to improve my current wireframes and added a couple of different ideas to the existing flow.
An example of this part of the iteration were the two following screens. One of them being the bottom menu where I opted to replace the icons with actual words.
Unfortunately, there were several tasks that not most users were not able to complete due to the menu being such an issue. For this next round of usability testing, I will focus on figuring out how users react to the new menu concept. I will also be testing screens for Setting Recurring Bill Payments and Setting Alerts.
After presenting my wireframes for the Wells Fargo banking app last week, I immediately realized how stunted my thinking was in redesigning the system. You can tell by a quick comparison of the Existing Info Architecture Map with the one I redesigned that, embarrassingly, not a lot had changed.
The second version of the information architecture map came from some of the feedback my classmates offered, along with what I noticed while conducting user-testing.
The main pain points I focused on were navigation. My classmates pointed out that it was confusing, and there was too much going on. The menu housed far too much information and the tab bar at the bottom needlessly repeated the menu. However, one of the big takeaways from user-testing led me to believe that the menu drop-down panel is a valuable tool for users to help orient themselves when they want to jump between sections. Given these two pieces of feedback, I decided to keep the menu, but pair it down to only the separate “sections” of the app a user would want to visit.
The core functionality of transferring money and paying bills, is now found on a tab bar on the “home” page. The Account Summary functions as the home page, and all the users I tested with appreciated the ease of seeing their account balance right away upon login.
I decided to keep the swipe option with each type of account since it allows a user to quickly perform functions directly related to that account. You’ll notice the tab bar also offers functions related directly to a users accounts, but these buttons will bring the user to a section with all the related functions.
At the bottom of each subsequent page under the “Transfer and Pay” section, the user can jump back to the transfer and pay “home” section.
If a user were to navigate to a section user the drop down menu, they might choose to go to “security”, and it would have a very similar structure.
All the menu item sections are set up in this way. The “customer support” section is nice in that some of the parts link to and support each other. Like how “locations” and “make an appointment” are linked as illustrated below.
The “contact” section under customer support allows the user to either call or chat with Wells Fargo. The “chat” portion could use some help with styling and I’ll be seeking some feedback on this part, but I wanted it to feel easy and personal, just like texting.
Lastly, in regard to solving my navigation problem, I added an icon that looks like a little house at the top of the header bar. This is a feature I plan to test out with my next round of users. There needs to be a quick and easy way to navigate back to the Account Summary page, but not everyone seems to view the “Wells Fargo” heading as a clickable navigation option. If the new icon doesn’t translate this, perhaps we can build it back into the menu.
The next iteration will be driven heavily by the second round of user testing I’ll conduct this week. The plan is to have the users execute tasks within a section and between sections so that I can understand their thinking in regard to the flow of the navigation.
In this week’s blogpost, I am going to describe my process for iterating on my Navigation and Information Architecture Map and the wireframes for the TD Mobile Banking App. This builds on two previous blog posts; the first was on my process for creating the original concept map and the second was for my process on developing the wireframes.
In this post, I am going to discuss and present:
Revising the Navigation and Information Architecture Map
Last week, I developed my wireframes using a process that hinged on imagining a flow through the application that would help well-defined characters achieve a goal. This week, I set out to see if real people could achieve those goals. To do this, I first created a digital prototype using Sketch and a plugin called Craft that links my wireframes to Envision. Then, I went out into the field to find at least five willing participants, primarily in local cafes. Last, I looked back at the data I had accumulated and found the top three design issues that I wanted to revise.
I knew that in order to get feedback on the usability of my application, I would need to present participants with a low fidelity prototype. One recommendation I received was to use a paper prototype. However, I decided to try and learn how to create a digital prototype since I know that people in industry do this. The process was arduous. It made me think more about each step of a user’s flow. Questions like, “What will happen if a user does not fill in a field properly?” or “What sequence of screen would a user most naturally flow?” came up. I also had to learn the idiosyncrasies and limitations of Craft and Envision. I thought that the time spent on this part of the prototype development was worthwhile because I thought that organizing a paper prototype would be overly onerous, especially when working with participants in real time.
Once the digital prototype was developed, I set out into the field to find willing participants. I had six predetermined tasks: checking a balance, transferring funds to an external account, paying a friend, setting up a new alert, paying a bill, and depositing a check. I wrote each of these tasks down on a separate sheet of paper so I could hand them off during the testing session.
I also prepared myself to follow the Think Aloud Protocol. The steps in the protocol involve first, telling the participant what they are about to do and that once testing begins, all I can say is, “Please keep talking.” I tell the participants that I want to hear what they are thinking as they attempt the tasks written on the sheet of paper. The Think Aloud Protocol is based on a theory that people can explain how they solve problems and that though it will slow down task completion, won’t have an impact on potential task completion. As participants will work through the task, I will take notes and record what they say so I have a reference for later synthesis. I also had my participants fill out a SUS score which is their rating of the application flows. My hope is that as I iterate on the wireframes, the score will go up.
A key takeaway from usability testing with a digital product was that a lot of the feedback I got was actually about the limitations of Envision. People got stuck on different screens because Envision is limited in how systematically accurate a user can interact with the product. I also found greater success when users could test the product in its appropriate environment, a mobile phone, and not a desktop computer. I also found that digital prototypes are limiting because they constrain how a user can walk through the application since the sequence is pre-determined. When doing this again, I could of course make a screen and flow for every single way a user can walk through the application, but I think that user a paper prototype may allow for more user control and thus, I can get even better data.
Some key takeaways from my first round of usability testing using the Think Aloud Protocol was that when I write the tasks, I should give users more information about what they may need to enter into each field. I also found that having a setting where I could clearly hear the participant is super important. I sometimes struggled to write good notes because of this. It was also challenging not to step in and help sometimes because Envision made it hard to tap on a field and move to the next screen. I would sometimes end up helping a user because it was just too frustrating for something that didn’t help me get any useful information. Also, after getting feedback from 5 people, I had confirmation that getting many more participants to try the application would not add to the accuracy of what I would learn. I saw patterns emerge already and can imagine that anymore than 10, I would not learn much more.
Of course, I was also able to garner some key issues that I would want to fix in my prototype. They are documented below.
Revised “Navigation and Information Architecture” Concept Map
There were two key revisions I made to my concept map. First, I wanted the concept map to reflect the complexity of the application system. My first map was too simple. A future software engineer would have a lot of potential to make up user flows because so many details were missing. So, this necessitated a complete overhaul of my concept map. Second, the concept map would have to reflect the revisions I made to my wireframes.
In order to do a complete overhaul of the map, I started fresh. I went through three paper sketches, getting feedback from classmates on clarity and hierarchy. I made sure that I had different shapes to reflect different kinds of screens and operations. Squares represent places a user goes to. Ovals represent the functions you find in each of the “places”. Circles represent the flows a user takes to accomplish the function. Working through this process made me have a much clearer idea of all of the screens I currently have as well as the screens I still need to develop for a complete application. The feedback I got from my classmates helped me to make a better visual hierarchy. At first I made the ovals a much thicker line weight but this confused my classmates because it made them more important than they should be.
In order to reflect revisions that I made to my screens, my concept map includes a shortcut to get to the main functions a user may want to apply to an account. Also, redoing the concept map made me realize that my I never included a way to logout of the application in the original wireframe set. It also helped me to see what screens I would add a home link to for a user to get to restart faster.
Below are the revised wireframes. First, I highlight the key screens that I revised based on the top 3 problems I chose to revise. Second, I present all of the screens. In addition to the revisions I listed above, I also revised a several other elements. I did these revisions based on what I learned from the critique session in class.
The other revisions were:
Graying out a button if it should not afford clicking if all required fields are incomplete
Changing the titles of buttons to more accurately reflect what they do (ie changing “Deposit” to “Another Deposit” on the success screen for deposits) or to be more natural (ie changing “Return Home” to “Home”).
Adding a logout option on the main menu
Next week, I plan to build out my application according to the concept map. I will also do usability testing. But this time, I want to focus on particular flows and to get feedback on buttons and font.
This week, I conducted put the first iterations of my VCU flows in front of three Bennu coffee patrons in order to test their usability. The method I used was think aloud testing, which basically involved asking my participants to say everything they were thinking as they tried to accomplish tasks using the VCU app. Every time they paused, I said a gentle “please keep talking” to get them started again. I had originally planned to test with more people, but these first tests turned up so many problems that I concluded I didn’t need to do any more testing.
Main Problem #1
The first big problem people encountered (quite literally) was that there were no signifiers on the login page to let users know what they should put in the input boxes.
One user said, “I’m clicking on the top one because it’s probably the username.”
The fix for this problem was relatively easy. I just added labels inside the input boxes.
Main Problem #2
The second big problem my participants encountered was that the main menu options were not clear.
Here are some quotes from my participants:
“I don’t see any that would suit depositing a check.”
“The names of the menu options were confusing. ‘Funds Transfer’ and ‘Bill Pay’ were really similar in my head.”
There were a few factors contributing to their confusion. “Bill Pay” and “Funds Transfer” sound like they perform similar functions. The word “mobile” does not add clarity to the check deposit feature.
To fix these problems, I did the following:
Changed “Mobile Check Deposit” to “Deposit a Check”
Changed “Transfer Funds” into two separate main menu options: “Transfer” and “Pay/Request from a Friend”
Subsumed “Credit Card” options within “Services” (in order to keep the full menu viewable without scrolling.
Here’s how it turned out:
Main Problem #3
The third big problem people encountered using the app occurred in the Deposit a Check flow. My participants had a hard time figuring out that the camera icon was a button that they needed to push in order to take a picture of their checks.
One user said, “I’m confused as to what this camera icon is for. I don’t really know what to do now.”
I concluded that the button was too small and subtle over there in the corner, and I had originally planned to enlarge it. But then I thought, why not just have the app take the photo as soon as the check is aligned with the viewfinder.
I also edited my flows based on the feedback my classmates gave me, and then I added a few new flows. Take a gander:
To wrap Austin Design Week, AIGA Austin hosted a panel discussion featuring local designers about how to make design for good part of your career. This latest installment in AIGA’s Changemaker series brought together designers from all career stages who have committed to make giving back part of their everyday lives.
The event was overflowing, attracting both existing designers and educators involved with social good and citizens simply interested in how to give back to their communities.
Understanding Design for Good Despite different backgrounds and clients, all designers agreed that intention is key when solving social problems.
“Design for good, for me, is considering the potential implications of my involvement and what the outcomes might be of my work– hoping it’s net positive and deciding when not to involve myself if that’s not likely,” said Serota.
Working as a Principal Designer for the City of Austin, Alan Holt is not only concerned with how to make great public spaces that are beautiful, but how do we create public spaces that are sustainable and connect us together?
O’Dell has already discovered to only commit herself to projects that she truly believes in and that will positively impact her community. “Design for good for is the integration and elevation of ideas that will help everyone,” said O’Dell.
Serving Your Community People and communities are at the core of designing for social good. Prior to becoming a designer for cities, Alan Holt started at a boutique architecture firm designing for elite New Yorkers. Once moving into the public sector, he realized he could help give a voice to the people he serves.
“On a day-to-day basis, I’m working in a world of politics where some people can say yes, and some people can say no,” said Holt. “Who I really feel I need to serve are the people who are oftentimes most powerless in that conversation. As designers I believe we can bring something unique to that conversation just because design is a radical act.”
Designing for your community can be as big Austin’s South Central Waterfront Initiative, a $1.2 billion dollar project Holt is spearheading in Austin, to starting a simple campaign to encourage community through waving. In 2013, Butler noticed hostility between cyclists and drivers in Austin — so he fought back through a simple act: waving. His agency developed a local campaign, which was later integrated into efforts in Austin and ultimately picked up as a statewide campaign in Rhode Island.
Designers not only have the power to create products and processes, they can also help spark conversations in communities. Serota views this as the biggest challenge and opportunity for success in her work. She advises that allowing your idea to expand, evolve and live in the world independent of you is what makes it more powerful.
“It’s probably 90% of my time now — to produce an environment that is conducive to inspiration coming forward and everyone feeling ownership around it,” said Serota.
Ultimately, community and intention are at the core of designing for good. Even though O’Dell is new to her career, she has already discovered that “to make anything good happen, you need to talk to people.”
CHANGEMAKER is an AIGA Austin initiative that unites teams of creative professionals with nonprofits and social change organizations to use design thinking, sustainable frameworks and creative tools to help advance their mission. Inspired? Sign up here to learn how you can help build a movement for change.