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 thy 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.