Screen Shot 2018-04-02 at 10.35.20 PM

Slicing Flows To Ship Minimal Loveable Product

After the developer meetings I had a few weeks ago and putting together our estimates for my  mobile banking application I was instructed to take my mobile banking application redesign wireframes and “Thin Slice” the hero flows in order to ship a minimal viable product.

Artboard 4@3x

Then I was asked to create a product roadmap illustrating which flows I was prioritizing. I created a road map based on the features and components that Chap (the developer I spoke with) gave me estimates for. The estimation to ship for my flows, according to Chap, would take around 127 days. I needed to look at each of my flows and see what I could take out  and still have a functionable and differentiated app.

Road Map@3x

What Could I Live Without?

 

I started by asking myself, “What features I could live without, while still giving the user a great experience?” I wanted to prioritize features that the developers said they could easily do in order to provide the most value up front by not making my developers get burnt out. I rationalized that by having the developers work on the easier and more straightforward parts of the app like navigation and accounts.

 

The main thing was that I needed to ship an app that functioned well at the beginning by doing one or two things really well, rather than trying to work on the more complex things at the beginning and shipping a product that was full of bugs. In my experience, apps that have a lot of errors upon initial release lose a lot of users. There were things like Spending analysis and transaction analysis that I thought the app could live without and actually might be better for in the beginning. I still do feel they are valuable, but having them in the initial shipment would just slow things down and take time away from the core navigation.

 

Prioritized Flows

Artboard 1 copy 4@3x

Login (With Touch ID)

 

I decided to ship the login capabilities as they were first because: 1. I understood that you can’t have a banking app without first logging in; 2. I found that, based on my usability testing, that Touch ID is a huge convenience thing for mobile banking. Many people hate having to continue typing passwords, especially the long passwords that most people have for their banking accounts.

 

Checking Account Balance

 

This flow was especially important because I purposefully designed the app to be minimized for the user by having them be able to navigate within one or two clicks away from the homepage to get to the majority of features within the app. So, having this flow and the components and capabilities developed for this flow to work would be a huge win for the entire app. Basically once this flow is done, I can just get developers to work on quick flows away from the home that, from the conversation I had with Chap, shouldn’t take much time at all.

 

Schedule Payments

 

This is another flow that I didn’t cut much from as it housed many of the core functions needed for future flows. Similar to the Checking Account Balance flow I chose to ship this early and keep most of the features because it was important that the developers create this flow, so when it’s time to create the other Bill pay features they know what works and doesn’t. This way I’ll be able to wireframe taking into account to their preferences.

 

Thin Slices

First Flow@3x

Deposit Checks

 

Many people would say that waiting to ship the Deposit Checks flow until week 7 would be unwise, but I felt that given the core functionality and value that my other flows had that waiting until week 7 was a smart move. For the MVP I also decided to cut certain features like: Edge Detection, Viewfinder Transparent Photo, and OCR – Amount.

 

I chose to cut Edge Detection and Viewfinder Transparent Photo because I felt they were a nice to have in terms of improving the user experience. Most of the users I tested with were intuitive enough to understand how depositing a check works and they relied on prior experience and trying and failing to understand the flow. Most, if not all, went through the paper prototypes fine without the edge detection and some even got confused by the viewfinder transparent photo.

 

I struggled with The OCR – Amount feature (A feature that automatically put amount from check in it’s field by analyzing the checks amount that is written down) because it eliminated so many more steps within the flow, which was a key design principle I had while creating the app. In the end I chose to cut the OCR – Amount feature because I knew I had to pick my battles when working on a banking app. I figured that as long as I can get minimum feature of depositing a check shipping then I can implement improvement later. In the end it might even be a good things because users would be excited later on that they get this new feature.

 

Spending Analysis

 

I cut this because it was initially supposed to be a differentiating feature that would set this new redesign away from most other apps that are out there. After thinking about the MVP and shipping my product I realized that the current app for my credit union is absolutely terrible and just the navigation and simplicity would make it a far better product than is offered currently.

Second Flow@3x

I cut most features within the flow with the exception of the optimized loading feature. This was because Chap told me this was a good way to minimize the times I needed to use an API and by actually have the app work within itself it can reduce security risks. The only reason against working within the app is that it requires a lot of processing power and sometimes takes more time that users are used to. The optimized loading screens would make it so that app can process within and the users will get to see colorful loading screens which will make it so they don’t mind the wait time as much.

 

Transaction Analysis

Artboard 4@3x

I cut this flow and the features within it for the MVP because, much like the Spending Analysis flow I felt like they were a “Nice to Have.” It didn’t provide enough value to the users experience, based on the scenarios I mapped out in quarter two, to include it in a v1 shipment.

 

 

 

Be sure to read my last blog post Communication and The Process of Shipping Products, and feel free to read more of my blog posts from my other projects and class while studying at Austin Center For Design.