Banking with Financial Modeling: A Student Redesign Project

Over the past two weeks, my classmates and I had set out to take feedback from users who played with our first rendition of a mobile bank app that we each design, imagined ourselves as working for a bank that was acquired was tasked to add financial modeling elements functionalities to our bank app. Mint one example of financial modeling. I’d like to share with you the journey I took to develop the idea and design, what I set out to learned and the things I discovered along the way.

The Process

Redesign Guidelines.

Just before this project, I had conducted user testing on the last iteration of my design. From that research I took my learnings about user motivation, habits and made a guideline of what to include in my next revision. Those guidelines were as follows.

  • Regarding UI and Copy
    • Use less icons, this was more distracting and created a busy feeling rather than informative
    • “forwards/backward” should be indicated with a specific call-to-action language, avoid image and generic language (i.e. review, back)
    • move navigation items in the same hierarchy. user’s prior experience demonstrated that this is best at the top left of the screen
    • Physically separate navigation links and buttons from confirmation targets.
    • a bank app should be visually clean, simple and information dense but still concise to only the most pertinent and supportive of what the user is trying to do.
  • Regarding User Experience
    • Users want to have control and flexibility over security
    • Users want the experience to be immediate and reassurance that what they are looking at is up to date and accurate
    • Be attentive to the detail of flow, messaging and accuracy of what is being displayed, the slightest confusion will immediately lead to distrust because this is a banking app.

Learning User Expectations of Financial Modeling  + More Guidelines

Financial modeling is not something that I am too familiar enough. To gauge what the what user’s the prior experience of a financial modeling app looks like I set out to analyze an existing app,  Mint,  and created a concept map of its functionalities. I then reviewed the concept map and isolated the core functionalities based on the following elements I was trying to integrate.

  • provide a snapshot of your finances and their trends
  • allow the user to analyze any specific transaction in any account to see if it is historically anomalous in
    the context of all of your spending
  • provide a simple “what if” modeling system based on “playing with” your recurring
    payment amounts, so users can see how changes in monthly spending impact your account
  • help the user figure out what amount of money is “safe to spend” at any given time.
  • Include the original banking functionalities that I had designed for originally
    • the ability to make a deposit
    • the ability to check one’s account balance and see the transaction details

The Re-Design + Build Out

The Fuzzy Front End & Creating a Process Flow Diagram for Clarity 

This is the fuzzy front end. It was a struggle to just ‘know’ what to put together and how. The earlier guidelines help me with what features should be included and how should the details be but I was still missing something to move this forward. In developing the process diagram I quickly learned the missing piece was a ‘why’. It was not until I was randomly piecing feature and elements together that I was able to start speaking to why they feature or elements should exist together.

A few squared and diamonds into it, I decide that my overarching goal of the app should be to test and see if an app when well designed, can provoke people to consider more frequently and in depth about their long and short term financial wellness. If the app can do this and also provide a simple to use tools to take steps to improve or maintain financial wellness.

Sketch for Direction & Digitized Mock-Ups

As I was mapping the process flow, I would make rough sketches of what the screen could look like and laid out what information should be included on the screen and how that information was best laid out.

In going between the process flow mapping and the hand sketched, I was able to see in real time if an idea of which pieces information, feature, and diagrams play well on limited screen size. I was also able to put the screens to and features I was building out to the litmus test of me overarching and functionality goals.  Something that wouldn’t fit nicely on a single screen, or made the screen too ‘busy’ was a great signal that I needed to revisit the grouping, and break down the ideas into something smaller.

Once I was happy enough I moved onto digitizing the screens in Sketch. It is important to emphasis ‘enough’ because I have learned that when it comes to doing something creative, it is SO EASY for me to go down a rabbit hole in the details. The focus of this step was to have a high-level flow, with details in the layout and functionality and some copy, but not the icons,  font. That stuff comes later.

The Wireframe

A lot of change happened between the last iteration and this one based on user feedback and lesson’s I’ve learned. As a designer, and research I made my process in developing the idea more robust, and focused on the details of the flow and if that ties back to my overarching goal for the users. As a researcher, I focused less on the details of what the user was going to see, and more on the flow of how the users can step through the mockup, this meant less time spend on screen to screen actions and more time focused on what is the least number of steps that a user has to take to achieve the task I will give them during user testing.

 

In regards to the actual design the changes I made were:

  • apply a structure and pattern to navigation
    • banking options in a menu at the button so navigation can happen single-handedly
    • back buttons at the top in the same spot
    • there is the main screen have a banking menu and pages that go into detail don’t
  • make the screen more simple and clean by
    • using mostly white and with just some specks of color on only the elements that are prioritized
    • User good copy over icons for navigation
    • icons have the same style
  • make information more prominent by using models when necessary to explain something to a user to get their attention

Here is the results. Click here for a larger more details view of the screens.

Screen Shot 2019-02-14 at 9.07.45 AM

User Research

Interviews and Research Objectives.

While I was digitizing, I had made simultaneously arrangements for scheduled user testing. This helps give me a hard deadline to complete me digitizing and remain focus and avoid those detailed rabbit holes.

In my user research I had set out to learn the following:

  • a user’s banking and financial planning and assessment behaviors
  • what are a user’s banking and planning goals
  • what do users plan for? what motivates this person’s financial planning
  • do user already have a tool to help with monitoring or making budgets. If so what is it?

I think testing the design using the Talk-Aloud method where I would give user prompts and ask the user to talk me through what they are doing and I would occasionally ask them to elaborate on why.  This method allows me to listen in on how the person thinks about finances, their expectations, and reasons for disappointment and enthusiasm. By getting a glimpse of this, I could better understand what flows and elements get people excited or make them anxieties.

Screen Shot 2019-02-14 at 9.07.28 AM

Testing Results and Lessons Learned

 

Testing Results and Recommendations.

During user testing, there were three key screens that proved most problematic. Here are the problems and recommendations I would make.

Screen Shot 2019-02-14 at 9.43.50 AM

Screen Shot 2019-02-14 at 9.43.58 AM

Screen Shot 2019-02-14 at 9.44.06 AM

Screen Shot 2019-02-14 at 9.44.15 AM

Screen Shot 2019-02-14 at 9.44.23 AM

Screen Shot 2019-02-14 at 9.44.29 AM

 

Lessons About the User.

Screen Shot 2019-02-14 at 9.44.38 AM

Lessons on Being a Research.

There are some things in my control, i.e. presentation, some of the setting and my mood. There are something out of my control, i.e. how I am received. This came up when I realized the effect my voice has on other people. I have what I like to call a ‘sultry’ voice. It can be deep. So, when testing with women I noticed that they would often look to me to the direction which would affect the research data. Knowing this I paid extra attention to my tone and tried to lighten it, as well as be very intentional with my diction. In one example a user would as me “Is this what I am supposed to click? I don’t know” and I had responded with “What do you think that thing should do?” This did not help the user feel more confident in taking control. It was only after I asked questions with less room for negotiating a conversation that I get better results. In this last example, I started to ask “What is this screen telling you?” over “What do you think this that thing should do?”

Lessons as a Working Designer.

I found that a lot of my ideas of how elements should act on a page limited by the tools I was using. In one example I wanted a certain sorting bar to stay constant even as sections of data can be scrolled through have still had that sorting bar apply to that newly displayed data. This proved most challenging in Sketch and Invision.  My compromise was to apply that bar multiple times per data section. Looking back, this is not something I would hand over to a developer and ask them to build it based on the mockup. I would prefer to do a manual demonstration to  show the developer what I was aiming for in the design.  So in conclusion, DON’T rely to heavily on tools, they limit your vision to their features and offerings.

Another thing I realized was how inconsiderate my design can be to a developer. If this a project that I would like to see the light of day, I would integrate a developer earlier in part of my design process and ask them to talk me through parts that they imagine diffuclt to build and why.

In Conclusion

I still have mixed feelings about this project. There is no doubt that I learned a lot from this, but there is part of me that wishes There was more time to brew over the design ideas, the reasons for doing, and the benefit of the app at all. It’s cool to make something a tinker with it and learn as you go, what I would like personally is just a little more time to sit and take in all that has been achieved. I liken this project to a sprinting marathon. That is when you have to run top speed for a full marathon. It’s not a thing, but it can be! I know in the back of my mind that there is a payoff, and there is something to be achieved but it’s hard to enjoy it while you are doing it, because well, I’m not an Olympian or an expert UX designer with slick wireframing skills (yet).