Meet the developers!
First off, a big thank you to all the developers for offering their time to us.
Over the past 2 weeks I have revised and notated my banking app wireframes in preparation for meeting with a developer, Caleb Thomson, to discuss sizing. Sizing is the process of pricing the cost to build the visual and functional interface of the app. Caleb quoted pricing as number of days with a half day minimum. In preparation for the meeting I laid out each flow on canvases to notate features and controls. I classified controls as elements (buttons, sliders, dropdown menus) that you interact with and features as attributes of each screen. The documents are the key to the meeting of the mind of the developer and designer. To me, using the document as a source for discussion was similar to being an architectural designer meeting with a builder. The same frustrations exist between what the designer dreams and what is a possibility for the builder.
In the end, I combined the features and controls onto one page which made it easy to discuss my the goals on each screen and have questions ready to gain insight into the time necessary for a simplified process of meeting the same user goal. One of my personal objectives was to learn as much as possible about the time it takes for functions in order to implement that knowledge in any future app design so I included the more complex features and then was sure to ask how much it would cost to reach the same goal in a simpler fashion.
One of the most valuable things I learned about while understanding the time it takes to program functions was about information flow. The diagram below shows how information travels back and forth from the app through the cloud to the API (Application Program Information). Information from the bank server flows back and forth through the API to desktop computers and apps. I learned the features that took the most time were those that required displaying information that would not typically be “packaged” by the bank server or on the desktop site. The strongest example of this was showing recurring charges.
Through my questions I learned that diagrams like bars and pie charts take up weeks! In my flows I created 2 different bar graphs with similar information, but since they were slightly different sizes each could take 1-2 weeks.
My first flow shows the login process for a user to check their balance. I was really surprise that something that seemed pretty straight forward was estimated to be 2-3 weeks. Caleb informed me that I had more detail than necessary and at this phase simply a placeholder box indicating what would be completed on each screen to avoid distraction any place where spacing was not perfect.
My next flow was an insta balance feature for the user to conveniently view their balance if they did not need further detail. This would take about 5 days, not including sign up screens to activate the insta-balance.
The second flow shows the process to reach transactions and details of the transactions. Screen 2.2B contains a bar chart the tI referenced earlier that takes weeks!
During user testing of the deposit check flow, I found that some users were weary about depositing with photos so I added a feature to show the account number and bank routing number of the photographed check. I learned that this was possible because of magnetic ink in the checks, however it would be weeks to code. Additionally, I was surprised that adding directions to the top of the camera was time consuming. Having the camera recognize the edges of the check and automatically photograph the check would take up to a month.
In the move money section, I built out the pay a friend feature and variations of frequency and when the transfer would occur. I was surprised that there was not much cost difference between the different sequences.
I learned that having a pop-up “toast” confirmation would take one week. If I had a static screen it would be 1-2 days, and then the following screen would be 1/2 day.
One of the financial budgeting features I built was the ability to see your different budget “buckets” visually in a chart, scroll down and see what portion of your budget you have used each month, and then the detailed transactions in that category. Again, there graphics are really time consuming and the pie chart was estimated at 2-3 weeks. One funny takeaway was that when I was constructing the wireframes in sketch, I wasn’t able to make this visual so I downloaded a static image of a pie chart and placed a white circle inside it so it became a ring instead of a pie. Caleb said he would write it the same way!
The second budgeting feature I built was to see recurring payments and be able to see how eliminating the ‘subscription’ would impact your financial goals for saving and paying down debt. Caleb thought this was a great feature but defining the recurring charges would be a challenge because that may not be identified in the bank server so would be very time consuming.
View the sizing estimate here
Thank you again to Caleb for his time. I am looking forward to my next steps of reducing the features to be more cost effective.