Scoping a Banking App MVP

In our product management class we are picking up where our designing digital interfaces class left off. We’ve been tasked with taking our banking app wireframes that we made in Q3 and presenting them to a developer in a productive meeting to get a better understanding of time estimates if we were to actually move forward with building this mobile application.

I started by reviewing my existing wireframes and making updates for cohesion between the first set and second set I’d built in the previous class. Then I went through and began removing portions that alluded to screens that I would not be building or including in my MVP deliverable. This left me with 9 flows.

To help me organize all these screens, many of them being used in multiple flows, I wrote brief user stories for each of them. This cleared my head from all the screens swimming aimlessly up there and helped me focus on moving forward.

Next I exported all the screens into powerpoint and began labeling each screen in the flow order both numerically and with a descriptive title. I then went through and added all these labels for each screen to the estimate discussion spreadsheet. Then I went through and redlined all the features on each screen, and copied the screen and re-redlined the controls.

I met with Caleb, my assigned developer last Friday at Friends and Allies. We began by going through each of my flows with me explaining the clicks between each screen and what was being shown – basically following the user stories. Next we went through and discussed each screen and the time estimate he thought would be appropriate. He said he usually does his estimates in days so I worked with that and modified days to hours later. I was interesting because each new simple screen was estimated to take about 4 hours, but the estimates for the complicated screens that had unknowns in backend development quickly grew to be potentially 3 months of work.

These large ranges all hinged on how much research they would take, and at the end he said they still may not be possible. Basically they were just a big unknown. The big unknowns in development were related to the flagging transactions as recurring and anomalous algorithm, and the ability to link to a recurring payment entity’s site for cancellation.

Flagged anomalous transactions with information message.
Flagged anomalous transactions with information message.
Redirect link to cancel recurring monthly subscription transactions from the app.
Redirect link to cancel recurring monthly subscription transactions from the app.

The lower estimate for building this banking app MVP is about 13 weeks, and the upper estimate is 22+ weeks.

A few other helpful things I learned were:

  • Any kind of chart will usually take at least 2 weeks of development time.
  • Medium fidelity wireframes were his preference for scoping meetings (like this one), with more robust high fidelity wireframes being made for build out.
  • Many developers will increase their estimates to account for things that may come up unexpectedly sometimes doubling the actual time something may take.
Monthly trends chart will come in at around 2 weeks of development time.
Monthly trends chart will come in at around 2 weeks of development time.

Click below to view all my materials.

Redline Features

Redline Controls

Estimate Discussion Spreadsheet

 

Blogging with Beers 🍻: Mapping our Learnings

It’s been quite the trip, but we’ve picked up a lot of tools and insights along the way. We’ve learned about human-centered design research and synthesis. We’ve also practiced sharing our insights with others through tools like concept models, zooms, and service blueprints. Last quarter, we explored methods of ideation like reframing and insight combination to come up with over a hundred novel design ideas to combat impostorism in women.

Jen, Vicky and I have a few insights and learnings to share with our many loyal AC4D blog readers:

    • Be yourself and do what you want. [Present findings that you find interesting and others will too. Don’t be afraid to insert your personality into presentations!]
    • Always maintain a bias toward action. [When in doubt, creating is better than not creating!]
    • Less is more. [#aintnobodygottimeforthat]

We’ve created a glorious vision for where we will surely be one week post-graduation. Please join us as we bask in the reality of it all:

joanna-szumska-661142-unsplash

We will each be fresh off our one-week minimum vacation to a tropical beach, and returning bright-eyed to a new role at a company we like with a team we’re excited to work with doing work we’ll be proud of. We’re excited about taking what we’ve learned and implementing change for the better at work and in all aspects of our lives.

To do this we will need to create a compelling portfolio and earmark time each week to set aside to work towards this goal. Building in time for critique and review will be beneficial and a great reason to reach out and learn from alumni, mentors, and the design community at large.

In addition to doing these things, we will also be expanding on the concept that came out of our research on impostorism in women. We are doing this because…

We exist to create a world where women aren’t stymied by failure.

In order to make this vision a reality, we are reframing failure by designing an event series for women to come together and celebrate stories of failure. To do that, right now we’re answering the question of whether or not women are open to celebrating failure. So, this week we’re doing “think aloud” user testing to better understand reactions to our concept and messaging.

Join us: www.atxfailclub.com 🍻

Water Planning with the Best Intentions

The last couple weeks in our theory class we’ve been reading articles chosen to fit the theme of “With the Best Intentions”. Many of these had examples of design projects that were created with the intention of “doing good”, but may actually have had questionable outcomes. This theme was especially engaging for me, because of my work experience in government. I commonly associate my work and intentions to align with “doing good”, and take a lot of pride in my work. For this reason, I found myself reflecting on how the author’s viewpoints might relate to my experiences and the work I do, as well as my future work as a designer.

The story I used to frame my learnings in my presentation was a brief overview of water planning in Texas. Click here to read a quick one pager on how the state does water planning then come back here to see how my takeaways from this process could be applied to not falling into the “but it was with good intentions” trap for future designers.

Require diverse stakeholder engagement.

Involving many different perspectives (sometimes conflicting) doesn’t always lead to a clear picture or easy solution, but it often provides a wealth of insights and a more meaningful picture than approaching a problem with a narrower lens. This is especially important when dealing with wicked problems, or working in the public sector because a designer may not be a part of the community they are designing for, or personally affected by the problem. Not only can this create blindspots in the design that lead to the benefit of one group over another, but also a solution that could be more heavily influenced by the market instead of lasting change for good. By involving stakeholders from a variety of backgrounds a project can benefit from the knowledge brought by all parties to collaborate and try something new that none may have been able to come up with on their own. Lastly, relying on a wide range of stakeholders will help normalize a solution and make it more accessible and dignified for all users.

Empower the community to get involved in identifying and solving their needs.

The readings this week showed that involving the community you are designing for is not always enough if you’re not asking the right questions. Sometimes, it’s not enough even if you are asking the right questions if they are not able to answer them well. I think this is often why we jump to technology as an answer, because it is so good at giving us information quickly when that isn’t always the case with people. We as designers need to take the time to work with communities to provide the tools and resources necessary to help them identify what needs may exist, and participate in the process of developing solutions.

Create long term goals with iterative tasks.

We also read and discussed the importance of focusing on designing solutions for the root cause of problems versus the symptoms. Some examples showed that immediate, localized, or small impacts don’t always solve the problem, but may just lessen a symptom of the problem. With wicked problems it can be difficult to know the root cause of a problem because everything is so intertwined and connected. Therefore, an approach that incorporates a long term goal and outlook with shorter term iterative tasks provides the best chance of success and the ability to “design with”. This is because it allows for ongoing adjustments based on learnings and developments as well as steady forward progress.

Have good intentions, do your best, and feel good about it.

This is more of my own personal takeaway from the readings. I can see why these articles are good for us to think about as designers, but I was perturbed by many of them. Particularly irksome were the readings that highlighted how “doing good” has become a huge selling point and private industry has been capitalizing on it to profit. I don’t in general believe that private industry can responsibly solve wicked problems because they are driven by profit as opposed to government or non-profit organizations. Despite good intentions, thinking of consumers is different than thinking of people. However, I think it’s very important for designers and everyone to approach problems and the world with good intentions, do their best, and not let the idea of “selfish altruism” get in their way. Yes, I get validation from “doing good”, but it also inspires me and drives me to continue working and striving to have a positive impact which I refuse to find fault in – especially if I am conscious to keep the above takeaways and other learnings in mind.

Adding Analytics to a Mobile Banking App

We’ve been focused on creating screens and redesigns for a mobile banking application for the last few assignments in our digital interfaces class. This new assignment threw us a curveball. The prompt was to imagine that the financial institution we’ve been working with has recently merged with a company that specializes in financial analytics and modeling software. Our challenge was to integrate this new technology into our recently redesigned mobile banking application and test it with users.

Finding Inspiration

The first thing I did was look at a few existing budget and money analytics tools that currently exist. I used Mint a few years ago, so started by re-logging into my account to review how they have it set up.  I know that many people really like mint, but it never really worked for me and always felt kind of burdensome. I’m also not a fan of circular graphs and charts so in reviewing mint I knew I wanted to do something a little different than what they have created. Next, I thought about applications that I really love and ended up opening my Airbnb app to review how they have it set up. Despite it not being a banking app, I found it really useful in how straightforward and clear they present information, and place emphasis on providing users simple tools and tips to improve their bookings or activity. These were both things I wanted to include in my screens.

Testing Methodology

After creating my screens I sat down with 5 users to test the functionality and see what they thought. My goals were to make screens that were clear, intuitive and made people feel like they had the tools to improve their budgeting/spending/saving if they were so inclined. To do this I asked participants to use the think-aloud protocol. This is similar to a stream of consciousness where the testers talked me through exactly what they were seeing, thinking, and doing. Using this method helped me understand the why behind what they were doing.

The four flows/tasks and the screens involved.
The four flows/tasks and the screens involved.

Testing Results

I found that I hit that mark with some things, but missed on others. Overall, testing really helped me see where I could make edits and improvements in my design.

Monthly Budget Overview Screen
Monthly Budget Overview Screen

For example, Flow 1 and 2 the user goes to their monthly budget overview screen to better understand their spending for that month and see if it’s safe to spend $200 they weren’t expecting. This screen came across as overwhelming for all my users. Being struck with lots of numbers, a math equation, and a graph all at once was too much. Additionally, having the safe to spend amount in the top right corner was not very noticeable, and the legend for the graph was missed by many participants. To solve these issues, my thinking is to either remove the equation at the top of the page (since this information is also in the graph) and the legend. Then I will add labels next to the call out of the amounts on the graph and when they are clicked an additional info popup will appear to explain more in-depth what these numbers mean if a user is interested. This should make the screen cleaner, and more approachable.

Things that users really liked about this screen was the clear status indicator at the top and the smart filters at the bottom. All my users thought the smart filters were great and said they would use them frequently instead of filtering through their transactions looking for certain things.

Anomalous transactions flagged by the app with spending insights.
Anomalous transactions flagged by the app with spending insights.

In flow 2 users were asked to look for transactions in their checking account that the app may have flagged as anomalous. Every user first looked at the amounts, then the recurring buttons, followed by the entity name label, and then finally found the information button flags. In my next iteration, I plan to move these buttons to a more noticeable location and change the icon to be more of a flag instead of information.

On the message screen almost all the participants were surprised that the message was related to their spending habits instead of a fraud security alert. Some said they appreciated it, but the general consensus was that there should be an option to have control over what gets flagged and the messages they receive. Many also said they would expect to see any important messages when they logged in, and not have to go search for them.

Click here to run through the wireframe flows yourself!

What I learned about testing

I learned a lot about the value of user testing, and what makes it run smoother.

  1. Scenarios and the wording used in setting up tasks for users matters. For example, in flow 2 where users were asked to look for flagged transactions, the wording became very important in differentiating that they were looking for potentially fraudulent activity or just transactions that were out of the ordinary for their spending habits.
  2. The more mundane the context information the better. I found that testers can easily get distracted by filler information in wireframes, especially if it’s not believable or stands out in some way. For example, on one screen I created savings accounts for dog savings and fun money just to show that a user might have multiple accounts to choose from. Labeling these as “dog savings” and “fun money” caught people’s attention and distracted them from what they were doing.
  3. Test with your mobile device, but turn the lock function off during testing. I found it really helpful to have users test the mobile app on either theirs or my mobile device to the functionality felt more real. However, I did not turn the sleep function off, and it became annoying to keep having to unlock the device throughout the testing session.

IMG_2364

 

Impostorism Managed

Last quarter our team researched the impact that impostorism may have on women’s trajectory through higher education and the workforce. Since then, we’ve spent the last month working to turn our research into actionable business ideas. This was done by using a few different methods such as reframing, pattern creation, and ideation to generate a large number of ideas. Once we had these ideas, we went through them one-by-one to rank them on the following scales: level of fun, level of impact, feasibility, and capacity to build confidence. This ranking allowed us to filter down to our top five ideas.

Next we created storyboards, lean canvases, and theory of change structures for each of these five ideas:

  • Impostor Confessionals – is a safe space to share and celebrate your stories of impostorism in your life, and in doing so support others.
  • JVL Consultancy – women-owned consultancy that identifies and designs guiding criteria to demand equality in the workplace.
  • Destruction Box – self care, self reflection, and stress relief, all tied up in one monthly box.
  • The Ladies Dinner Party –  is a place where women gather to share and celebrate stories of failure — and in doing so, grow together.
  • Alumni Sharing – as students graduate AC4D and enter the workforce, they can experience intense feelings of impostorism. This alumni sharing initiative spotlights and shares those feelings to help overcome impostorism within all of us.

After presenting and thinking further on these ideas last week we did another round of down selecting to end with three ideas. Down selecting from five was hard because we all really liked all five ideas we’d come up with. We ended up combined the dinner club and confessional storytelling ideas into one idea where the dinner club would meet more frequently and  the confessional style event would be a semiannual or annual larger event. We also decided that even though we weren’t moving forward with the fifth idea as a business concept we’d still like to create the “prototype version” of it and gather impostorism stories from the AC4D alumni community to share with current and future students.

So now, we have begun the process of talking to people and testing these three ideas. This week, we interviewed one person to get her feedback on all three ideas. For this interview we had one lo-fi physical prototype of a product, and we used the storyboards for the other two ideas to explain their concepts and how they would work. Our hypotheses:

  1. The destruction box idea, while fun, may not be that effective for combatting impostorism long term.
  2. It may be difficult to get people to sign up to tell their stories of failure or impostorism on stage publicly.
  3. Human Resource departments are good entry points, and method for framing the JVL consultancy work.

IMG_2036

What we learned:

The destruction box may be more impactful that we thought. Our interviewee loved this idea. She talked about how this could release endorphins in the body and physically make people feel better. She also recommended that there be some sort of reflection tool so users can reflect on the why behind these feelings. She brought up the fact that women are traditionally associated with creating: Mother Earth, child birth, etc. and it was refreshing to embrace the opposite of that: destruction.

She said it reminded her of a similar past experience when she and others intentionally broke plates to symbolically destroy negative feelings. She says it felt cathartic, almost like… “Yeah! Is this how the bros feel when they walk into a board room?”

Our hypothesis that the dinner club might be an easier point of entry for telling stories of impostorism/failure was seconded by our interviewee. She liked both the dinner club and moth style event but said that as an introvert she was much more comfortable with the dinner party. She agreed that she would likely not get up on stage to discuss her impostorism, let alone submit a video to do it.

Lulu was most excited/most pessimistic about the JVL Consultancy idea. Her first question was, will you actually be able to implement this in companies? She feels that yes, we need this, companies need this, people identifying as women need this but it couldn’t only happen with HR. She feels like there’s no chance of success if we don’t have buy-in from leadership. We will need to focus more on how we could position ourselves to appeal to organizational leaders and potentially interview people in these roles to try and evaluate if/what would make them buy into this idea.

Looking forward, we have another interview tomorrow, and plan to continue to iterate and build prototypes of our ideas.

Current destruction box prototype for testing.
Current destruction box prototype for testing.

User Testing a Digital Banking App

This week I sat down with 7 people and had them test the wireframes and flows that I created as part of the redesign of the UFCU mobile app. The entire experience was new to me and I learned a lot along the way.

This was my first time using InVision to create a semi-interactive prototype, and there was a learning curve. Once I got the hang of it though it was really neat to link the screens and buttons and get a feel for what it would actually be like to move through this application.

Next, the user testing. I decided to test four flows on my users:

  1. You need to send your Uncle Bill $50 from your checking account for his Birthday.
  2. You need to deposit a $75 check into your checking account.
  3. You want to check your account balances to see if you have enough money.
  4. You are transferring $400 to an account outside of UFCU.

Click here to click through my flows yourself.

I asked the user to simulate logging in at the start of each flow. I used a finger print id button that they could tap to do this. It was interesting to see people’s mixed reactions to this first step. Some people loved it because they thought it was more secure, others were upset because they like using a pin, and still some kept closing out of the flow all together because they would hit the actual home button to scan their fingerprint.

Next was the main menu page. My thinking in redesigning this page was to put the more actionable items like depositing a check large on the top and the more passive items like looking up locations on the bottom. I learned that while this made sense to me, most people expected to the ‘Account’ button to be larger and at the top because this is what they said they do most often. There was also some confusion about the difference between ‘Making a Payment’ and ‘Transfer’. Flow one paying your Uncle was setup as a payment, but almost all the users attempted to transfer money to their Uncle. I think this could be redesigned to a more general button of ‘Send Money’ and then build in navigation to seamlessly help a user get to the appropriate flow.

IMG_0240

Another big issue for people was the ‘Search By’ screen for adding a new payee. On this screen I listed 3 options that they could search by: Business Name, Business Zipcode, and Email. Most users ready the first option and instantly got confused. One saying “My Uncle is not a business…” Then they would usually try and back out instead of reading on. I think I would re-arrange the order of the search items on this page to have email or just name at the top and separate out the business payees and personal payees as an earlier step in the flow.

IMG_0241

I learned many more things that could be improved with my wireframes, and really enjoyed the user testing. Overall the users thought clicking through the prototype was kind of fun and treated it a little bit like a game. Some were a little worried about getting things wrong. I also found out how easy it is for users to get caught up in the details. On one flow I said they were depositing a $75 dollar check, and included that in the amount section, but then used an image of a $50 check. This threw people off and made it a little less realistic. Having text autocomplete also made testing a little less believable and some people got a little paranoid that it read their mind.

Wireframing a Digital Banking App Redesign

If you’ve been following along closely to our very exciting adventures here on the AC4D blog, you may remember the last post showcasing a concept map for a digital banking application. Well dear readership, now I present to you the wireframes for that same redesigned application. For this assignment we focused on creating wireframes of the redesigned app to highlight specific user flows:

  • Check a balance
  • Deposit a check
  • Transfer money out of the bank
  • Set alerts and notifications
  • Pay a friend
  • View, setup, and change recurring bill payments

These are not meant to be finished products, but instead give a general layout to test usability and be a guide during development. For my redesign I decided to keep the overall setup of the existing app but add functionality that is currently only available through the website. For example, the existing application only has the ability to transfer money between your own existing accounts. In my redesign I created frames for the user to add and transfer money to account outside of UFCU.

Wireframe flow: transfer out of bank
Wireframe flow: transfer out of bank

Creating wireframes really forced me to think more about the details than the concept map. Especially about how the user would interact with the application. It wasn’t enough to just write the fields that would be in a form, but I had to think about how the field data would be entered, and how that would change the screen. Our next steps will be to turn these into prototypes and conduct user testing. I image I will learn even more about how users interact with my diagram and make it even more detailed as I begin connecting buttons with their resulting actions. Signing off until next time.

Concept Map Redesign of a Digital Banking App

For our first assignment in our Designing Digital Interfaces class we focused on mobile banking apps. I chose University Federal Credit Union’s mobile application. With the goal of outlining all the application’s functionality to better understand where changes could or should be made I started by clicking through every single button in the existing application and taking screen shots to look back at and reference. I also quickly sketched out the hierarchy of the buttons and pages. This sketch helped me visualize the flow in the application as well as start to differentiate the main product areas, subsections, non-core functionality, and non-functional areas.

Then, I was ready to start laying out my concept map. After struggling for a bit to find a program that I liked I decided to just pin what I had to the wall so I could look at it all at once. This was really helpful for me to be able to move portions and play around with layout.

Early drafts of UFCU concept model
Early drafts of UFCU concept model

Finally, I digitized my concept map using arrows and element placement to show hierarchy and feature flow within the application.

Concept map of current UFCU mobile application
Concept map of current UFCU mobile application

I also used element size (large to small) to show which features I deemed the main product areas, subsections, non-core functionality, and non-functional areas. Depicting digital forms and questionnaires in the application was a little tricky. I chose to use boxed outlines and dotted lines to identify and group form elements.

Concept map legend
Concept map legend

This is an application I’ve had for years, and I’ve always thought it works great for my needs. I usually use the mobile app to check my balances, transfer money between my own accounts, and deposit the rare check. Looking at the whole concept map, that seems very small, maybe only a third of what’s available.

Concept map of redesigned UFCU mobile application
Concept map of redesigned UFCU mobile application

I found this model of the existing application very useful as I began thinking about the second portion of the assignment which was a redesign of the application. If you’d asked me before what should be changed or added, I’d probably one have thought to add the ability to make mortgage payments through the app, and definitely wouldn’t have known where that might fit. Being able to visually look at the entire application was really useful in identifying the missing functionality, and choosing the best place to add new functionality.

For example, in the ‘Bill Pay’ section I didn’t have any payee’s setup, and there is no functionality in the mobile app to add one. This is a dead end for a user so in my redesign I added that functionality.

The existing ‘CardKeeper’ screen has two buttons that currently open an info box with a phone number to call, but this number is not linked for a user to click on it and immediately dial. If this app is redesigned I think that would be more helpful for users who are likely already frustrated about their missing card. Other functionality that was added in the re-design includes the ability to setup and manage notifications under the ‘More’ button, transfer money to other financial institution accounts in the ‘Transfer’ section, and updated payment options.

Service Design at the Castle

Jen Figueroa and I have spent the last 16 weeks conducting a service design project for Castle Hill Fitness. Our research focused on understanding the new member onboarding experience. Please visit the website we’ve created to showcase the many deliverables that came out of this project, and be sure to read back through our blog posts to learn more about our process along the way.

CHF_WebsiteImage

Feeling like an impostor

Over the last couple weeks we’ve been learning about impostor syndrome to get a better understanding of what impact it may play in women’s higher education trajectory from cultural background to employment. To do this we first needed to get a better understanding how we were going to identify when someone may have experienced these feelings. Below are three concept models that we’ve developed based on our interviews with subject matter experts, stakeholders, and participants to help us describe and identify feelings associated with impostor syndrome.

Figure 1: What You Know vs. What Everyone Else Knows
Figure 1: What You Know vs. What Everyone Else Knows

As shown in Figure 1, feelings of self doubt associated with impostor syndrome may sometimes stem from the idea that everyone around you knows more than you, when in reality you all know the same amount of information.

Figure 2: How much of your success is due to hard work vs. luck?
Figure 2: How much of your success is due to hard work vs. luck?

Another way to spot feelings of impostor syndrome when they may not be apparent is when someone attributes most of their success to luck despite the large amounts of hard work that went in to reaching that goal, as shown above in Figure 2.

Figure 3: Volume of Self Doubt
Figure 3: Volume of Self Doubt

While many people experience a certain degree of self doubt on a daily basis we are learning that there are certain situations and factors that may increase or decrease the volume of those feelings. These are important because they may help indicate times when these feelings get so loud that they could have a higher potential to influence someone’s behavior or decision making. For example, Figure 3 shows that a common time for these feelings to manifest is during times of change or when someone is experiencing something new. Dealing with unknowns can be scary and if someone has no prior experience, as a foundation to build from, it can be easy to make assumptions about other’s experience and knowledge compared to their own. We’ve also learned that people who are juggling and switching between multiple, and sometimes conflicting, roles may have increased feelings of self doubt and uncertainty. Conversely, we are finding that having mentors, support networks, and building knowledge and experience can be tools to decrease and overcome these feelings.