Moving from Wireframes to a Product
Resurrecting Quarter 2 Artifacts
This quarter in Product Management, we are learning about giving life to a product, starting with wrapping our heads around application development.
To learn more about developers’ timelines and considerations, I dusted off my wireframes from last December’s Rapid Ideation and Creative Prototyping Course.
Back in Quarter 2, I created 5 iterations of wireframes for my banking app re-design. With each iteration, I went out into the wild (mostly places with beer) and had strangers talk through navigating the app’s flows.
The class followed think-aloud usability testing protocol, which has the tester verbally express their thought process as they work towards a prescribed goal. Throughout the activity, the administrator is unable to answer any questions the tester may have, simply responding and probing with “please keep talking”.
This method can feel uncomfortable, but this discomfort comes with a reward: with 6-10 think-aloud tests, designers can identify their product’s primary usability issues.
This first assignment focused on understanding how long building something actually takes and which components are the time sinks.
I was very fortunate to get almost two hours with Mark Phillip, an Austin-based developer and entrepreneur, to size out my wireframes. Mark went through flow by flow (log in, check credit balance, transfer money, etc.), estimating each one in days. This post covers my higher level evaluation, as well as the particular pieces that will stay with me as I move into building a product roadmap.
Below is a snapshot of how I prepared my wireframes for meeting with Mark. The highlighted pieces are buttons, components, and features that I wanted to ensure got included in my estimate.
123 Days of Development – The Breakdown
Review the complete breakdown and discussion notes here.
Adding and editing payment recipients is a time-consuming feature. Additionally, I have 4 different ways to send money. If I can nail this and streamline the payment workflow itself, I can save time on these 26 days.
There are a few expensive goodies which I’ll have to weigh – how beneficial are these to the user experience?
- Auto photo capture for check deposit: 2 days
- Personal avatar with photo saved bank system-wide: 4 days
- Just push notifications would take 2 days less than doing push, email, and text notification options
- Touch ID login: 2 days
I would love for my application to be available in more than just English, so I asked Mark about translations. Developers call this Internationalization, or I18N for short, and it is a lot smoother to work on from the start of the process.
While building the app, a developer would flag each language item on the screen, and that flag serves as a placeholder to pull in languages from any dictionaries. It’s 10-15% extra days on top of the entire app estimate, but, once it’s in place, any language of similar word length can be easily integrated. This will be a tough, but urgent decision to make as I create my product roadmap.
Recurring Transaction Options
My original wireframes included almost any option you could want for a recurring transaction:
- one time
- every two weeks
- every six months
Mark estimated that building 2 monthly recurring options would take 3 days, while adding two more options would increase the estimate to 5 days.
I need to discriminate which types of payments really need recurring options, and then how many options users really need to satisfy 95% of users.
Charting the Course
Over this next week, I will be gathering my takeaways from this meeting to prioritize the building of my banking application’s features.
More wireframes and flow annotations can be found here: Wireframes V6.