We’ve been repeatedly challenged to learn this rule at AC4D: The quickest way to understand whether your concept works is to show it to someone else. This week, our challenge was to show our Q3 banking app wireframes to a working developer, work through their questions and responses (and rejections!), and get an estimate of workdays needed to make and ship our app concept.
While I still have a lot to learn about shipping a product from concept to market (that’s what the rest of this Product Management class is for!), our 1-hour meetings with a developer were grounding, humbling, and exciting all at once. Here’s a few things I learned from my first real-world meeting with a third-party developer:
Get Your Shit in Order.
I got through Q3 learning Sketch on the fly. Which means I learned some sophisticated things quickly, and also missed some square-1 basics. Coming out of Q3, my workflow looked like this:
accounts bar, Q3 wireframes
Not only was my process disorganized—it was terribly inefficient. I still produced some serviceable wireframes, but the UI was stylistically—and functionally—a bit all over the map.
example of flows, Q3 wireframes
This works ok for a lone designer who knows where she’s going and why. It’s totally unworkable for a team effort, especially with outside consults or clients. So my first shift was to start thinking like a manager—If I am the product lead, what parameters, systems, and symbols need to be in place so others can follow along?
So I revamped my flow to be easily followed, searchable, and indexed:
accounts bar, Q4 wireframes
And I learned to save key components as symbols, streamlining both my building process and others’ ease in identifying each flow.
Templates Exist for a Reason.
My first lesson from Chap, the developer I met with, was that anything customizable takes significantly longer to build (meaning way higher developer hours/expense). We sat down to look at my wireframes together, and each time we hit a customized button or login field, he would ask, “Is there specific purpose behind this being customized?” Usually, the answer was “No”—iOS would be fine, and I’d just either not known that was an option, or had just tried to make something cute for the fun of it. Where that approach may work for user testing on the design end, as a product manager you inherit significant constraints—specifically, money, and time.
At his encouragement, I revamped my login screens to use existing iOS buttons and alert formatting. If I’d customized something with specific intent, I kept it. If iOS would work just as well, I swapped it.
You Have No Idea How Long Anything Will Take to Build.
It turns out I am very bad at predicting what will take a long time. Bitmoji? Only 1 day. Edge detection to capture a check for mobile deposit? Up to 5 days. Linking your app with a third-party bank account? Entirely dependent on any existing agreement between your bank and the other bank, and whether a plugin exists or we have to build one from scratch…so this could take anywhere from 1 day to several weeks. Which brings me to:
Come With As Many Scoping Problems Answered As Possible.
I had some major blindspots coming into our meeting. I didn’t know if this bank app integrated with others. I didn’t know how many login attempts a user could make before the bank would suspend their account. I didn’t know how far back I wanted users to be able to scroll back through recent transactions before being required to just download their statement. Chap raised several questions around bank data-sharing and “length of time” in my apps’ features, none of which I knew how to answer. This creates uncertainty for the developer, and as Chap told me clearly: The more complexity and uncertainty you throw at a developer, the higher their burden…and they will quote you a (n expontentially) higher rate accordingly.
Chap’s “developer days” estimate. Left: Initial estimate. Center: Scaled 1.5 if mild uncertainty/unclarity. Right: Scaled 2.0 if significant uncertainty/clarity. Note the huge spread between “best case” and “worst case” quotes.
developer’s “developer days” estimate, Q4 wireframes
With Chap’s feedback in hand, I revised my wireframes: More customized to iOS style; fewer screens to do the same job; and key components broken out for quick reference.
Those are below:
flow: check account
flow: deposit a check