Posted by Mauricio Vergara, Product Marketing Manager, with contibutions by Thousand Ant.
They needed to get to the bottom of the problem quickly — figure out what it would take to resolve and then justify such an investment to their leadership. That meant answering a number of tough questions. Where was the bottleneck? How was it affecting user experience? How great a priority should it be for their team at that moment? Luckily, they had a powerful tool at their disposal that could help them find answers. With the help of . The current and historical performance of each metric is tracked on real devices and can be compared to the performance of other apps in the category. With the help of this powerful tool, the development team discovered that the Lyft Driver app startup time was 15–20% slower than 10 other apps in their category — a pressing issue.
Next, the team needed to establish the right scope for the project, one that would be commensurate with the slowdown’s impact on business goals and user experience. The data from Android vitals made the case clear, especially because it provided a direct comparison to competitors in the rideshare space. The development team estimated that a single developer working on the problem for one month would be enough to make a measurable improvement to app startup time.
Drawing on this wealth of data, and appealing to Lyft’s commitment to app excellence, the team made the case to their leadership. Demonstrating a clear opportunity to improve customer experience, a reasonably scoped and achievable goal, and clear-cut competitive intelligence, they got the go-ahead.
How They Did It
Lyft uses “Time to interact” as a primary startup metric (also known as
First, they reduced unneeded network calls on the critical launch path. After decomposing their backend services, they could safely remove some network calls in the launch path entirely. When possible, they also chose to execute network calls asynchronously. If some data was still required for the application to function, but was not needed during app launch, these calls were made non-blocking to allow the launch to proceed without them. Blocking network calls were able to be safely moved to the background. Finally, they chose to cache data between sessions.
The can help you understand your user and issue distribution to make better decisions about which specs to build for, where to launch, and what to test. The data from the tool allows your team to prioritize quality efforts and determine where improvements will have the greatest impact for the most users. ), check out our condensed case study for product owners and executives linked
SOCIAL SHARE CARD GENERATOR