How To Continuously Improve Your Mobile Apps (Part 2)

Gathering insights after releasing

In this series of blog posts, we are focusing on several ways of gathering insights from data out of the feedback loop to improve your mobile apps. Collecting feedback leads to insights that will help you prioritize on app improvements in your product roadmap, backlog- and release planning. In an earlier blog post, we were writing about getting insights by creating prototypes and defining a minimal lovable product (MLP) before starting with the development of mobile apps.

Analyzing insights from beta testing and in-app feedback helps with tackling the bigger errors before pushing your app to a bigger crowd. This could save you some nasty reviews in the app store. Next to that it reduces the risks of customers encountering critical bugs that end up being reported through your support channels. In the next and final blog post, we will focus on gaining insights after publishing your app. In this blog post, we’ll focus on how to get customer feedback after the first releases of your app.

1. Beta testing

Beta testing offers you a way to test pre-releases of your mobile app in a controlled fashion. Apps can be installed on lots of different devices with different form factors. Both Google and Apple offer beta testing functionalities for a limited group of testers through their app store platforms. Most of your users already have an app store account which makes beta testing very accessible as no additional registration is needed.

Before publishing beta apps make sure that you have release management processes and tools in place. Your team should be able to deliver automated builds of your app, signed with the right certificates and stored with a logical version number in the app properties. A proper build management setup allows the team to quickly deliver different builds for testing, receiving feedback and fixing issues. Tools like i.e. Visual Studio App Center, Bamboo or Jenkins allows you to set up a continues delivery for the testing of (app) builds but also for continues (automated) deployments to the app stores.

Continuous deployment is mostly depending on the distribution platform. When using Mobile Device Management (MDM), then “real” continuous, pushed deployments are possible. Otherwise, it always dependents on the willingness of the user to install a new version of the app. For iOS in specific, deploying beta apps through Apple’s TestFlight makes installing beta apps relatively easy, with no need to keep track of device identifiers (UDIDs) and updating app provisioning profiles on the developer’s end.

Although there are ways to automate and analyze your tests, beta testing allows you to get feedback from a relatively big group of real users on new features, usability, performance or crashes. Especially if the app is part of a solution with connected devices like (for example) smart lighting or remote controlled central heating, users may use a different setup and have different expectations on the most important features.

If your app launch date is time critical you could consider pushing an internal beta as soon as you have a “minimal lovable” release ready of your app. Once your app is stable enough to be used by a bigger crowd, you can scale up to an external (public) beta test. During a beta testing period, you can monitor both the app and the backend performance by checking the (in-app) analytics and the server side logging. Beta testing allows fixing of the most critical bugs and taking care of some urgent issues before publishing your app.

2. Collecting In-App Feedback

During a beta testing period, you can offer user feedback options inside your app. Feedback options can be implemented in several ways. The most simple option would be to add a button in the main menu that allows users to send their feedback through email to a support email address using any existing email app on the device. Alternatives to adding a feedback option on all screens are to use movement sensors from the mobile device, like shaking. Interactions like this can keep your UI clean while giving the user an option to provide feedback on any screen. Of course, clear instructions are needed on how to trigger this. Also, there are third-party in-app feedback providers that could be considered to cut down on the development costs of a system for collecting and processing feedback if this is already in place.

Utilizing In-app feedback options should not require more than 2 or 3 taps on the screen. Feedback should at least include technical information about i.e. the app version and mobile device used. If possible, general information about the user, the screen flow, suggestions for new features could be added as well. Before adding in-app feedback options to discuss with your design and support team on how to add this in a discrete way. You should build trust by letting the user know that feedback is used for app improvements. Prevent any annoyances e.g. if an external email app is used for sending feedback, the user should be informed about leaving the app. Your product support team needs to be able to reply to the feedback and at a minimum have access to feedback history as well for tracing and reporting purposes.