Feature Breakdown and Sizing Summary: Details, Details, Details
For our first Product Management class assignment, our task was to markup the flows we made in Q2 of our banking apps and then facilitate a conversation with a developer to create an estimate for how long it would take to create the banking app based on the number and difficulty-level of its features.
Here’s an example of a marked-up flow:
The idea is to provide enough detail about each flow, feature, control, and component that the developer could build the app without the designer sitting there the whole time to answer questions about which button goes where, etc.
The designer then shows the markup to the developer so that the developer can request any additional details the designer may have forgotten. The developer can also suggest better, more efficient ways to accomplish the same goals the designer wants to accomplish and provide cost-benefit analysis around how to build a feature or if a feature should be built at all. Though the estimates the developer arrives at for how long it would take to build out the app’s various features will inevitably be wrong, it gives all parties involved a starting place for planning how the rest of the product’s development should proceed.
I’ll get to the feature breakdown and sizing summary below, but first I’ll write a bit about what I learned by going through this process.
Forcing Mechanism for Iteration
First, marking up the Velocity Credit Union redesign wireframes forced me to refine them even further from where they were at the end of Q2 because it helped to counteract the urge to blindly copy-paste components from similar screens without thinking deeply about what they would mean in this new context. For instance, in my Bill Pay to a New Payee flow, users have the option to search and select from a list of payees that are big companies whose information is pre-loaded into the Payee API. My first iteration of that wireframe featured a chevron (the little arrow point) next to the company name (in this case “Sprint”), but that didn’t really make sense. Users shouldn’t be able to change Sprint’s contact and banking information, so why would that business name be clickable?
Chap Ambrose, the designer-developer who was kind enough to give me an walk me through the estimate process with my app, was able to point out ways in which I needed to be much more specific in labeling pieces of my flows. For instance, my original markup for my home screen, I had just said to change the greeting message to good morning, good afternoon, or good night depending on the time of day without actually specifying when those switches should happen.
I also hadn’t really thought about possible edge cases, such as what should happen to a list of saved bill payees if it the person tried to save 300 bill payees. Should they all load at once? Should the app load the first 10 payees in a scrollable list and then have a “See More” button?
Legal and Security Issues
Chap also pointed out that especially for a banking app, legal and security issues would come into play in the design in ways I hadn’t considered. For instance, he said that he would have to build time into his estimate of my “Wrong Password” flow to figure out whether he would be allowed to implement my original design suggestion of giving the user the explicit feedback that the password was incorrect. He would also need to know how many times a user could try to sign in before they would get locked out, and what would happen if someone tried to log in from out of the country.
My original version of my “forgot password” flow – possibly not feasible from a security or legality standpoint.
Along those same lines, Chap brought up another factor I had not considered: sandboxing issues. Sandboxing is a security mechanism that limits the environments in which specific pieces of code can execute in order to try to limit the reach of malicious software. For instance, Chap reminded me that I would need to explicitly ask users for permission to use their camera in my Mobile Check Deposit feature, which makes sense because as a user you don’t want just any app to be able to access your camera whenever.
Apple’s Human Interface Guidelines also dictate that you can only have a modal pop up asking your permission to access the app once, so as a designer, I needed to account for what would happen if someone denied the VCU app permission to use the camera the first time around, but then later wanted to use the mobile deposit feature. Namely, I would need to wireframe some kind of tutorial letting the user know how to go into their device’s settings to manually change the permissions for the VCU app. This “Denied Camera Access Tutorial” was the only feature in my app that Chap was not able to give me a sizing estimate about since I had not wireframed that process at all.
All Things Are Possible, But Not Necessarily Feasible
One of my biggest concerns going into this process was that my “Ways to Save” feature, which was the most imaginative set of wireframes I created in Q2, might not actually be possible to build out because it involved analyzing people’s spending patterns and then making concrete suggestions based on those spending patterns about how they could spend less. Chap reassured me, however, that the Ways to Save feature wouldn’t be a problem, but due to that feature and a few others surrounding tracking transactions and account balances, I should make the VCU app into a hybrid rather than a native app. This would mean the app would be using APIs (such as pre-existing code building blocks that would have been made for Velocity Credit Union’s internal or web-based banking software) to actually make some of the features of my app functional. For instance, the account summary buttons in my app would be quicker to build if the text in them were populated by a pre-existing Data Account Balance API.
APIs would especially be helpful for the more complicated features that someone must have already built out for other apps, such as Touch ID. Chap thought that it would be faster to just find or buy a Touch ID API than to build one from scratch. The downside to using APIs, though, is that you cannot always tell going in how reliable they are. APIs could be poorly coded, or the programmer in charge of one of the VCU’s APIs might be really hard to work with. For this reason, Chap added extra time padding around any features he thought he would use an API for.
The Actual Estimate
As to the actual estimate, Chap thought that it would take 2 developers approximately 9 months to build out all the features I showed him in my flows. This estimate did not include the “denied access to camera tutorial” for people who did not give the app permission to use the camera the first time they tried to use mobile deposit since I had not created those wireframes at the time of our meeting.
Chap arrived at that estimate by assigning point values to each feature based on whether he had built similar features before, whether he thought an API would be available, and if the features included custom controls, among other factors. One point corresponded to about one day of work for a single developer. Chap then multiplied those initial point value guesses by 1.5 because he likes to pad out his estimate just in case. Then, since this would be an enterprise software product for a bank that would presumably involve many legal and security issues, he multiplied that second total by 2. The detailed breakdown is available here.
In all, he thought the app would take about 195 working days for one person to do (about a year), or about 9 months for two developers. At a rate of $1,200/day, which is what Chap said he would charge for this kind of work, that would put the cost of creating this app somewhere in the neighborhood of $175,000.
For our next project, we’ll be looking at how we could pare down our apps in order shave down that cost estimate. Check back then to see how my redesign of the Velocity Credit Union app has evolved.