What It’s Like to Be a Mobile Team in a Desktop-First Company
In the entirety of my short mobile development career (around 10 years), I worked in mobile-first companies, where mobile is king of the show.
Everything was mobile friendly — the APIs, documentation, support, and product. Every stakeholder or manager served the mobile development, which led the company effort to be a successful one.
Joining Melio Payments gave me a new and exciting challenge — growing and building a mobile team in a desktop-first company.
One of the main challenges has to do with the fact mobile is not just another aspect of the product — it’s more like a client that deserves special attention. And it has so many different aspects the organization needs to consider to make it grow and become meaningful.
“Just use the web APIs.”
You’d assume that using the web APIs is fast way to develop our app, right? And you’d be right if we want the same web experience we already have it today. However, mobile users demand a different experience than web users — everything needs to be fast, quick, and immediate.
A modern mobile screen refresh rate is between 60HZ to 120HZ. If rendering a screen takes more than 16ms, we start dropping frames. Or should I say the opposite — loading a screen in less than 16ms means it appears instantly to the user. Just look at your most popular apps — everything is optimized to run super-fast and smooth. Our goal should also be to optimize the user experience to align with what they expect.
But to create a super-fast application, we cannot rely on going back and forth with the backend to load data — the key here must be some kind of local storage.
Working with local storage sets new requirements from our APIs and the backend. For instance, we want the app to load its local storage first and only get updates from the server to lower the loading time to zero. This kind of data sync (“Delta sync”) requires the backend to expose new types of APIs and handling the data differently in the backend database
Delta Sync
In Delta Sync, each record must have its own updated time. In the first launch, the client receives all records and saves them, but it also gets a timestamp representing the most recent item’s updated time. In the next client’s screen load, it once again requests data from the server, but this time it sends the timestamp it received the last time.
The server responds with new, updated data, and sends another timestamp which will be used in the next fetch.
Even though Delta Sync provides a superior user experience, it is recommended for no more than a few hundred records. What do we do when we have more than a few hundred records?
Don’t worry. We’ve got another design pattern for that.
Pagination
Do you know what it’s like for web apps to display data with pages? In the mobile world, this is not a very good experience. Most cases, the user just wants to scroll to the following pages without having to touch the page number or press the “Next” button.
That’s why a pagination-style API is much more suitable for a mobile native app. But just like a Delta sync, pagination requires additional thought when implemented.
For example:
- What to do when we want to “jump” to a specific item?
- How do we handle local storage to provide a better experience?
- If we take local storage, how do we control record deletion?
Pagination is much more challenging than just handling pages and requires us to work closely with the product team to understand the different use cases the users may face.
Fast User Experience Is Not Just Loading Time
Many think of “fast” as loading time only. But we should also speed up specific user flows and take advantage of the technology of the mobile device.
One great example is authentication. It is possible to save the user access token safely on the device and use some kind of biometric authentication method such as face/fingerprint recognition capabilities. Using biometric authentication is superior to any other method, but it may also require the R&D team to build a different infrastructure to take advantage of these capabilities.
This new infrastructure also needs to support the previous web authentication methodology and, therefore, may require re-thinking the company’s authentication development roadmap.
Another example of a fast user experience is focus. Mobile screens are much smaller than desktops, which means we constantly need to decide what we put on the screen and what we need to remove.
A small screen forces us to focus on the main user task, leading us to think differently about our product — what is the most important thing to the user at this stage? What needs to be apparent to the user, and what can we hide?
And that thinking leads us to more significant questions — what exactly is our app’s goal? Are we planning to create multiple apps or one app that does everything?
In mobile-first companies, these questions feel natural and are being asked daily, but a desktop-first company may have a different approach.
Mobile / Desktop Cooperation
Perhaps Mobile and Desktop are two different products and platforms, but it doesn’t mean they can’t cooperate to provide an excellent funnel for the user. But when we add a mobile product to a desktop-first company, we must decide why we are doing that.
Did we do that to expand our user base (growth)? Or perhaps to increase users’ engagement?
Do we want users to onboard in the mobile app and continue on the desktop or vice versa?
What are the primary users’ flows on the mobile and the main user flows on the web, and how will it affect the user’s day-to-day experience?
A mobile app has different capabilities and different strengths. Creating the exact same product as the desktop might be a waste of time and won’t add any value to the company. But expanding user flows, shaping them into a world of instant actions, communication, and mobility, can improve the overall user experience and satisfaction.
Adding a mobile app to a desktop-first company requires different thinking, and that’s true not only for “mobile” but also for any other new platform. A mobile world is different — it’s much more consumable, fast, and minimalistic.
Taking the holistic approach is recommended — thinking of the whole Desktop + Mobile as a system, covering more use cases, flows, and stories, and providing the optimized infrastructure for each one of them will increase your product value.
