The ASB app suite is a major commercial success, being awarded for usability, design and breadth of features. The Windows Phone app in particular is lauded in reviews such as "The best banking app on any platform, anywhere".
As Digital Design Specialist at ASB I was tasked with creating the visual designs for these apps. It was a great challenge to try to isolate elements of the design that would pass for "native" across all platforms, without sacrificing visual and functional consistency.
The majority of the work involved controlled interaction design and copywriting. It was a constant challenge to avoid giving users the wrong expectations across a huge array of circumstances. Major roadbloacks were presented from the outset - Activation of the app required a complex web of interactions requiring multifactor authentication that accounted for a bounce rate of 70% in a similar release across the Tasman. (We achieved bounces of only %15). The Facebook integration required an understanding of the interelationship between the Facebook mobile App, the ASB Mobile app, the existing ASB "Virtual Branch" Facebook app, and an additional ASB app on Facebook, created simply to process payment requests from the app.
I acted as the key contact in the supplier-client relationship between the Corporate and Technology verticals within ASB, liasing with Legal, Marketing and Support, performed triage of internally reported bugs and customer feedback from the app store. I conducted user testing and oversaw the production of video tutorials, then presented the App in person to ASB teams onsite.
Following the retail banking app, the business banking app went into production. This was visually similar, but functionally completely diifferent to the retail app, and was harder because of the myriad of permissions and transaction types that the app was required to handle. See the video below for a look.
The golden UX rules I developed over the 2 years I worked on these projects were:
If you can't give a user certainty, give them control (and vice versa). E.G. if you can't give a user certainty over how a feature works, give them the control to turn it off.
If it's not 100% correct, it's not right. For example, a "Done" button to move to the next screen in a process is misleading, the word "Next" would be more appropriate, even though the user is "Done" with that screen Another good example are client-side error messages - they are superfluous if additional validation is required server-side (save the red exclamation mark for when it really matters!)
