Redesigning for a Product Acquisition
Congratulations! Your banking company just acquired a financial modeling company, and now it’s necessary to integrate their products’ capabilities into your banking company’s mobile app!
This is the message our instructor, Jon Kolko, presented to us last week. It was a surprise feature change, and it’s not uncommon in industry to hear such news. With that in mind, we changed course and started immediately on developing new features and building out those screens instead of iterating and polishing even more on the existing screens and features. See this past post to learn more about previous feature build-out for our hypothetical banking application.
The criteria for the feature build-out included the following:
- Provide a snapshot of finances and their trends
- Analyze transactions to see if they are historically anomalous in the context of user’s spending
- Provide a drop-dead simple “what if” modeling system based on “playing with” recurring payment amounts to see how changes in monthly spending impact the user’s account.
- Help figure out what amount of money is safe for a user to spend at any given time.
Designing the Features
To get started with this process, I started by brainstorming, reading about, and diagramming all the concepts, details, relationships, and scenarios I could think of related to these features.
What kinds of recurring payments might people have? What types of finances might people want to review in a snapshot? When would they review them? Will people analyze transactions to see if they’re historically anomalous? Probably not. So perhaps the system will analyze transactions and alert users about them. What types of patterns would be useful?
After mapping out many of the concepts and sketches of scenarios, I developed a more rich picture of the user and feature use using scenario writing. I created a character named Eric who used his app to derive value using these different features. Once the scenarios were complete, I mapped ideas for different screens to the various parts of the scenario when he might encounter them.
Information Architecture & User Interface Sketching
Next, I started sketching the information architecture map and also started sketching screens. Though some people may think this process should be strictly linear, doing one before the other, I find it rigid and creatively dampening to try to go in such a linear order. While creating the information architecture map, there are details I’ll miss that will come out while sketching screens, and visa versa.
I then updated the digital version of the information architecture map.
I’ve received feedback in the past that I need to improve how much the app looks and feels like an iOS app. With this in mind, I looked at iOS apps like the calendar, clock, settings screens in order to better emulate the iOS interaction paradigms. I also reviewed and took notes on Luke Wroblewski’s book, Web Form Design, to improve the layout of my screens. I integrated various tips on alignment of fields, padding, visual layout, and language in this set of screens.
Finally, I did usability testing using the think-aloud protocol. The think-aloud protocol is a useful method for detecting usability errors, and I describe the process in detail in this post.
The following are descriptions of how I integrated the features into the Wells Fargo app; what errors I uncovered in usability testing; and how I corrected some of them and plan to correct others in future iterations.
General Product Integration
Overall, though some of my peers used the financial modeling and analysis features to create suggestions for users to save more, I chose to leverage the financial modeling features to simply support users’ financial awareness and decision-making. I believe that users will more likely change their behavior if they are aware of their financial positions and behaviors more so than if an app suggests they change those behaviors in particular ways.
Also, some of my peers created new paradigms for thinking about finances or leveraged emerging trends in financial apps such as “Safe to Spend”, a feature built into the Simple app. I found these concepts confusing and believe that users are most likely to value and benefit from features if they are integrated into existing paradigms such as using budgets, cost scenarios, and alerts.
Snapshot of finances
To integrate a snapshot of finances, I created a simple graphical layout of common financial information. The interface makes it easy to switch between accounts for analysis by swiping the account cards above, and the months can also be compared through a bar chart. Though the greyscale makes it challenging to read the colors, the circle chart will use color to clearly indicate spending area proportionality. These colors map clearly to a scrollable list of budget categories on the right. For more information, the user can go into any budget category by clicking through.
During testing, I found that users were confused about the scrollability of the budgets, and I will put shadow on the bottom and top of the scroll bar to make it more resemble a picker wheel that one can spin.
Historically anomalous analysis
Instead of relying on users to go into transactions to analyze them, which I find unlikely to happen, I developed the system to analyze transactions and send push alerts to the user as they were helpful. In this case, the user has signed up for “Savings Alerts” and sees an alert on the lock-screen. He then opens the screen to find the Savings Alert notifying him about grocery spending. It does not suggest he change his behavior as much as make him aware of the ramifications of the behavior over time. I think this will better improve user behavior than suggestions.
During testing, I heard users say things like “What do I do this now?” In the future, I will build-in opportunities to provide the system with feedback, allowing the user to respond to the notification and therefore “do” something with the information. Telling the system, for example, that the information was useful or not is one example. Another example is telling the system to remind them next time there’s a similar anomaly, or to dismiss this type of anomaly and stop hearing alerts about similar anomalies.
“What if” modeling system
For the “What If” modeling system, I decided to make it into a cost scenario builder. The user accesses this system from the budgets and goals area, an area that is similar in use to scenario building because it is about future planning regarding expenses. From here, the user can test out what new recurring costs would do to monthly costs, or she can modify existing recurring costs that the system has identified and see how modifying those costs would affect monthly costs overall.
In my wireframe flow, the scenario depicts a user testing out how she can afford a massage. She creates a new scenario, adds a massage cost that will be monthly, and then tests out downgrading her cable and eliminating a monthly water-cooler service. In summary, she finds she only has an increased cost of a bit over a dollar if she were to take this strategy in adjusting her monthly costs and services.
She then saves the scenario. This feature allows her to test and compare scenarios or to share them with someone like a roommate, partner, or business associate, based on how they manage finances and who else may need to know about these changes before making a decision.
The biggest challenge I heard from users regarding this scenario is the complication of going into each cost, modifying them, and then returning to the scenario builder screen. In the future, I will try out different interfaces that put all the controls and feedback elements on the same screen. Sliders, pickers, and graphical feedback elements may help centralize the interactions on one screen.
Safe to spend
Regarding safe to spend, I find the best way to help people quickly understand how much they have to spend is by visualizing budgets effortlessly and quickly. I find the “Safe to spend” paradigm in apps like Simple too cumbersome, confusing, and requiring too much training and user input to be useful. There are also too many opportunities for assumptions about transactions to rely on the banking app to decide what is safe to spend or not. I created a quick way to view account balances and budgets in particular to alert the user what money they should consider available at any point in time. This ease of access and visibility is the most important part of helping users understand their finances, as many banking apps do not make this information easy enough to access or read.
Overall, these past eight weeks have been eye-openers. The most important lesson I learned was the following
Start with Low-Fidelity
In making the first set of screens, I started by modeling my work on the Wells Fargo app and brought it to too high a level of fidelity. This made it more difficult to go back and make changes to the app as needed. As I developed these new features over the past week, I made sure to start and stay low-fidelity much longer. In the future, I now know to go slowly in building up fidelity, and I plan to do as much by hand as possible before committing to digital mock-ups.
Interaction design is a challenging field, but the last lesson I learned is that through rapid iteration and usability tests, we can learn much more than through endless planning and design in a silo. I look forward to next quarter when we will apply these techniques to designing and developing our own apps. For now, it’s time for December break. Happy Holidays!