A New Perspective: Understanding the Developer Approach

Introduction

Over the last two months, I’ve been working to create wireframes for a mobile banking app. Focused first on basic flows crucial to the core of a banking app and then adding on more in-depth features including budgeting tools. While creating these, I’ve put the designs out into the world of users and received feedback, which was then implemented to make the design better for our users.

Moving into the Product Management phase, however, meant a slight shift in design focus. Instead of being solely focused on designs that were great for the users, I now I had to make sure these designs were within our budget for development. To do this, I was paired with a developer to understand product sizing and evaluation. Sure, I know how long it would take me to mock up something in Sketch or XD, but I had no idea how long something would take to be coded and launched.

The Value of Meeting with a Developer

Meeting with developers is a crucial part of getting any digital design launched and the better communication you have with the developer the smoother the launching will go. I scheduled a meeting with Mark Phillip and began to prepare my wireframes for the meeting.

Meeting Preparation

Prior to meeting with Mark, I went back to my wireframes and made sure that I had updated my flows based on the last round of user feedback. Additionally, I decided to try out redlining my screens. As seen below, I first went through and redlined all of my features (as seen in Fig 1-2 below). I boxed them in red and wrote a brief explanation about what they were and how they functioned. After that, I went back through all the frames and outlined all of the controls and components and described how each of those functioned (see Fig 3-4). Lastly, I pulled all of the controls and key components out of the context of the wireframes and described their behavior individually (see Fig 5-6).

Fig 1. Redlining Features
Fig 1. Redlining Features – Home Screen

 

Fig 1 Relining Features
Fig 2. Relining Features – Account Balances

 

One thing that I would’ve done differently here, is talked to my developer prior to our meeting and asked for clarification around what exactly would help him best in the meeting to grasp the wireframes. If I had done that, I would’ve learned that he did not need to see the controls and components redlined (like in Fig 3-4), which would’ve saved me a lot of time. But he did like to see the components and controls taken out of the context of the wireframe and annotated (as seen in Fig 5-6).

Fig 3. Redlining Controls - Home Screen
Fig 3. Redlining Controls – Home Screen

 

Fig 4. Redlining Controls - Account Balances
Fig 4. Redlining Controls – Account Balances

 

Fig 5. Component and Control Breakdown
Fig 5. Component and Control Breakdown

 

Fig 6. Component and Control Breakdown pt2
Fig 6. Component and Control Breakdown pt2

Lastly, I ended up printing all of my redlined wireframes out and bringing them to the meeting. It was a lot of paper, but being able to make notes, redraw, and scratch things out right on the design quickly helped out meeting go smoothly.

To see the full redlined wireframes click on the links below:

Features

Controls

Controls Breakdown

During the Meeting

Mark was friendly and warm and understood well what were trying to accomplish in our meeting. We went through the wireframes by flow and discussed them screen by screen using the redlining Features section I had prepared.

As we went through, it was clear that he quickly grasped what the flows were and how the features and controls functioned. He asked questions when he needed it and the discussion illustrated a couple areas where I could add screens or move things around for clarity of flow.

During the meeting, he gave me an overall estimate for each flow and then I would prod him with questions regarding particular features or what he was thinking. I asked a lot of questions like “How did you get to the estimation? Could you break the timeline down for me?” and “What feature do you think would take the longest? Or how could we save some time or make this flow leaner?” He took all my questions in stride and offered explanations for which features he thought would take him the longest to build and we brainstormed some alternatives.

For example, one of my flows included a long form to manually add a payee for bill payment. I had designed it so that when a user finished page one they would then go on to page two, but Mark pointed out that would be extra time and that a scrolling form would shorter the development time.

Fig 7. Pay Bills Flow includes form for manually adding new payee. It includes two separate pages, but could just be a scrollable form.
Fig 7. Pay Bills Flow includes form for manually adding new payee. It includes two separate pages, but could just be a scrollable form.

 

At the end of the meeting, I inquired about what he normally likes to see in these types of meetings. He told me that a basic concept map of the architecture of the app would be helpful to understand how the pieces fit together and give him and overview so he can better understand where he is in the app as we go through wireframes.

Overall the meeting gave me a more holistic understanding of all the ways a project can be viewed. The majority of the meeting was me trying to understand how the developer is going to attack a problem and the developer trying to understand why we chose to design things the way we did. This understanding of the two sides is a crucial piece to implementing a cohesive product within budget that works for users.

After the Meeting

Upon returning from the meeting with the developer, I documented my learnings. I created and excel sheet breakdown of all the estimations that Mark gave me. I made sure to include notes on the features that would take the longest and why, so I can prioritize later about what should be included in our v1 of the app.

Walking away from the meeting, I have a new understanding of how developers approach a problem or a build and I have better grasp on how I can communicate and how I can prepare to get the most out of those interactions. My main takeaway from Mark was that the more that I, as a designer, can illustrate and articulate how something functions and why we chose that function, the easier it is going to be for the developer to understand the scope of work and give an accurate estimate. As Mark put it, “If I’m confused or scared by something or I’m not sure how it works, I’m going to give you a less accurate estimate because I want to make sure I have enough time to figure it out.”

The Estimation Results

Developer estimation for each flow
Fig 8. Developer estimation for each flow.

Detailed estimation can be found here.

To Consider Moving Forward

Several items within my app are time consuming for the developers and should be carefully considered moving forward. For instance, I had included a Recurring Payment option in my Bill Pay flow. It’s the ability to automatically pay a particular bill at recurring times in the future, basically scheduling them out at particular intervals. This was problematic for the developer because of the amount of variables included, like daily, weekly, monthly payment options.

Fig 9. Pay Bill with recurring payment feature offered. A potentially costly addition.
Fig 9. Pay Bill with recurring payment feature offered. A potentially costly addition.

 

Another feature to change in my wireframes is the numeric keypad. I need to a little digging to find a standard Andriod numeric keypad for the wireframes. From working with the developer, I learned that many standard features are much faster for them to include because the developer that copy the code for standard features instead of building a new keypad from scratch. This should be a relatively easy fix on my end that will allow the developer to work much quicker down the line.

Fig 10. Nonstandard Numeric Keypad will take much longer for developer to build instead of just including a standard Android keypad.
Fig 10. Nonstandard Numeric Keypad will take much longer for developer to build instead of just including a standard Android keypad.

Lastly, including all of the interstitial states that I had included for my users were completely unnecessary for the developer to see. Next time, I would only include enough so they understand the function and not every single screen for interstitial states.

Fig 11. Interstitial states were not necessary to show in developer meeting.
Fig 11. Interstitial states were not necessary to show in developer meeting.

 

Communication is key to these meetings. That includes preparing with redlining features, printing wireframes, or chatting with your developer prior to meeting to understand what would be best for them. It includes asking questions and having answers to developer’s questions during the meeting. And it includes documenting communications after the meeting and following up with the developer as the project progresses.