Product Sizing | Chase Mobile Banking App
This week, we’ve been learning the process of bringing a design or product to market. For this assignment, I will be using the Chase Mobile Banking app I redesigned last quarter. We were each assigned a developer who we will be working with to go through the steps of going from wireframes to a useable product. The developer I was assigned for this project is Chap, who also happens to be an alumni from AC4D. He has been a great mentor for my entire duration of AC4D, so many thanks, Chap!
First, I compiled all of the most recent screen designs and printed them out in order. I labeled them giving each screen a unique name. We sat down and went through every single screen to estimate and price each screen. I would start the conversation explaining what each feature was and he would ask questions to clarify.
From there he assigned each feature a number of points depending on how long he thought it would take. The numbers ranged from 0-5.
Through this process, I learned what types of elements app developers get for “Free” and which ones take more time. Essentially, the more.
So even if user tests prove your design works better than what is IOS standard, it might not be implemented because of the time it would take to develop. This is when it’s essential for a designer to have a clear idea of what features and controls are essential to the interaction.
There are some screens that aren’t a part of the “hero” or “ideal” flows but are critical to the usability of the app, such as having a negative balance or if there is an error due to connection issues.
After looking over each screen after our meeting, I started to notice there were quite a few redundancies and things seemed like they would take longer than I expected. So I asked Chap to schedule a Skype call to go over those screens to see if we could shave off any time. During the first call, he assigned any screen that was similar to something before a 1. However, during the call we bumped all of those from being a 1 to only a .25. Which shaved off quite a bit of time.
After the points were assigned to each screen, I added up the total for each major task and put it in an excel document. As you can tell below, it was originally projected to be completed Early June if the start date was Feb 1, 2016.
He ended the phone call telling me that he priced mine a little higher than some classmates because it seemed as if my wireframes and designs was at a higher fidelity. He said he knew if he were actually to develop it he would need more time to make it exactly right, whereas if they were less developed, he would have more room to add some design decisions himself. I was surprised because I initially thought for developers the less flushed out, the more time they would estimate. Chap has a design background so it would make sense how having the freedom to make design decisions could boost his coding efficiency. Where as with a traditional software developer might not feel comfortable making those decisions or make very well thought out ones.
After the call almost an entire month was saved.
From there I started asking these questions to decide the order of importance during product development.
I created a high level plan of when each version would be released and what features would be included.
Moving forward I will be creating a detailed timeline of when each feature, control & version will be developed and released.