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.

Think-Aloud Testing

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.

Application Sizing

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.

Credit Card Transactions and Transaction Details
Credit Card Transactions and Transaction Details

123 Days of Development – The Breakdown

Review the complete breakdown and discussion notes here.

Estimate Board

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.

Time-Intensive Features

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

touchid

Internationalization

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.

language selection

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
  • weekly
  • every two weeks
  • monthly
  • quarterly
  • every six months
  • annually

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.