Crafting a Roadmap from Wireframes
A week and a half ago I had shared my journey and lessons learned after I took my redesigned mobile banking app to a mobile app developer for feedback. I walked away taking many of his design advice that would help achieve a more seamless interaction with the app as a user goes to the app to monitor and interact with their bank accounts. One example of a more seamless experience was the removal of the continue button on a deposit screen, instead, the updated design would automatically recognize them with insight and
This past week I was tasked with taking my bank app and plan for its development with some real work constraints. The challenge was to plan out this app’s development over time with only 2 developers working full time for one week. This put me at an 80-hour development budget.
Once this constraint was introduced I quickly had to consider the following, how many features of this design group in a way to make a complete app and still NOT go over my 80-hours of the development budget.
User Value vs Resource Constrained Decisions and Prioritization
Tradeoffs. With the user’s experience and value in mind, it was very easy to treat interactions like magic. You just say what happens to the screen to make a user automatically be taking to the next screen, i.e. when the deposit form fields are all filled out, the user automatically taken to the verification page. While the experience can feel magical, software development does not. This fluid transition came at the cost of more development time, and code to account for when a user wanted to go back to the deposit form to make an edit, but their form is completed. In this example, I had to work with the developer to define a task to add a flag to the account of the edit scenario. Here is the tradeoff I discovered.
The more delightful and fluid user experiences that are included in the design, the more you add to the cost of development.
The reverse is true as well. When I had to consider which 80-hours work of features make up the core values and functionality to make a complete experience. With constrained resources as a focus, some of the screens on my design flow had to be traded out for less magical user experience for the sake of delivering complete user experience. To be able to navigate this some assumptions and decisions had to be made.
Sprints. Sets of features are built over time at a human pace and a single feature does not make a complete and functional app. In order to deliver a complete and functional thins features are groups and built and delivered in a sprint.
Release & Milestone. The set of features if a sprint, once complete and shipped, it is released to its audience for use. Each release represents small leaps of improvements in the app. I also made the decision to align each sprint with a sprint goal that will be built towards the app’s overall goal for the user. For example, the app’s overall goal is to make it easy for users to monitor and interact with their bank. I made my first sprint goal be: to build the foundational feature for a user to access the app, and be able to monitor their accounts and a small part of banking.
Prioritizing is a craft, not a science. This process has been invaluable in helping me develop and refine my prioritization skills. To prioritize, I needed to be able to justify the value of one feature over another, but no two features are the same, as it should be. I relied on my app goal, and assumptions made from my understanding of bank app users, as well as my early user research. I outlined Guiding Principles to reference early to make sure that my decisions are consistent and complement each decision before and after it. This would help the series of sprints and releases be coherent.
- Always ask:
- Does this feature better than the user’s current banking solution (i.e. going into the bank)?
- Is there a simpler faster way to get the same results?
- Which features best achieve the app goal?
- App Goal to be broken into phases (aka sprints): For a user to be able to monitor and interact with their bank.
- A newly implemented feature should be complete in its core function and user a purpose for the user.
- Not all parts of a feature need to be implemented at the same time.
- If a part of a feature needs to be included I need to consider deprioritizing less important features OR implements a simpler version of the feature that still achieves the same functionality of the original feature.
From these guidelines and my references (user research, other developer and designer’s knowledge and experience, existing application’s implementation) I made the following assumptions:
- physically going to the bank is not desirable because it interrupts a person’s day and routine.
- features that make sense to have but are not historically a habit/thing that users use should be de-prioritized or removed. (i.e. users do not have the habit of signing out, there for signing out does not need to be the first thing that users see on a screen)
- when I am unsure of what typical user behavior or interactions look like, I can always reference existing popular applications to inform what typical user behavior looks like.
Now that I have guiding principles, defined constraints, and resource to help my decision making, building a roadmap because more like a putting together a puzzle.
I took to google spreadsheets to organize all my features, their details and their estimated hours to build. I then created columns to assign them a sprint number (which will help decide which features to build get built in the 1st, 2nd, 3rd and so on sprints) and an owner. With the constraint that a single person can do at most 40 hours of development a week, I was better able to define which features go into which sprint. For example, I would start by selecting two or three features that make a complete experience. This is how that list of features shaped out.
An example of the thought process behind building a sprint. For the first sprint, I identified that a user should be able to, sign in, reset their password, view their account overview and deposit a check. The reasons behind that were that in banking users need to authenticate their identity and that. Working in tech, I’ve known for users to have ongoing troubles with remembering their password, so signing and resetting passwords have to be shipped together. The ability to monitor one account was the primary goal of the app. After adding all of these features and adding up their estimated outs I had some room to add another feature. I decided to go with being able to deposit a check because the alternative for a user to have to take time from their day to go to the bank. The app will not make depositing without having to go somewhere else san option and clear value add for users that chill received checks for forms of payments. This includes business and people who work for small businesses that pay in check. I made the assumption that there are plenty of people that still go to the bank to deposit their check, otherwise why else would teller counters and bank brick and mortars exist?
This first sprint put me just over 80 hours, reviewed each aspect of the selected feature to reexamine which part can be reduced. Resetting password seemed like the easiest place to start because I knew that the bank that I originally made this redesign for has a working website that supports password reset. So I consulted the developer to figure out of it was feasible to have a screen within the app to point to that web page, and if that solution for password reset would take less time then the original estimate. The new solution worked out to take less time so I took the original design idea out of the sprint and replaced it with this new design idea.
I continued this exercise for the remaining features and would use a release goal (or theme) to makes sure that each release provided a coherent and complementary set of values. This would make the brand of the app seem less disjointed for users who are actively using the app. These were the resulting goals.
The resulting roadmaps looked like this.
Modified screens. After organizing the features into a sprint in a manner that fits the guiding principle, I had to go back and modify the wireframes of the bank app so make sure that the app doesn’t look like features and parts of features were hobbles together. One example was the navigation menu. The original navigation menu accounted for all five banking features the app offered. With the first sprint, only two features were being built (Accounts Overview and Deposit). As a result, I had to go back to clean up the navigation menu for the first iteration of the app, then added tasks to the roadmap for later menu updates as more features get built out.
I continued through the rest of the apps to make similar modifications to account for varying iterations.
Making and Sharing Wireframes Per Sprint
As a means to communicate to developers the current vision, and how it is different from the final version of the bank app, I pulled out the screens per sprint and compiled it into a format that easily shared with developers. For this activity, I have the formats of a .sketch file (where each set of screens in the same sprint is on its own page), .png file, and .pdf. The point was so that developers don’t confuse the temporary modifications to a component with the intended final version of the same component. Below are some samples from the feature in the first sprint.
Focus and tradeoffs. Designing an app have a very different focus and purpose than when it comes to building and implementing the design. I had mentioned earlier that there is a tradeoff in the difference in these roles where design’s user experience focused can easily add more bulk in development time, and product management and development’s perspective of contained resources will prioritize the feasibility and completeness or a design idea over the user’s experience. Alone each focus can result in an excessively delightful app without purpose or a very practical app that may not be as seamless. But when both focuses are in balance with each other, the results can be a very functional, concise and still user-friendly product.
Breaking features down into its smallest possible unit is the tool for flexibility. Organizing the operations and logistics of building a product is a craft. Even with estimations per feature, I often found myself either coming in under or over the budgeted hours of development per sprint. In the real world, these estimations are exactly that, just estimations. I was only when I would break down the features into individual capabilities with smaller estimates that I was able to more easily move feature around. What I also found was that the more granular I was able to describe a feature and reconnect that granularity to other parts of the app it can or does impact, the better the developer was able to give me a confident smaller estimation.
Communication is key. To be able to bring together all the people involved in building an app, and to strike a balance between delightful design and practical implementation communication is KEY! Everyone I consulted in this project had a better-reasoned solution or offered an alternative option that would take less time to build.