Designer Needs Developer: My Blueprint for Building an App
“Starting Over!? Nooooo!” said my internal monologue. I knew I had to begin again.
In the final quarter of our year as Interactive Design students at AC4D; we’re learning the pathway to bring a design into the real world. And that pathway can have many restarts or forks in the road. In this case, I’ve redesigned my banking app, Ally Bank, for mobile Apple devices.
I spent the last few months making mockups (called wireframes) on paper and using the program Sketch. I tested my redesign with users, made changes, and went back and started it all again. Then I realized my wireframes looked sloppy, and more importantly, didn’t meet Apple’s Human Interface Guidelines.
Yes, just like cars and trucks have to meet certain size regulations (thanks Federal Highway Administration!) so do mobile operating systems (thanks Apple!). This was the key reason to go back to the Sketch drawing board and make wireframes that a developer could work with.
The saying goes, “developers are lazy.” In fact, they say it themselves. But this is just a cute simplification. More accurately, developers don’t want to do the work of designers. Our class paired us with a professional developer. But before I would go and meet with a professional for an hours estimate, I had to have my wireframes in a decent place. This involved knowing my features, each of my buttons, controls, and an awareness of edge cases, the particular instances where the user doesn’t know what to do.
Designer Meets Developer
I met with Mark Phillip, CEO & Founder of Are You Watching This?! and a very experienced developer. Meeting with Mark was the impetus for creating the guide above, which will help give a developer basic parameters to begin coding.
I showed Mark all of my wireframes grouped in flows. Each flow is a particular task, such as checking the details of an expense. Check out the flow below as an example:
Meeting with Mark provided a few key insights:
- Give a big picture view of the app you want made, perhaps a concept map of the whole system
- Use iOS standards and guidelines (and Android when needed); particularly built-in functions like date pickers which Apple has already developed
- Keep tasks on one screen (with pop-up buttons); it can flow better, and it’s cheaper
- Common customization features can be time-suckers
- Extensive “redlining” is not necessary, just have visuals, and know what happens when the user takes an action
The flow below is an appropriate example of not making a developer’s life easier. Here, our user wants to send money to an existing contact. But the time-consuming development factor was surprising to me. Allowing the user to select any possible day at any reoccurring frequency is a developer’s nightmare. The finicky nature of our Georgian calendar causes developers to have nightmares. I plan to reduce the user’s options’ for reoccurring transfers to three particular instances: one time (now); weekly, and monthly.
Cost & Conclusion
Mark was extremely gracious with his time and advice. Based on his estimates to do front-end development; he estimated my 14 flows would take just over 339 total hours, or roughly, 21 days for two developers, or 42 days for a single developer.
Based on a freelance developer hourly rate between $120 – $300/hr; the app would take between $40,000 – $101,000 to build. And that does not account for back-end development (the systems to retrieve all your money data) nor would that include the very extensive task of app management.
With an audience of over six million customers, Ally Bank is most likely hiring a full-time team or employing an internal team of developers to keep this online-only bank functioning.
As for myself, after this assignment I’ll be better prepared in two instances: moving from paper to digital wireframes, and having the visuals for all edge cases before meeting with a developer.