Rapid Prototyping: A One Week Redesign
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:
- Usability Testing
- Information Architecture Redesign
- Wireframes Redesign
- In-class Critique
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”.