What do you do when a client comes to you and says that their app is underperforming? With this five-step process, you’ll be able to diagnose and repair these issues with ease.
Let’s say a client comes to you and says their app isn’t doing what it’s supposed to do or they’re unhappy with the results. Ugh. That could mean any number of things.
It’s not really their fault. It’s kind of like having to take your phone into the Apple store or your car to the mechanic. You know what you observed and why you think it’s not working. But in terms of technically diagnosing the issue? Many people can’t do that. So while it might be frustrating when a client describes vaguely what’s going on, that’s what this process is for.
In the following post, we’ll go through the step-by-step approach you can use to diagnose and treat most issues your clients have with their apps.
While the methods you use from project to project will differ based on the underlying issue, the process itself will remain the same. There are five steps to follow. Below, we’re going to use a hypothetical fintech app to demonstrate how you’d work through them.
When your client brings the problem to you, it’s probably going to be described in terms like these:
“We’re not getting any users.”
“We see people installing it, but no one uses it.”
“We’re losing users just as quickly as we’re getting them.”
Those are valid problems, but they’re too broad, vague and emotional to do much with them. That’s why, in this data-gathering phase, you’re going to look into the fintech app’s existing data.
First, talk to your client and see if you can get them to provide you with more detail. Let’s say they come to you with this problem:
“We have plenty of installs, but no one is signing up for the app.”
Rather than try to get them to explain the technical issue (since they’re not going to know what that is), focus on their objective. Ask them the following questions:
Getting them to think about the problem from the business’s perspective will encourage them to describe the problem more like a story. Like this:
“Our small business accounting app has been in the Google and Apple app stores for six months. It gets dozens of installs every day. However, we only get one or two subscribers a week.”
By getting them to more carefully define what their expectations and objectives were, this will help you gather enough details to flesh out a more specific problem to tackle. Also, if they’re being unrealistic or unreasonable (like expecting thousands of new signups a month after launch), you won’t waste their time or yours researching and fixing a problem that’s not yet a problem.
Now, even if you have a good idea where the problem lies based on the client’s description, you should still review all the app data to make sure you’re not missing anything. Here are the key data points to note:
This data gathering exercise should paint an accurate picture of what’s going on for users at different points of the journey with this app. Document any important trends or telling data points you find.
Before you do any research related to what the users experience when they encounter the app, make some observations of your own. Even if you were the one to originally build the app, putting some time and other projects between you and it will allow you to approach it now with fresh(er) eyes.
There are a number of things to check up on. It’ll depend on what the issue is that you’ve identified. But let’s run through some of the common checks you might do at this stage:
Do a search for the app by name.
Go to each app store and do a search for the app by name. If the exact name of the app doesn’t pull up anything or the app page is buried far down the results page, then you know the issue has to do with SEO and likely the quality of the page itself.
If the amount of installs isn’t a problem, this probably won’t reveal much, but it’s still good to start with it to make sure everything’s okay on that front.
Do a search for the app purpose.
In our example, you’d want to search for terms like:
It wouldn’t be a bad idea to swap out “small business” for “freelance” either.
The point of this exercise is to see if the app’s purpose is accurately described by its metadata and the content on the landing page. If there’s a disconnect between what people are searching for and what they encounter, that may be why there are lots of app store visits but low percentages of installs.
Attempt the signup/onboarding process.
Install the app from the app store. Before you do anything else, make note of your thoughts. Does what you see here logically flow from the app store to the onboarding screen? If not, what’s wrong?
Go ahead and sign up. Did you experience any issues with the process? If so, were they deal breakers?
First impressions matter. If what is being sold on the app store page isn’t reflected at the start of their experience within the installed app, that’s probably why you’re seeing lots of installs but low subscription rates.
Use the app to perform common actions.
The other thing you can do to test this from the users’ perspectives is to attempt the top three actions they’d take. For an accounting app, that might be:
Run through the steps for each and take notice of any friction or errors. Also make note of how the design and layout make you feel. If you observe any issues, this may be the reason why users don’t stay subscribed long after signup.
This is where UX research comes in handy. Now that you have a better idea of the problems inherent in the app, you’re going to seek out confirmation from your target audience.
Since the app is already live, you can ask existing users for feedback through in-app surveys or feedback forms. That said, if these users are actually using the app, their insights might not be all that reflective of how users who install but never subscribe feel. It’s still important to engage with them regardless. You never know what you might learn.
You can use other research methods to find out what’s going on with a low signup rate:
User interviews and focus groups will put you face to face with target users to get their opinions and feedback on the app. Depending on where the issue is, you might want to gather user insights related to the discoverability of the app, the app store listing, the onboarding process, in-app features or something else.
Heatmaps and app session recordings will be a useful way of passively observing users and collecting their “feedback.” Use the software on the parts of the user journey where you’re seeing the most dropoff. You won’t be able to do anything if the issue is in the discovery phase, but you will if it occurs during onboarding or inside of the app.
Usability tests are another option. This will allow you to directly or indirectly observe target users interacting with the app similar to what you did in Step 2. In addition to asking them to complete tasks, you can request that they explain what they’re doing with each step, giving you further insight into why they won’t convert.
What might have felt intuitive to you as a designer might not be for them, so don’t be surprised if there are disparities between your experience and theirs. You might also discover a trend in shared concerns that the users have that you or the original designer might not have anticipated (especially as it relates to financial technologies).
At this stage, you’re no longer working on a problem based on your client’s gut concerns or emotional response to an underperforming app. You now have a clear hypothesis:
This is what’s going on and this is why it’s happening. If I do X, then Y will follow.
For example, let’s say that you’ve found that your client’s small business accounting app is comparable to a Xero or QuickBooks Self-Employed, just a tad bit cheaper. This is what existing subscribers have told you about the app.
However, when users install the app from the app store, they immediately see a screen asking them to pay $15 for access. Many of them are shocked. This is an app they were willing to try based on the positive reviews and the promise of a cost-efficient accounting solution. But without the brand reputation that the bigger companies have, small business owners are understandably reluctant to sign up.
In your opinion and the users’ you interviewed and observed, there’s nothing wrong with the app store listing. It’s the app’s diminutive reputation that is, so you believe the following solutions will help:
Solution 1: If we ask users only for an email and password after installation, they will get a chance to see the inside of the app without the pressure of having to pay first. The features will be gated off until they subscribe, but it will at least assure them that it’s going to be money well-spent.
Solution 2: If we build a web-based landing page for the mobile app, we’ll have more space to talk up the benefits of the app, describe the features and provide context for them, and include a comparison table between our solution and the competition. This will not only help the app attract more traffic, but also qualify those leads before they go to the app store and install it.
You might end up with a number of hypotheses—competing or independent—like I have here. That’s okay. But just as with A/B testing where you never want to run more than one test at a time, you only want to implement one solution at a time. Prioritize your hypotheses and then get to work on implementing them.
Review your hypothesis and plan with the client along with your findings. When they give you the go ahead, implement it.
While you might not be in the habit of closely watching an app’s performance immediately after launch, it’s a critical part of this process. Especially if the objective is to increase signups in a meaningful way (i.e., retaining those subscribers).
When it comes to financial mobile apps, in particular, retention rates tend to drop significantly over the first 30 days post-installation. So, you won’t be able to log into your analytics just once and be able to confirm that the fix you implemented worked or didn’t.
In addition to monitoring the app’s performance after launch, you should compare it against all that data you collected at the beginning of the process. That’s the true metric for success here. Is the app performing better now? And is it going to reach your client’s original objective if it isn’t there already?
By the way, if your plan involves the reconfiguration of the app’s SEO or marketing strategy, you probably won’t see major shifts in the data right away. These types of changes can take months to catch on, so be patient.
Once you’ve collected and analyzed a decent body of data, you can start thinking about implementing other changes to improve the users’ experiences. You may have other hypotheses waiting in line or you may simply want to start A/B testing different parts of the UI to experiment with ways to make the product stronger.
When a client comes to you with a problem, you want to be able to present them with a fast and immediate solution. It’s not always that easy, though, especially if their complaint is vague and directionless. That said, if you take a methodical approach to assess the underlying issue, confirm it with the target audience, and then repair the relevant parts of the app, you’ll at least have a straightforward process that will get you to the right answer.
A former project manager and web design agency manager, Suzanne Scacca now writes about the changing landscape of design, development and software.