Nowadays, having a strong mobile presence is a must. There’s a good chance that smartphones are one of the primary interfaces through which your users interact with your product, either via your mobile app or the mobile version of your website. But just adding a wrapper over your existing web product won’t cut it: “Mobile” isn’t a checkbox you mark and consider done. Trying to cut corners on your mobile offerings is giving your competitors an unnecessary advantage. This means that it’s not only important to create a mobile solution for customers, but to do so while keeping in mind the usability patterns and idiosyncrasies of both Android and iOS platforms.
“As of July 2019, Android controlled the mobile OS market with a 76 percent share, maintaining its position as the leading mobile operating system worldwide.” – Statista
Android still dominates the mobile market, so if you’re building an Android app, it’s important to consider the experience of those users, who may represent the majority of your audience. Here’s the story of how we built a user-centric Android app for a client in the Human Resource industry—in a whirlwind less-than-two months.
Building a native Android app
At the beginning of 2019, one of our existing clients approached us to help with their Human Capital Management platform. While highly regarded by their customers, the platform lacked a mobile friendly way for the end-users (employees of their customers) to access basic HR-related information—W2s, paycheck history, paycheck notifications, that sort of thing. The company needed a mobile app that would be a companion to their main web-based product, and they needed our help to build the Android version (the iOS version was already in development).
This app would have to be done in less than two months, leaving enough time for it to be tested, verified, and published to app stores in time for a major conference at which they would unveil the new mobile offering.
….It also had to be built natively.
No way around native
Normally, for mobile applications like this, our go-to mobile tooling choice is Xamarin. But it became clear from our discussions that Xamarin wasn’t an option for the client and it had to be built natively. We also prefer to be the ones building the backend APIs, to mitigate work scheduling and dependency issues. However, the client also had a team already tasked with working on the backend APIs that the mobile app would consume.
So when we sat down to plan this project internally, we documented our three main challenges:
- Short deadline
- Native App (can’t use Xamarin)
- Don’t own the backend
Mapping out the solutions
We knew at that point that we would need someone to review the specs of the backend API, keeping track of its available resources and, if possible, proposing changes to help shape its design, even though we were not the ones implementing it. As a Tech Lead on the project, I was able to review the API design and provide upfront feedback. We also knew we would need a tight communication loop with the client’s team, as we had to be as efficient as possible with our time.
The other thing we had to be careful about was designing the application using iOS as the platform for its prototype and proposals. The client wanted to keep the experience on both versions as close as possible, in order to deliver a unique but platform-agnostic experience. While that is understandable and relatable desire, to own your own experience as a developer, it is important to keep the platform you’re building for specificity in mind. Since we were working on the Android app exclusively, we made sure we kept an eye out for any behaviors and requirements in the client’s specs that could interrupt the user experience on Android.
Designing an experience
Our teams hit the ground running and started building out the skeleton of the application as soon as the paperwork was done. With a tight loop of iterating over results at least weekly (at first, two times a week) we were able to move forward at a fast pace and nail down the details that weren’t tied to the backend API: design, navigation, and other user-facing aspects of the application.
This meant reviewing and providing feedback on the existing design guidelines and requirements for the application. We also conducted user research and proposed design changes to make the app feel native on Android, as opposed to feeling like an iOS app that just got ported over to the Android platform.
We proposed critical changes, like using an “Options Menu” to provide additional functionality in a carousel—a common Android design pattern. We also made sure that the overall application navigation structure followed the Material Design Navigation Guidelines. This way, we were able to retain the client’s overall design look and feel while keeping the usability on par with what Android users are familiar with.
Finding new ways to add value
In parallel, we also helped them design a Backends For Frontends (BFF) API. That is, an API whose contract is tailored to the mobile front end as opposed to a General Purpose API, where the mobile app is responsible for combining and coordinating the results of several API calls in order for a given screen to work. This was one of the main drivers of the project’s success, as it allowed us to keep the mobile app code simple and focused on the user experience.
In the end, we not only delivered the application on time but also with budget leftover that allowed us to add an extra feature to further enhance the user experience: We integrated the application authentication with the Biometric Authentication feature of Android. We chose that as the add-on to serve our primary goal of making the app easy and frictionless for end-users. These small, thoughtful elements can be huge differentiators for mobile users who crave simplicity and efficiency—and can be the reason they choose your brand over others.
From a quick sprint to the long run
Any company with a digital presence is expected to have a mobile offering—but it doesn’t need to be a total replication of the main product. Having a companion app that makes it easier for your users to perform their most common tasks is the goal. It’s key to keep the app simple and tailored to the mobile audience you’re building for, following the usability paradigms for each platform.
However, building the app at your own pace and on your own terms is not enough—you must keep pace with your users. You have to develop in a timely manner and iterate constantly—the key point being constantly. While it’s possible to play fast and loose and put an app together quickly, you will only be able to continue to do that if you build your app in a way that sets you up for future success. That means identifying the key areas that can boost your development velocity without hindering your future maintainability. (We did that when we worked with our client to achieve a BFF API design for the mobile backend.) So don’t just aim to move fast. Make sure you’re ready for the marathon, not just the 100 meter sprint.