As Brett King says, “banking is no longer somewhere you go, but something you do.” This sentiment reflects why account holders increasingly demand a consistent banking experience across devices and platforms. However, as anyone who has worked on a cross-platform app knows, building a consistent experience across channels is a challenging problem to solve. More devices are entering the market every week, and each device comes with its own challenges.
At MX we’ve had good iOS apps, but the user interface of the phone, tablet, and desktop lived in silos with very little in common. So when a feature was added or changed, it had to be designed and coded three times. When we added an Android app, the problem was further complicated. Maintaining the apps was turning into a nightmare on all fronts. It also made for a poor user experience since users had to learn a new way to accomplish the same tasks on each device.
At the beginning of the year we started working on a cross-platform app — one code base that would run everywhere. The goal was to create a unified experience across devices and platforms. Once we had proven that the technology would work for the financial space, we had another challenge: how would we design a UI that is platform-agnostic? We couldn’t just use iOS conventions and slap them on Android and Windows Phone. The experience would feel disjointed and out of place.
Here are a few things we’ve learned in the process of designing our new app, which we’ve named Helios.
Phone & Tablet vs Portrait & Landscape
Soon after we started working on designs and talking about what the cross-platform framework was capable of we realized that referring to the designs as “phone” and “tablet” was actually a misnomer. This app could potentially be used in all sorts of different contexts. The “phone” design might become a Mac app and the “tablet” design could be used on an Amazon FireTV. The words “phone” and “tablet” didn’t fully capture the contexts that these designs would be used in. So we started referring to the layouts as portrait and landscape. This language, while more abstract, removed the limits in our minds of where these designs might be used. It helped us to consider contexts that we wouldn’t have otherwise thought of if we had stuck to talking about designs for phone and tablet.
Before Helios, our typical process was to design the UI for the desktop first and then figure out how to squeeze it down to work on phones. But for Helios we embraced a mobile-first philosophy. We recognized that the mobile app is becoming the primary banking experience for many people. So it made sense to focus on that experience first and then begin to scale up.
The constraints of a small screen force you to focus and cut out anything that isn’t critical. When you start with larger screens the tendency is to add more functionality because you have the space available. But having more space available on the screen doesn’t automatically mean the user has more cognitive space available in their head. The decisions you make about what is important on a small screen carry through as you scale the interface for larger devices.
For example, when designing the account details view we realized that the layout actually became more difficult to use when we tried to make it fill the screen on a large device. The portrait version had a nice clean line your eye could follow but in the landscape version your eye had to jump around the screen. As an experiment, we took the portrait design and dropped it in as a slide-out column for the detail view. It was immediately clear that this was a much better solution. It was also a win for engineers because they could use the exact same code that built the portrait view in landscape.
Our designers are all iOS users, and none of us had much experience designing for Android (and zero experience designing for Windows Phone). So we spent time reading through the Android and Windows guidelines to familiarize ourselves with the design patters on other platforms.
Our iOS bias became very clear while working on the navigation paradigm. We knew we wanted a dashboard to display data as soon as you log into the app. At first we were trying to separate the dashboard from the navigation. And what’s the easiest way to do that? A bottom tab bar! It worked great when we tested it on our iPhones.
But as we read through the Android documentation and showed the prototype to Android users around the office, the tab bar menu became problematic. The Android documentation specifically states that bottom tab bars should not be used (the Action Bar should be used instead). It doesn’t work well with the hardware buttons on Android devices. And it’s not a pattern that Android users are familiar with. Windows Phone faced a similar problem. And when we thought about the interface being used on a desktop with a mouse, it didn’t feel right at all.
So we moved all the navigation items into smaller cards on the dashboard. This created a clearer navigation paradigm where the dashboard became like a home-screen for the app. You tap or click a card, drill into information, and then back-out to the dashboard. This navigation pattern is used on all platforms so we felt confident that users would understand it. And as we did internal testing, people found their way around the app easily, so it was a win.
One Experience Everywhere
Banking software has suffered from fractured experiences for too long. The design challenges we’re solving with Helios will give users access to the features they want no matter where they are. Software shouldn’t discriminate what features are available based on device. Users want to perform the same tasks on phones, tablets, desktops, and even TVs. The unified experience in Helios will let them do that.