Built For Use

For the past couple of weeks, we have worked to solidify the wireframes of our redesigned banking applications. For me, this involved going back through each of my flows and considering all the “unhappy paths.” Often, we refer to the path we want the user to take as a “happy path.” But, what happens when the user tries to do something else other than the one option you have given them? Or what if user error has caused them to get off the initial path? How do they get back? When I say that I have been considering the “unhappy paths” for the past two weeks, I mean to say that I have been considering all the paths that a user may take beyond the one I have chosen for them and then building out a flow that represents that.

To add, I have spent time refining, organizing, and adding annotations to my flows so that they may be presentable to a developer. Oddly enough, as a designer, I have spent a lot of time considering the user of the ultimate app in creating my wireframes. The exercise of making them readable to a developer asked me to consider another user, in the developer, for the first time and to consider how to make our wireframes most readable for the ones who will have the ability to make them into anything more than .png files.

I met with a developer (and former AC4D alum) this week to discuss my wireframes, consider gaps in my considerations, and get an estimate of the amount of time (and money) it will take to create my app. Below I am sharing some of the various flows I created:

Check Balance w:Annotations

Deposit Check

Transfer Money (Part 1)

Transfer Money (Part 2)

Transfer to Non-Wells Fargo

Set Alerts

Pay A Friend

Automatic Payments

In order to make our work as readable as possible for a developer, it is important to break down the various complex components of screens to show what they entail. Below you can see some of the components I included the “break down” I gave to my developer.


As I met with my developer, I learned about the estimated amount of time each screen would take to build. I learned that some elements would take significantly longer than others because of small customized elements I chose to include. I also was able to learn about gaps in the comprehension of my flow. He was able to break down the various screens by time estimate in a spreadsheet.

Screen Shot 2019-03-18 at 4.59.15 PM

My meeting with my developer was very constructive. My biggest learning is that I am possibly being “too detailed” in the wireframes that I am developing. That my intention is communicated more than I assumed. As I continue to build out my wireframes and annotations, I will work on being more strategic in my time and noticing what I can assume someone would know as standard from the Apple Human Interface Guidelines or other such guidelines.

I have estimated that it will take 198 days to build my app but imagine as I work to build out my last couple of flows that number will expand by a bit.