Balancing user experience and performance

Mobile apps have changed our world— from how we pay bills to how we date or order food, to even the ways we play games. They’ve opened up seemingly limitless possibilities, thanks to the talent of the developer community.

Building the next killer app requires the creation of features that attract and delight while still supporting millions of concurrent users— and doing so without compromising the experience. And unfortunately, companies often underestimate just how difficult it can be to strike a balance between performance and experience until they are so far down a path that it is difficult to course correct. As a result, some fantastic ideas never reach their full potential.

Building for Scale: A Critical Factor

The desire to acquire users as fast as possible with a compelling feature set often leads to limitations on the backend. It’s no surprise that when performance suffers, users migrate away from the app out of frustration and/or viral growth sputters. One of the most important things I’ve learned from building multiple companies is that we need to reverse this thinking. Architect based on the assumption of success from the get-go. It’s easier and cleaner to build for scale early than trying to cobble your infrastructure together like Lego bricks as you go.

A developer should always be thinking about what happens when you get a thousand users, ten thousand users, millions? What is the minimum viable product? With my most recent company, for example, we wanted to know how many people we could fit into a single chat room without it falling apart. We understood that sending a single line of text to someone is pretty simple, but having 10,000 people in a single chat room is not. Every time you send a message, that message is broadcast 10,000 times. If you add features like read receipts or typing indicators on top of it, everything becomes exponentially more costly and more complicated. And we had to account for that before we released a commercial offering.

To solve for this, we conducted some early experiments with consumer applications that our friends were building. This allowed us to quickly build and test how things were going in ways that we couldn’t simulate on our own— which ultimately led to three major overhauls in our infrastructure to ensure that we could support the massive global adoption we were striving for.  We aimed big and we built to match that thinking. 

Accounting for Complications

Getting a bit more granular about what organizations should be considering as they create the next big thing, I’ll highlight some of the issues we faced as we developed our product and feature set. While not an extensive list, these problems are common for many different types of applications.

Global User Base

We had to make sure that every layer— mobile devices, to caching, the performance queue, task management, the data reads and writes and so forth— had to scale horizontally. It also had to scale across different geographies to handle a global user base so that no matter where someone was located, they could chat simultaneously without lag. Solving this problem required quite a bit of effort and engineering time.

Traffic Patterns

Expanding this further, there was also the challenge of traffic patterns. This was a big unknown because customers across different verticals can have very different traffic patterns, just as application deployments in different parts of the world do. Solving for this required not only understanding what the traffic patterns were, but also what features given customers would use more or less of, as well as how many users are typically in the group channels simultaneously. There’s a lot going on at once, and each of these pieces needed to be accounted for as we built for strong, reliable performance.

Use Case Coverage

Ensuring our infrastructure was capable of supporting a very wide range of use cases, from community chat to live streamed events, to doctor-patient consults to delivery applications, with their respective patterns involved a lot of servers and experimentation with autoscaling to adjust for high to low volume traffic fluxuations.

Pushing through boundaries, we’ve been able to accomplish engineering feats that weren’t possible previously, such as enabling up to 20,000 users to engage in real-time private group chats. But it took a commitment to scalability from very early on in our company’s lifecycle and a willingness to try and fail until we got it right. We refused to compromise performance to push a feature— and this approach continues. Because we put in the infrastructure work early on, we are able to move very quickly today and can consistently innovate.

And Then Come the Features

Building for scale and performance may not be sexy or appealing, particularly from the beginning, but it is critically important to design for this in early stages of development. . When the number of concurrent users grows, the user experience can be significantly impacted if the infrastructure doesn’t support user volumes to scale with the growth.  Support for a high number of concurrent users is not easily architected into your solution after the fact. 

The chat space, for example, is moving really quickly. It’s not just Facebook Messenger driving the trend; it’s everyone from Slack to TikTok. Pretty much every app now demands some level of real-time interaction capabilities to appeal to consumers, and this is pushing companies to constantly roll out new features to stave off competitive pressure while attracting and retaining users. People also expect all of their favorite applications to have similar features. Think about read receipts. This was not a popular or common feature early on, but now almost every messaging app has them because users expect them. It’s part of the constant evolution of the user experience.

To address this, companies perpetually have to ask “How do we layer in features to make sure we deliver the high quality experience that users want and expect? And how do we do that without compromising scalability and performance?” This is where true value creation comes into play.

The end goal is a seamless experience existing within the application, one that can be tailored for specific verticals if need be. To do this, the secret sauce is in the configuration and a common, scalable infrastructure layer that can host and scale with new features and  services as they are created. If you’ve built a robust infrastructure, one that can scale horizontally, the performance impact of adding new features is minimized. Utilizing a common infrastructure layer also means you can more efficiently add new features and services without having to rebuild and test the underlying infrastructure for scalability every time. 

Developer Support Required

To build for both performance and experience, developer support is key. Companies should be saying, “We want you to help make our tools better. To do that, we will give you the easiest to use, very best tools.”

In the early days of my company, we were all developers at heart. As we grew, we understood how instrumental and beneficial developer support was to our growth, and we strive very hard to create a positive developer experience today. For about 95% of our feature set, we try to really focus on giving developers the power to incorporate it into their apps in unique and interesting ways. 

Developers fuel innovation so any company that hopes to tap into the genius of this community should make an SDK or UIKit that appeals to developers. After all, we have entered the API economy where developers are expected to integrate new capabilities at an incredible pace. Let’s strive to make it as easy as possible to build the most modern features for their applications— without compromising scalability and performance for a compelling user experience. Balance is key, and partnering with developers is how we achieve it.

The post Balancing user experience and performance appeared first on SD Times.

from SD Times https://ift.tt/3gPBwXI