US Bank Mobile Banking App Redesign: Development Resource Planning

We have been redesigning mobile banking apps, and so far, it’s been all about the user:

  • What are the user’s goals?
  • Can users accomplish their goals?
  • How can we make the design even better?

Now, it’s time to look at what we’ve got and figure out how to get it into the app store. That means code. That means working with developers. That means pragmatic planning.

To begin, we scheduled a meeting with a developer to review the app’s functionality in its entirety, identifying the app’s features, components, and controls over the course of the meeting. To ensure we were on the same page, this meant literally pointing to wireframes and labeling the components.

2016-02-01 13.19.10

Along the way, the developer was able to react to the elements onscreen with respect to their perceived complexity (based on his knowledge and experience with the development of other mobile apps). There were a few suggestions made to use alternate controls which could reduce some of the development effort required. However, most of these were relatively minor gains in reduced dev time when compared to the impact on consistency and clarity for the user. For example, instead of customizing a table view with additional logic to mimic the functionality of radio buttons (as in screen 4.3 in the image above), the developer suggested simply using radio buttons. However, he also acknowledged the sacrifice in visual consistency that would entail.

After getting through the entire app, we then listed out features and applied estimates for the number of days it would take the developer to complete each one. Here are the final results of the developer’s estimates:

Screen Shot 2016-02-01 at 3.48.39 PM

For a more detailed breakdown of features, components, and controls throughout the app, here is the full PDF:
USBank_Wireframes_Kade_FeaturesComponentsControls_r6.pdf

You can see that the development of the user interface elements does take up the largest portion of the estimated time, especially when accounting for styling near the end. However, there is a back-end portion of the logic that turned out to be surprisingly tricky to build: recurring transaction frequency estimated at 8 days. That turns out to be 18.6% of the development cost.

Because the design calls for the ability of the user to enter in any custom frequency for a recurring transaction, there are numerous edge cases that must be accounted for. For example, say the user wants a transaction to recur every fourth month on the 31st. First, “every fourth month” is not a common frequency and so would have to be entered using a “Custom” option, as in the following image:

Screen Shot 2016-02-01 at 3.58.20 PM

Additionally, there are many months which do not have 31 days. Also, the 31st day of the month may not fall on a weekday… and so on. Just ensuring that the user is confident that they are able to achieve the desired result is difficult enough. Building in all the edge cases in the logic may be even harder.

As is not commonly the case, the estimates came in well below expectations, even accounting for the difficulty of handling the recurring transaction logic. There will be no changes to the scope of the project. However, we will next be looking at creating a roadmap to determine which portions of the app can be released sooner than others. This will result in a phased development approach that I’ll be outlining in my next post for the project.