Learning from Conversations with a Developer

A few months ago, I had built out an interactive wireframe of a bank app for the purpose of user testing.  Over the last two weeks, I was tasked with taking that design and size the feature.

All the Hurdles.

#1. Foundational Hurdles. The biggest initial challenge was to build out the remaining flows that I did not get the time to build. That is four out of a total of six flows. Additionally, I still needed to figure out how to make the app usable. These were very intimidating tasks because I hadn’t cracked the code on how to build wireframes quickly, how to map the user flows in a way that is smooth and achieve a clear goal, and going pedal to the metal was not an option as time is not a luxury at AC4D.

#2. First Meeting with a Developer. I was also to show my wireframes of the bank app to Eric Webb, a developer who has volunteered his time to help AC4D designers in training how to size and estimate the app’s features. Can’t do this if there isn’t much to show.

#3. Time. I need to do all of that as well as identify the key features, estimate the time it would take to develop the feature after a conversation with Eric, the developer.

I’ll be sharing with you how I overcame the hurdles and my journey in over the last two weeks.

 

The Process

Step 1. Meet with A Developer. Recognizing that I still had some wireframes to critique, I decided to meet with Eric earlier rather than later to get some feedback and suggestions on the existing mock-ups and understand what to consider from a product engineer’s perspective. As creativity does not happen in a silo, and developers also build things with users in mind, this conversation did provide a richer understanding of how to design for a user.

2. Complete more of the wireframe. Based on feedback from Eric, and hearing him talk through how he would implement parts of my design, and talk through what some parts of the design seemed unnecessary, I took some key takeaways with me as I rebuilt the existing parts of my app, and built out the remainder flows. Compared to 2 flows with repearted screens over the course 45+hours, I was able to build out unique, 28 key app screens that had a clear visual hierarchy, in less than 20 hours.

3. Second Meeting with a Developer. This is what I will be doing next. I will print out my screens and annotate (also called redlining) the components of each app screen as a developer helps estimate how long the app will take, and about how much it will cost to build the app.

Key Takeaways

While I did not get to a place with estimation, working with Eric and discussing the natural flow of an app and how users typically interact with apps was super helpful. Here are some key takeaways that I will actively include in my process in the future.  When designing keep the following in mind.

Use Existing Element over Custom Element.

Custom controls and UI take more time, to design, to build, test, and (for iOS apps) it may take longer to approved by Apple as you maybe not following their style guide properly. Making custom components for the sake of delightfulness comes at a high cost, literally.  Custom elements are best reserved for making the user experience & business interaction move valuable, efficient, and pleasing.

The result of this is more consistency in what you built, it’s faster to reuse existing components in design as well as in development, and the app is less brittle. When something breaks it is faster to identify and fix that single component that exists in several places.

The components of your app will have a pattern, which decreases the user’s learning curve as they interact with the app, and navigation become more intuitive for less tech-savvy users.

The components of your app will have a pattern.

Have Clear Defined Goal

Have a clear single defined goal for the app as well as for each flow. Without this, is it very hard to decide what elements, details, and information to include, let along how to outline the flow.  Knowing those things makes it infinitely easier to be decisive on where to place certain navigations, how to build a clear hierarchy, and you move faster.

Before_No Clear Goal After_Clear Goal

 

Consider Typical User Behavior 

When Eric asked me “When was the last time you logged out of an app?”  I, like many, couldn’t remember when I last did that on a browser or app. So, it was clear to me that keeping a Log Out link would be a waste of valuable phone real estate. I started paying more attention to how I bank and took a closer look at the things in the apps I’ve used that I never noticed before. All of the links I never touch in an app made it on a list of low priority elements that I will use to survey my peers and people I interact with daily. Some things that make it onto the list when it comes to my banking apps are: find a bank location, help, privacy policy, legal policy, terms & conditions, statements, setting a language preference, login information, notifications, alerts, bill pay.  As a result, I opted for moving the Log Out link into a hamburger menu.

Be Prepared, and Ready to Trim Ideas

After hearing from my classmates, when I meet with a developer to gauge feature estimates, I will be prepared by having the ideal state of the app screens printed to share and to make note of critiques on, be ready to explain why I made design choice I over other options, have all my feature named and listed, be ready to ask for alternative options and to ask lots of questions. I did not do a very good job asking questions about trade-off such as loading time (which impacts the user’s experience), and security features.

 

Mock Up Screens

Here are the flows I’ve created and will be used for estimations.

Onboarding

Onboarding_1

Onboarding_2

 

Accounts. Users can monitor their account.

Accounts

Deposit.

Deposit

Transfer Money. Users can transfer money between your accounts or to an external account.

Transfer

 Pay A Bill.

Bill Pay