Wireframe Sizing Evaluation

In our Product Management course with Scott Magee, we’ve been revising our banking app wireframes that we designed in our Q3 Designing Digital Interfaces course, in order to learn how a product goes from the wireframe stage to market. An important step in that process is identifying capabilities and controls within the app, then meeting with a developer to determine roughly how long it will take to develop the app based on those features.

At the beginning of this process, I took an inventory of screens and flows, and knew that there was a lot of functionality that was incomplete. Within the time frame of the assignment, I knew there would be a tradeoff between completeness and complexity. My goal was to have a complete set of flows, no matter how minimal in total scope, so I wound up having to reduce and simplify the functionality that I had begun to build out in Q3, including most of the financial modeling that had gone into the app. Although the current app only allows the user to do a limited number of actions – transfer funds, deposit checks, view balances, add accounts, view transaction history – those represent the core functionality of a banking app. There is very little that I wasn’t able to completely build out within the scope that I aimed for, and I feel satisfied with the current status. I have 12 main flows, including login alternatives and pre-login actions.

In an exercise to understand wireframing edge cases and errors, I decided to take a small portion of the app – login options – and include every error state and screen that I could predict, which is reflected in my flows. I quickly realized how time-consuming it is to design these, but also how important it is to consider how and when a user might cause an error, and what information they need to be given to proceed.

FLOWS WITH CAPABILITY BREAKDOWN

Flow 1 - Login Standard A

Flow 1 - Login Standard B

Flow 2 - Login Passcode A

Flow 2 - Login Passcode B

Flow 2 - Login Passcode C

Flow 3 - Login Fingerprint A

Flow 3 - Login Fingerprint B

Flow 3 - Login Fingerprint C

Flow 4 - Logout

Flow 5 - Call Us

Flow 6 - Locations A

Flow 6 - Locations B

Flow 7 - Enroll A

Flow 7 - Enroll B

Flow 7 - Enroll C

Flow 8 - Check Balance

Flow 9 - Dep Chk A

Flow 9 - Dep Chk B

Flow 9 - Dep Chk C

Flow 10 - View Activity A

Flow 10 - View Activity B

Flow 10 - View Activity C

Flow 11 - Int Xfer A

Flow 11 - Int Xfer B

Flow 11 - Int Xfer C

Flow 12 - Add Xtnl Acct A

Flow 12 - Add Xtnl Acct B

Flow 12 - Add Xtnl Acct C

Flow 12 - Add Xtnl Acct D

MEETING WITH A DEVELOPER

I had the honor and pleasure of meeting with developer and entrepreneur Mark Philip to size my app. As designers and students, we spend a great deal of time working on our designs, but meeting with a developer helped connect the work that I do to the bigger picture – how a product actually gets made. This meeting was a huge revelation to me in terms of the teamwork it takes to bring a product to life.

meeting with Mark Philip to estimate development time
meeting with Mark Philip to estimate development time

The meeting as a whole was a huge learning experience for me. However, I do have some key takeaways to remember for next time.

  • Having paper printouts of my screens was an enormous benefit. We could mark them up and have something tangible to reference later.
  • Mark worked with me to suggest some functionality that was missing, or to edit some elements of the screens as I had designed them. The conversation felt extremely collaborative, and I was grateful to have his experience and expertise influence revisions to my screens. I made the revisions we discussed together, which removed some extraneous screens and made the user experience better.
  • Mark suggested that it’s helpful to a developer to be given some sort of site map or architecture concept map, to aid in understanding how all the sections of the product connect. I’ll make sure to create and provide this going forward.

SIZING ESTIMATE

Sizing Spreadsheet

Mark gave me a summary in days, broken up by sections of the app – not necessarily complete flows, but pieces for development as he would approach it. The total came to 80 days, and Mark said that overall he would estimate 3 months for the scope of my current app. With 2 developers working full-time, it would take approximately 1.5 months to do the front-end development for my app, assuming that things went according to schedule. In thinking about the tradeoff of complexity vs. completeness, I’m very satisfied with how long this will take. My users won’t have a robust app, but they will be able to undertake the basic functions of a banking app with a shorter wait for roll-out. As I add functionality into the app, new versions can be released sequentially.

View a full estimation table here, with additional notes and info for each section of the app.

View a pdf of all documented flows here, including the sizing summary table.