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