Moving from Wireframes to a Product

Resurrecting Quarter 2 Artifacts

This quarter in Product Management, we are learning about giving life to a product, starting with wrapping our heads around application development.

To learn more about developers’ timelines and considerations, I dusted off my wireframes from last December’s Rapid Ideation and Creative Prototyping Course.

Back in Quarter 2, I created 5 iterations of wireframes for my banking app re-design. With each iteration, I went out into the wild (mostly places with beer) and had strangers talk through navigating the app’s flows.

Think-Aloud Testing

The class followed think-aloud usability testing protocol, which has the tester verbally express their thought process as they work towards a prescribed goal. Throughout the activity, the administrator is unable to answer any questions the tester may have, simply responding and probing with “please keep talking”.

This method can feel uncomfortable, but this discomfort comes with a reward: with 6-10 think-aloud tests, designers can identify their product’s primary usability issues.

Application Sizing

This first assignment focused on understanding how long building something actually takes and which components are the time sinks.

I was very fortunate to get almost two hours with Mark Phillip, an Austin-based developer and entrepreneur, to size out my wireframes. Mark went through flow by flow (log in, check credit balance, transfer money, etc.), estimating each one in days. This post covers my higher level evaluation, as well as the particular pieces that will stay with me as I move into building a product roadmap.

Below is a snapshot of how I prepared my wireframes for meeting with Mark. The highlighted pieces are buttons, components, and features that I wanted to ensure got included in my estimate.

Credit Card Transactions and Transaction Details
Credit Card Transactions and Transaction Details

123 Days of Development – The Breakdown

Review the complete breakdown and discussion notes here.

Estimate Board

Adding and editing payment recipients is a time-consuming feature. Additionally, I have 4 different ways to send money. If I can nail this and streamline the payment workflow itself, I can save time on these 26 days.

Time-Intensive Features

There are a few expensive goodies which I’ll have to weigh – how beneficial are these to the user experience?

  • Auto photo capture for check deposit: 2 days
  • Personal avatar with photo saved bank system-wide: 4 days
  • Just push notifications would take 2 days less than doing push, email, and text notification options
  • Touch ID login: 2 days



I would love for my application to be available in more than just English, so I asked Mark about translations. Developers call this Internationalization, or I18N for short, and it is a lot smoother to work on from the start of the process.

language selection

While building the app, a developer would flag each language item on the screen, and that flag serves as a placeholder to pull in languages from any dictionaries. It’s 10-15% extra days on top of the entire app estimate, but, once it’s in place, any language of similar word length can be easily integrated. This will be a tough, but urgent decision to make as I create my product roadmap.

Recurring Transaction Options

My original wireframes included almost any option you could want for a recurring transaction:

  • one time
  • weekly
  • every two weeks
  • monthly
  • quarterly
  • every six months
  • annually

Mark estimated that building 2 monthly recurring options would take 3 days, while adding two more options would increase the estimate to 5 days.

I need to discriminate which types of payments really need recurring options, and then how many options users really need to satisfy 95% of users.

Charting the Course

Over this next week, I will be gathering my takeaways from this meeting to prioritize the building of my banking application’s features.

More wireframes and flow annotations can be found here: Wireframes V6.

Reviving the Chase Mobile Banking wireframes

After about two months of collecting dust in far-far away folders on my laptop, Chase Mobile Banking wireframes got their second life this past week!

This time, we are going to see how much it costs to bring this app to life. To accomplish that, I have prepared the wireframes in a format that I thought would be most helpful for the developer who would do the estimation… I’ve made sure everything is good with Sketch, and have organized the wireframes in Invision, and eventually met with the developer to get a rough estimation.

Before the meeting, I felt pretty good about the wireframes. I thought they looked decent and make a lot of sense. To be honest, I was quite proud of my achievement in Q2, especially taking into account the fact that we had two other very intensive classes going on.

Screen Shot 2018-03-19 at 9.30.45 PM

I had enough time to forget that the wireframes weren’t *that* good. But the meeting with the developer opened my eyes to how much was missing and how many questions weren’t answered.

Here’s something that I thought was very important about the way I approach this class. I want to ensure that anything I do and learn should help potentially working with remote developers. That’s why I decided to take a risk and try to organize all screens and detailed specifications in Invision. I already used this app for user testing of these same wireframes, and it was the time to explore the capabilities of the app for remote collaboration.

I started with making connections between the screens, adding what is called “hot spots” (clickable areas) – a very long and boring process, but so insightful! I realized that so many buttons still don’t lead anywhere. So many pages are missing. Sometimes, it was not clear where a “Back” or a “Cancel” button would lead. That really helped to do some micro-iterations on certain screens.

Here is my Invision prototype if you are curious!

During one-hour-long meeting with Mark Phillips, owner of “Are You Watching This?”, we were able to walk through all existing flows, cover some of them in much detail, and just slightly touched others. Nothing really surprised me in the estimation. But I was finally hit by the realization that this is a long, very long process to develop a comprehensive set of wireframes for a Mobile Bank App. According to his estimate the app will take him about 8 months to develop.

Screen Shot 2018-03-19 at 9.28.51 PM

The process of estimation I had was not as efficient as it could be. I wish I had all the specifications and components list completely done by the meeting with the developer! Not necessary to show it all to him (we only had one hour together), but to minimize the number of questions I didn’t have an answer on. The lesson is learned. But then, it’s clear that the more often we meet, the easier it is to align with the direction and ensure I prepare everything the developer would need from me going forward.

I am looking forward to getting to a comprehensive deliverable for the developer this week and solidifying the estimate.

Discovering the world of product management

This quarter in Product Management

So far we’ve learned skills that have to do with design, business development, and production of technological products.

We started this quarter with an introduction to product management, method and skill (that will be added to our toolkit) and that aims to better prepare us to lead product planning and development from beginning to end. {the intention of having this knowledge is…}

Before this first assignment, the class had a brief introduction to the world of developers. For this, three guest speakers came to AC4D and talked to us about their ventures, process and current projects that they’re working on. From server configuration, to web development, to hardware software development, all three speakers shared their perspective of what it should take for us to have an efficient feedback session with a developer as part of a Product Management role.

For this assignment, we were tasked to show our baking wireframes to a developer so they could and facilitate a feedback session with them so they could size – assigning relative estimates to unique features, components and controls. Before this first assignment, which I will be telling you all about below, my peers and I already had a general idea that:

  1. Developers strive for efficiency, the more accurate information they can have about your product, the better
  2. There is no universal way to do sizing (developers all use different methods but the most typical ones are “t-shirt sizing” and “fibonacci sizing”)
  3. The estimated time it will take is almost never accurate, but it’s useful to have active conversations with the developers anyways because it provides clarity of what it takes to develop a mobile app to everyone involved in the project.

Break down feature and capability

In order to prepare the screens of my banking application for my meeting with a developer (and AC4D alumni – Chap Ambrose), I started by reviewing the screens that I had created in Q2. I started by separatating each flow into its own category, duplicating the screens that I needed to in order for the flow to make sense.

Sizing Exercise - 1
Sizing exercise: Preparing screen flows for walkthrough with developer

After this I started analyzing each screen in order to categorize them by feature (behavior of the system that directly fulfill some user need. Aka: “view account summary”) and component or control (system parts that provide and encapsulate common functions needed to implement features. Aka: “drop down list”)



Components breakdown_example
Example of screen annotation for component breakdown (“Account Balance” flow)


Features breakdown_example
Example of screen annotation for feature breakdown (“Account Balance” flow)

After doing this for each one of my flows, I started documenting each feature and control in a spreadsheet by assigning them a label with a name, a unique identifier and a description under each of those elements. All of this is done outside of the context of the wireframes so the could stand on their own. Each screen pertaining to my wireframe flow was also given a unique identifier that was added to the documentation of my components/features so that they could be easily referenced.

Out of context documentation
Documentation of each feature and component individually and out of context.

The whole annotation process ended up looking something like this:

Annotated screens

For a detailed view of all the annotated screens click here, for the breakdown exercise. here, for the entire breakdown.  

Sizing Session

After finishing preparing my screens, it was time to meet with my assigned developer to get a estimate for the development of my app! Activity otherwise known as “sizing” – a method for assigning relative estimates to unique features, components and controls.

Prior to meeting with Chap he let us know that the proper way to show him our screens would be directly in my Sketch file. So before our meeting I made sure my annotations were made directly in my file. Our meeting was in a coffee shop, he had his computer where he opened an Google spreadsheet ready to annotate information for each of my screens. As I walked him through the screens, he quickly analyzed each one of them and asked questions, shared concerns and made suggestions. After I attempted to clarify each point, he identified each screen on one of his google spreadsheet fields and gave it a number. I will share my learnings below:

Things I hadn’t thought of:

Source of data: The developer will need to have an idea of the source of the data that my app will use. Since I’m not actually employed by bank, nor I’m a bank owner, I had no idea how to answer where the data of the transactions will be coming from, or the source of the API’s needed for to make it actionable.

Things I didn’t know:
  • By now I know that each developer has a way to measure how long it’s going to take them to complete a project. In class we were introduced to the concept of sizing using t-shirt sizing and the Fibonacci framework, but my developer used “points”.
  • API knowledge: There were a lot of questions regarding data sources which I had no idea how to answer, but definitely gave me a notion of what types of questions I would expect from another sizing conversation.
  • Legal concerns, due to the nature of the project – Banking Application -, there were questions around how safe it would be to handle private type information like a banking customer.
What I will do better next time:
  • Time management: Ask beforehand how long it will take to go over a specific amount of screens to know how much it will take to go through them during the sizing session.
  • I would have liked to have had an intake form with each screen number so I could take notes for each screen in a more efficient way.
  • Missing screens: there are a lot of interactions I did not think through when building the screens for my app. Many of them have to do with edge cases that I did not take the time to come up with. To do this, it is advised to spend some time analyzing each screen and come up with different scenarios that could trigger different responses.

Unfortunately, the meeting had a hard stop after exactly one hour and I had more screens that we did not have time to go over. But at the end of our meeting I was able to get a high level estimate of how long my app will take to be developed.

Screenshot of estimate spreadsheet (Flows “Account balance” and “Pay someone”)

For a view of the entire sizing spreadsheet, please click here.

Fields highlighted in orange are missing screens that the developer did not know how to estimate. I also learned that, the less unknowns the developer has or detects in the customer (myself in this case) the more likely he or she will be to double the amount of time it would take for the app to be developed. Considering that I potentially had only 50% of screens of the entire system I was given an estimate of 120 days of work (excluding questions marks, aka: screens without wireframes).

Next Steps

After this exercise, we will share our learnings in class and get feedback which we’ll then use to create a roadmap to plan for our product development.

Shifting from Design to Product Management & Development

“Put on your thinking cap!” Do you remember your elementary teacher saying that?

I used to think it was a quaint thing to say, but there’s a lot of power behind the symbolism of the thinking cap. Over the last two weeks, I put on new thinking caps – the developer and product manager’s thinking caps.

Over the course of eight weeks in the winter, I redesigned the Wells Fargo Banking app. From concept maps and information architecture maps to mock-ups, usability testing, and many iterations of the wireframe designs, the app’s design slowly took form.

Wells Fargo Redesign – Concept Mapping

Wells Fargo Redesign – Rapid Prototyping

Wells Fargo Redesign – New Features

Over the eight week period of this quarter, we’re taking a very different approach to thinking about this app redesign. Rather than rather than thinking creatively as designers by putting down the constraints of what’s “realistic” from the business perspective, we are learning to think creatively from the perspective of developers and product managers. How do we make that abstract design into a concrete reality. The key word here is “concrete”.

To create a vision for how to realize this design, we are walking through various exercises typical to development and delivery.

  • Feature analysis
  • Sizing (Estimation)
  • Product Road Mapping
  • Thin-Slice development

This blog post is about Feature analysis and sizing and my experience completing these tasks with my Wells Fargo app redesign as the sample project.

Feature Analysis

First off, what is “Sizing”? Sizing is just another name for estimation. We want to create an app, but first we need to size it up, or estimate its potential cost, in order to keep the process in check. Without a good estimate, it’s easy to let development costs and timelines get out of hand, severely jeopardizing the success or viability of the project.

The first step to creating an estimate for the development cost is to break down the application into its individual parts. We can think of the app as having two types of “parts” – its features, and its elements. By breaking down the app into smaller parts, we can price out each of the parts in order to have a more accurate sense of the effort and cost to develop the larger whole.

What is a feature? A feature is a capability. The app for example, allows for depositing a check with your phone. The fact that we can do this is like magic. But to paraphrase a quote attributed to Thomas Edison, “All magic is science that isn’t yet understood.” That high-level capability is important to list as a feature for the app, but it isn’t broken down yet into manageable chunks that helps a developer understand what to code. So we can break it down further and further until we have the right level of detail so it isn’t too high level or too granular to be manageable by the developers who will need to code the app.

Image of Mobile Check Deposit Screen
Mobile Check Deposit Screen

In the case of Mobile Check Deposit, we can break this high-level feature down to things such as:

  • Indicate Account into which the check is deposited
  • Take a picture of the front and back of the check
  • Pull up Photo-Taking Tips
  • Input the amount of the check
  • Provide Check Deposit Confirmation to User

These lower level features spell out the various capabilities and actions one may take to deposit a check.

All of these features and sub-features or functions are very abstract, however. What do they look like? What are the pieces and parts that give form to these functions? These are the elements. Examples of these elements include screen overlays, dialog menus, dividers, drop-down or accordion menus, headers, sub-headers, input fields, date pickers, navigation bars, and more.

The first step in creating an estimate, therefore, is to fully analyze the application in terms it’s form and function, or in other words, it’s elements and features.


To identify the specific elements and features in the app, one could lay out every screen in no specific order, specifying the form and function of every part of each screen, but this would be a confusing and ineffective way to complete the task.

A much better way to complete the task is to show these elements and features in the context of use. To do this, we lay out what are called “Flows”.

Each flow represents the achievement of a goal by a user. “Deposit a check for $25 in the Debit account” is one example of a goal a user may set out to achieve. To achieve this goal, the user follows a series of steps through the app. These are laid out in the accompanying figure. The places where a user interacts with the app through screen taps is indicated by purple bulls-eyes.

Image of Mobile Check Deposit Flow
A “Flow” of screens through which the user moves as she deposits a check.

Now that the flow is laid out, I can analyze and communicate the elements and sub-features that compose the app and are evident in the screens. They’re all represented in the context of a process, further clarifying their function or relative use.

After analyzing the various flows I developed for the app and identifying the elements and features within them, I will next review them with a developer to create an estimate of their costs. Before I meet with the developer however, I want to be even more organized so I can clearly communicate these parts to him.


The next step I took was to organize these features and elements. With proper organization, it is much easier to communicate and handoff the app’s design and specifications to the developer. To organize the elements and features, I took screenshots of each of them and arranged them in a grid. I then gave each one its own identification code and title. Lastly, I added a description of the item to better specify its functionality.


Mobile Check Breakdown-53-53


Why should we spend so much work to communicate the design’s specifications? With this level of specificity, the developer is much more likely to create the app in the way the designer originally envisioned.

Without this specificity, a developer is more likely to not encode a particular functionality for the element, or she may come to a point where she has to come up with her own solution which likely is not the approach the designer had in mind. A developer may have good problem-solving, but this isn’t what they were hired to do in most cases.

For all these reasons, it’s important for the designer to develop materials to clearly specify the design’s form and functionality.

Link to Full Set of Flows and Elements

Developer Estimation

After developing the feature and element grid, I met with a developer to review the materials. I was fortunate that Andre Ortiz, an experienced designer/developer, volunteered an hour of his time to help me learn this process. We spent one hour together, analyzing the flows.

With each flow that we reviewed, we discussed the screens’ elements and functions. “What’s this button do right here?”, “Where does the list of accounts come from?”, “How do you expect the app to analyze a picture of a check to prove it’s real?”

These questions reveal many things. First of all, these questions facilitate the communication what the designer already has in mind for the app. Second of all, they reveal things the designer didn’t think of yet. Third of all, they reveal the perspective, knowledge, and mindset of the developer. The opportunity for such questions makes meeting and discussion much more fruitful than simply “handing off” specifications to a developer.

One example of something I had overlooked in the specification and design process was the behavior of the Account Summary screen as users scroll down it, opening accordion menus to view specific accounts and details within.


Image of Sticky Menus
The developer conversation yielded new ideas, such as the Sticky Menus feature.

Andre: “What happens when I scroll down here? What if I have five checking accounts? It’s going to get really long.”

Noah: “You’ll just open the accordion menus and have a long list. That’s it.”

Andre: “In the case that I have lots of accounts that extend beyond the top and bottom of the screen, what if the ‘Accounts Summary’ menu headers stick to the top of the screen as I scroll through the Accounts?”

This was a great idea. This conversation revealed something I hadn’t thought of. Now that we clarified that behavior, the app would be that much more easy to understand for users. In addition, this conversation revealed something about my developer’s knowledge and perspective. He practices a mix of design and development.

With this in mind, I know better understand his capacity for solving similar, unspecified design problems in the future. Conversely, I found that he did not have as in-depth an understanding yet of some banking app protocols. This meant that it would take longer for him to develop those portions of the app, in effect increasing the costliness of his services.

During the development estimation conversation, we pored over the flows in this way and he provided ballpark estimates of how long he thought each feature or flow would take to build. I kept a spreadsheet that tracked the estimates and discussion points supporting those estimates.

App Estimate Spreadsheet
A spreadsheet with specific feature and flow analysis helps keep tabs of estimated costs.

Link to App Development Estimate Spreadsheet

Estimation in Full

After the conversation, I added up the various estimates and found that the flows we covered would take roughly 915 hours to complete. This number included additional hours to “pad” the time, saving us both from the drama of broken promises and missed deadlines which could ruin a relationship and complicate other tasks dependent on the application’s completed stages.

Assuming I were to have two developers working forty hours per week, this work would be completed in approximately three months. How so fast? The truth is that I was ambitious in scoping out the full functionality of the application. Several parts of the app were not yet designed on paper, including the message center, transaction list and search, and customer service functions like replacing a card, managing travel plans, or disputing a transaction.

For the purpose of the exercise, I added all these items to my spreadsheet and used Andre’s estimates and justification to make my own estimates of how long these items would take to complete. The remaining features would take about 1,225 hours to complete, implying that the full development would take about 2,140 hours, or roughly seven months for two developers. This, according to Andre, sounded like a much more reasonable timeline to develop a full featured banking application.


The first big lesson I learned here is that it’s invaluable for designers to learn the end-to-end design process, including the development and shipping stages. In addition to simply knowing “about” the process, designers benefit from doing the process. Only in this way can we as designers learn the language, concerns, and perspectives of those individuals who are responsible for shipping the design.

By understanding their perspectives, it helps us work even better with those individuals. We’re a team, after all, developing products and services that are only truly valuable if they’re delivered properly. Even if the design was originally excellent, if it isn’t specified well, developers are disadvantaged in creating the product that was so rigorously user-tested, potentially leading to a substandard product.

The second key lesson I learned is that nothing beats a conversation. As specific as documented materials may be, a conversation provides the space and opportunity to ensure even more detail can be communicated or thought through regarding the product.

The last lesson I took away from this experience has been to “Know they Developer”. Before this exercise, I hadn’t had in-depth conversations with many developers about products. During the exercise, however, we met with multiple developers who had substantially different backgrounds, demeanors, and skill sets. One was more entrepreneurial, another was more focused on front-end design, and a third had much more knowledge about physical products than the first two. I could hire any of them to develop this app, but what else do I get other than the baseline coding skills? What if a problem comes up? What opportunities might they see?

It depends on more than their ability to use a specific coding language. In hiring a contractor or agency for a development project, it’s important to weigh what other strengths or gaps they may have. I would prefer to think of them as being a member of the team rather than a hired gun. Given my team’s strengths, what skills, other than coding skills, might the ideal contractor possess to create the best outcomes for our project?


The design hat is off. I’ve put down my Adobe Illustrator pen, for the most part, and I’ve picked up the spreadsheet and project manager tools. It’s been enlightening to look at the product from this perspective. Stay tuned in the coming weeks as we develop a product road map and even get deep into coding a slice of our product’s functionality.


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:

Here is my marked-up Check Balance Flow
Here is my marked-up Check Balance 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?

Bill Pay with and without chevron


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.

Check Balance Screen Original

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.

Forgot Password Screen

My original version of my “forgot password” flow – possibly not feasible from a security or legality standpoint.

Sandbox Issues

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.

Check Deposit Flow - Permission to use Camera
Asking permission to use the device’s camera

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.

Account Summary Button

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.

Next Steps

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.

From Wireframe to Market

Extracting and sizing feature specifications from a design with the help of a developer are critical aspects of product managers role. For the past two weeks, I have endeavored to evaluate feasibility and scope of a Bank of America mobile application that I redesigned in 2017.

I began by dusting off the wireframes and revisiting the flows to understand the bigger picture of what I am creating. I anticipated that I had 70% of the entire wireframes and felt that I had enough to consult a developer to begin the estimation phase. To prepare for the developer consultation, I worked to identify the significant flows, unique features, and components of the design.





I met with Andre Ortiz, an experienced designer of interfaces and experiences, for a development estimation session. An estimation session brings designers and developers together which gives a more thorough understanding the product, capabilities, and effort. Estimation will also ultimately provide insight to a broad range of stakeholders, such as marketers, sales, etc., who will need to know the features and delivery dates for a rollout, and also provides details about the costs and effort associated with a product, which will be of interest to finance and others.

The meeting with Andre was constructive and gave me insight into possible development effort. I also learned that I do not have all of the wireframes (even though I can still hear the refrain, “design every single screen,” from previous quarters). For the time being, I will use a placeholder of development hours and consult with others for the best way to handle. Even though I did not have all of the wireframes, it was a productive and valuable use of time.


From a product perspective, the most important thing I learned is that bank-to-bank transfers will require 20 hours of development per financial institution. There are approximately 6k FDIC-insured commercial banks in the USA which will need 120k hours. Further analysis will be necessary before determining an approach for bank-to-bank transfers. For example, perhaps we can plan to design for the ten most significant banks.

In total, currently, I estimate that it will take 128 days to develop the mobile application. In reality, I believe that it will take more time. I will confer with my design colleagues who also met with developers to estimate other banking apps.

Detailed estimate.

Sizing a Design

A couple of months ago I was working on redesigning the Wells Fargo banking app. I restructured it, simplified it, and created wire frames for all the essential flows a banking app should include (in my opinion), as well as some additional capability that Wells Fargo currently doesn’t offer.

Now it’s time to talk to a developer and size the design.

Sizing is the process of understanding how long it will take to build out different components and features of the app. A component would be something like a dynamic list, such as this transactions list below:

Checking Account - 1 – 2@3x


A feature would be what that dynamic list does. In this case, the transactions list populates and displays the latest transactions from a designated account. For each screen created, I marked the component, gave it a name, and described the feature below the component name.

Artboard 1@72x-100

When I met with a developer to discuss the design I printed out all of the screens and taped them down onto big sheets of brown paper. This way we could write on them and look at them all at a glance. I put a small pink sticky note next to each component and a small blue one described the feature.


Mark, the developer, made his estimations according to flows. He thinks in days and carefully nodded along as I walked him through each screen. We marked up how long things would take on orange stickies along with new things to think about for different components.


Mark was great, and I had been particularly interested to learn what it’s like to work with a developer. He pointed out several holes in my design, things that hadn’t been thought through. I knew he was going to try and do this. In fact, right before I went to meet with him, I threw together some quick ‘error state’ screens, and patted myself on the back for being well prepared.

dropped connection@3x

“But what if they lose connection in the middle of a transaction? If they just refresh, will it send the transaction twice?” Mark asked. Clearly it wasn’t his first time thinking through these things, and it was enormously helpful to hear his insights.

From Mark, I also learned how much I didn’t understand about how certain systems work. Like how when adding a new bank account that’s outside the system, I had set the system up to search by name of the financial institution. But really we just need the routing number and account number to confirm the account.

Perhaps most importantly, he got me thinking about how using similar conventions and components that repeat throughout the system save the developer a lot of time. I noticed I often changed things later on as I designed, and didn’t go back to make sure I was utilizing the same conventions. It got me thinking about how I was not only giving more work to a developer, but I was also making the user’s experience more confusing and less cohesive.

The screen on the left was designed earlier on and the screen on the right was made several weeks later

The next step in sizing is to document all the components in a spread sheet and list how long it will take to build each part out. I did this in two ways. First I created a sheet with columns for the types of components that could be found.

Screen Shot 2018-03-18 at 10.33.39 PM

Then, on a separate sheet I listed all the flows and put all of the components into each flow along with their feature, and screen. Here is where I listed how long each flow would take, and I added comments from my discussion with Mark on certain components.

Screen Shot 2018-03-18 at 10.49.18 PM

Over all, he estimated that it will take about 93 days, or 4.5 months to build everything out. If there were two developers working full time on this project, I could have this version of the app done in 2.5 months. This seems really quick!

But how do we know this estimation is correct? Sizing estimation (so I’ve been told) is extremely inaccurate. However it’s good to get some type of scope for what it would take to build something.

Communication and The Process of Shipping Products

Shipping My Banking Application
I have returned to my Randolph Brooks Wireframes for the first assignment in our Product Management class of Q4. The class teaches us the fundamental methods of product management and what it takes to understand the scope of big workings like taking a product from wireframe to market. It’s a big step taking our flows that we created in Rapid Ideation and Creative Problem Solving during Q2, and create component sheets and estimations to know how and what is needed to ship all the features and components within the application. 
This week our task was to set up a meeting with a developer and discuss our flows in depth to see how long it would take to ship the components and features we created in our wireframes. I met with Chap Ambrose: a former alumni and our Q1 Studio professor. It was a great experience to talk with Chap about the app and get a little more understanding about the complexities that  are involved in developing a mobile application. After our meeting I took my flows and the estimation that Chap provided me and created several deliverables that I will be presenting in an informal walk-the-wall presentation to my classmates and professor, Ruby Ku. The deliverables I created include all of my flows for the app that I have completed so far, the individual components and features that Chap and I discussed and estimated time for completion, and a spreadsheet of each component labeled with notes from my discussion with Chap. 
Meeting With Chap
I met with Chap, the developer, last Wednesday for about an hour. In our meet we discussed the wireframes I presented and the key components and features needed to perform a “hero flow.” Chap advised that we should create a “Hybrid HTML app” instead of using an API (Application Programming Interface) because it was much faster and because of the nature of this app using API wasn’t really needed. To my knowledge, the reasoning Chap suggested this is that just developing the app via HTML/CSS/Javascript is sufficient unless you are developing an application that requires a lot of processing power. If not, then you can just develop it like you would a website and just make it function the way a mobile application does. Now, I’m no developer so I may have gotten that wrong, and Chap, if you’re reading this, hopefully I didn’t butcher your words. 
The big takeaways that I got from our conversation were that I should use Android’s Material Design UI and I learned the value co-designing with developers. Using Design Principles from Android’s Material Design makes creating the app a lot simpler and easier to ship. The reason being is that I created my app to reduce the amount of clicks for navigation as much as possible, and after looking over the Android development page I found that all my features and components except only a few can be swapped with Androids UI designs. 
My second big takeaway from my conversation with Chap was that co-designing the app with a developer is the best case scenario to shoot for when I get into a designer role after school. I learned how valuable that connection and communication is between a developer and a designer, and I can see how if have a great connection you are able to create things faster, more efficiently, and ship better products. 
We ended up saying that in total, from what I had in wireframes at this point, it would take him around 135 days to ship the app. I felt like this was a reasonable number given the complexities of some of my features. I learned that I need to think about things like, “What happens if there’s an error?” “How many items should appear in lists?” “How do I want my numbers to populate?” I learned that reusable components can be a powerful thing for shipping products more quickly and even in usability testing with users, because the more times a user encounters a component the more they can navigate using prior experience rather than trial and error. 
Identifying Components
I created six wireframe hero flows that present most of the key features and components of the app. The Assignment instructed us to also Identify unique features; give them names and label them.You can view each identified component in the image below. The components identified in these images are the core features that Chap gave me estimations for shipping. Components like “Back Arrows” and “Radio Boxes” have been excluded from these sheets simply because in the hour that we had for discussion we wanted to get estimation on the more complex components. For smaller components such as these I need to have another conversation with Chap to see how much longer it will take to ship the app in its entirety including these components.
Assuming this was a real product and I was actually going to created this app I would want to set up times for Chap and I to go over these smaller components and  overall the function of the app. Since the complete flows for the app have not yet been created I feel that co-designing with him would be a way to test and iterate in real time to provide a back and forth with him that would really bring out the most creative end result. It would also hold Chap and myself accountable for time and efficiency because we’d have weekly meetups to discuss features.
Flows and Components-27 Flows and Components-28 Flows and Components-29 Flows and Components-30 Flows and Components-31 Flows and Components-32 Flows and Components-33 Flows and Components-34 Flows and Components-35 Flows and Components-36 Flows and Components-37 Flows and Components-38 Flows and Components-39
Overall I am happy with this experience. I feel like I learned a great deal and I have a greater respect for the communication between developers and designers. I had the insight during this assignment that I should not spend a lot of time trying to learn code, and instead spend that time with developers learning how to speak with them about developing and design. I am not opposed to learning some developing skills down the line, but I feel that the most important thing in being designer is that I am able to communicate with developer so we both end up getting what we want out of the experience. I am excited going forward and this assignment has given me more confidence in my abilities to lead teams and learn from my peers. 

Wireframe Hero Flows

Spending Health Analysis
Flows and Components-13 Flows and Components-14 Flows and Components-15
Login (First time User)
 Flows and Components-04 Flows and Components-05 Flows and Components-06
Login With Touch ID
Flows and Components-07
Deposit: Depositing A Check
Flows and Components-08 Flows and Components-09 Flows and Components-10 Flows and Components-11 Flows and Components-12
Bill Pay: Schedule a Payment
Flows and Components-16
Flows and Components-17 Flows and Components-18 Flows and Components-19 Flows and Components-20
Alerts: Updating ATM withdrawal amount and notification settings
Flows and Components-21 Flows and Components-22 Flows and Components-23
Transaction Analysis
Flows and Components-25 Flows and Components-26
 Component Spreadsheet

The first step to ship my TD Mobile Banking App Re-design: sizing

This quarter, I am returning to my redesign of the TD banking application for my product management course. In this course, we are shifting from user-centered designer to product manager. We will ask ourselves what it will take to actually build this product, how do we communicate with developers to determine cost and length of time, and then, eventually develop a roadmap to an MVP. In this blogpost, I am going to discuss my process to size the banking application. This means, I will break down the banking app into unique features, components and controls (to be discussed below) in order to have a discussion with a developer to determine how long the product will take to make. More generally, I am now focused on how to ship my product (now that I’ve determine what I should make).

This blogpost will include:

  • Identifying unique features, components, and controls
  • Documenting the system
  • Sizing
  • What I Learned

    Identifying unique features, components, and controls

My first step in determining what it will take to ship my product will be to move from the ‘blue sky’ thinking of design to the grounded land of ‘constraints’. I have heard from many designers that conversations with developers is often a ‘downer’ as they say give their perspective on what’s possible given budget and time constraints. Of course, every developer is going to provide a best guess (which will be wildly inaccurate) but will at least give an approximation to work from. In order to prepare myself for this conversation, I had to re-analyze my system using a new framework: where are there unique features, controls and components in order to help develop a way to describe everything to an engineer as well as look for opportunities for efficiency.

To do this, I first posted up all my flows so I could get a zoomed out perspective of the entire application. I then searched for all of the features (green stickies). This was challenging since I didn’t have a strict definition of a feature. I spoke with several mentors and tried to ad-hoc synthesize what I learned. I decided that features are well-defined features in which users accomplish whole or partial tasks. For example, when a user is within the Transfer money flow, they add an external account. At this point, I assumed that this was a feature.

Posting up the flows

Then, I scanned my system for unique components and controls. These are elements users interact with in order to accomplish a task. The challenge for this was to find all of the industry standard terminology for each component or control. I learned that some of the ones I made in my application were not actually standard.

Documenting the system

After I finished identifying the unique features, components and controls, I zoomed back into the details of my system. This involved removing all of the elements I highlighted in green and orange from their context so that I could record a description of each in terms of the information they include, where the information comes from, as well as how it fits into the larger system. This process helped me to think about my banking application from a new perspective. I had to ask myself how a developer might see think about element. The record I am including below represents my best guess the entire inventory of unique features in my application. After I met with a developer, I learned that in some cases I did not include a feature I should have or that there were sub-features within a feature I had already named. For example, in I discovered that in general, any form had to interact with APIs outside of my system. I did not realize that before.

System documentation 6 System documentation 5 System documentation 4 System documentation 3 System documentation 2 System documentation 1

Transfer 1 Transfer 2 Transfer 3 safe to spend 8 safe to spend 7 safe to spend 6 safe to spend 5 safe to spend 4 safe to spend 3 safe to spend 2 Safe to spend 1 settings Quick Pay 3 Quick Pay 2 Quick Pay 1 Deposit check Alerts:Notifcations 2 Alerts Notifications 1 Check balance Edit Bill Error Login


The final step in this process was to meet with a developer. This was an opportunity for me to learn what goes on in the ‘black box’ – or the system behind my wireframes. As I build my design, I knew was either ignorant of typical bank application features or made many assumptions when I built the safe to spend feature.

Turns out I was right on both accounts.

During my meeting, I learned a lot about how simple flows that I assumed were old hat by now like authentication was actually quite complex. It took way longer (80 hours) than I thought it would. This is often how it went as I showed the developer all of my flows. He also exposed me to some important vocabulary. For example, my interaction with the developer pushed me to begin trying to understand APIs a lot more. My goal will be to be able to explain what an API is to the class at some point (hopefully as we present tonight).

In total, my banking application will take 218 days in total to build. Of course, this estimation is wildly inaccurate. The developer repeatedly told me he was padding his time because he did not know what variables would come up. He constantly talked about how risky many of the features would be and that he could not predict all the ways it could go wrong. Below is a detailed list of how long each flow will take as well as particular notes on different features. Below that, I have included all of my flows.

Sizing Documentation – Sheet1

What I Learned

I have been reflecting on this experience so that I can take away meaningful insights. First it was a challenge to be able to even determine how to describe my banking application not from the perspective of a user-directed flow. But, after working through this process, I have begun to form some theory.

First, I believe that features are made up of forms and controls, as displayed in the concept map below.

digital elements

Second, forms and components interact with humans and features interact with data. Both combine to accomplish flow tasks. The concept map below illustrates this concept.

Nested features

Third, my banking application is a series of nested features and it is my goal to be able to explain it on all levels. When speaking with my developer, I need to know all of the features as well as the nested features that can be reused over and over again. Below is a concept map that illustrates nested features following the transfer flow I spoke about above.


Masquerading as a Social Entreprenuer

What If I Cave?

 The most provocative that the readings brought up in my mind was this idea that Jessi Hempel mentioned in her article. She writes, “The only thing worse than not asking the questions, is not paying attention to the answers that don’t fit into their world view, because it’s inconvenient.”
The overall message in Hedel’s article in my mind is that when designers go out looking for solution to a problem that we define, we will usually find it. The issue here is that, without taking the time to understand the people, scope, and context of the system, we may end up focusing on the wrong thing. Therefore the solution, while it may work for that particular problem, won’t actually provide any usefulness to the target users. People and businesses often miss this because it becomes inconvenient to their current strategy.
This really hit home for me. It’s been a big fear that when I go out into the workforce, unsure of my ethics and my design theory, and I’ll end up just caving to business theory or side with how other designers view the world. I want to have the moral backbone to stick up for my own values and the ways I’ve been taught in AC4D about how to create thoughtful and usable design. 
AC4D has presented opportunities to me as a student that might be contrary to points articulated in the readings. Like, for example, the articles that talk about design competitions and hackathons. The point that Joyojeet Pal makes is that hackathons or design-for-good competitions aren’t doing near what they are trying because they set out to reach these blue sky ideas without considering how this thing could become a reality or really whether it is even useful. In fact, the result of these events favors us designers rather than the people it’s supposably for and by attending programs like AC4D or competitions like IxDA we get that sense of selfish altruism and practice at doing these type of projects. In a way it’s dishonest of us to masquerade as designers that practice social entrepreneurship and design for social good when, the minute we that we are out of here, we will pick the role that provides the top dollar. 

Scaling As A Designer

 I feel like new designers have so much pressure to do well quickly then it’s harder for us to choose what direct we want to go right now. Then once we get good enough to actually pave our own path we have gone too deep into agency work or consulting and our lives force us to stick to a paycheck. 
It’s just like the Red Cross vs. New Home. New Home, because they were a startup company, was able to focus more on design research methods like participatory design that enabled them to create more empathetic and tailored products to their users. Red Cross, while they tried to helped, their methods failed because the problem required a more focused method approach that they couldn’t provide at the level they were at. 
When you’re just starting out it’s easier to focus on the empathy and the individual, but scaling your design is another trick. Then once you get to the level of Red Cross you can’t do the same type of design because it doesn’t work that way. The Red Cross failed because with the thousands of things they do daily it is hard to really narrow in their focus to give the detail needed to thoughtful design.
I compare this to being a senior designer at a company like Frog or even Goodpatch. Chelsea, when she came to speak, mentioned in passing that 60% of their work is presentations and only 40% is actual design work. It’s not that this is inherently bad but, just like Red Cross finds it difficult to be effective at their scale, I feel like it would be hard to solve these wicked problem at that level. 

I Guess We’ll See

The problem that scares me is that I am one of the designers we read about in Theory class. I can see myself being the type of designer that graduates and goes straight for the money, even though I know that I find working on these issues more fulfilling. I know long term I would want to make the monetary sacrifice, but I haven’t been one to have great foresight. I guess we will see in April.