Reviews are a very touching point in apps. Some of them criticise your business model, others your customer services, but the most useful and practical ones and performative are the tech bugs/performance reviews. In fact, having application reviews too much focused on tech means that the app is not being useful and does not represent the business model.
Arriving at a scenario where reviews are going down for a long time and in the presence of a codebase needing care. It is safe to say the apocalypse is about to happen. This means having to make changes and improvements to remove the bad tech reviews and make a positive impact on % free crash users.
How can we improve the bad tech related reviews in a medium period of time?
When this was asked to me for the first time, as a fresh developer on the team, I really thought to myself, why are people giving such high importance to this matter more than other metrics?
I deep-dived, and the bad metrics matched with the bad tech reviews, I thought to myself that rebuilding was the solution when facing an outdated and complex codebase. However, it would take time and as a fresh developer, I did not have enough arguments to make it happen.
So, What’s now?
A lesson to be learned and a lot of feature flags to be created. The emmet job!
Every codebase can be improved with an adequate plan.
As with every problem, it should be divided into small chunks and keep it simple.
Fix the most critical bugs and address the critical tickets
There was already a list of Jira tickets to focus on, and the objective was to pair these tickets with the other Android Engineers in the team, to better understand the codebase. During this development some refactors were taken, it was important to create tests to cover the refactors.
However, this was not enough to raise the reviews, because new issues appeared and others were being discovered by the customer support.
It was time to stop doing the infinite list and address the second chunk.
Improve the success scenario
The second chunk of the plan was to improve the application for the success scenario. Just imagine that the user lives in an ideal world. The user should not face issues with logic/UI when the request succeeds.
The objective inside this stage was to focus and write tickets about UX and tech issues when the app was in a successful state. This stage took some time to finalise. Keep in mind that some refactors, and logic behaviours might change during this phase, and you need to adapt to last-minute changes from the product. The issues are not only tech-related, but they could also be related to product logic not well-defined too. Nonetheless, make sure that everything is tested as much as you can for your timetable. The team did not have a dedicated QA in the process, and in another article, I will talk about how to overcome it.
When this stage finishes, the tech reviews started to raise a bit, but not enough to make us happy.
Why?
The UX associated with error handling still needed some work.
Improve the error scenario
The objective of this chunk was to inform and bring value to the user when an error happens. Every request failure was addressed to a big error screen.
The first step was to separate what was a “major request” (a request that brings the biggest value to the screen) and a minor request (brings less value to the user). Finishing this separation, the app would bring the error screen for the major request and a warning message for the minor ones. With the warning message, the user is now able to keep the data and actions already performed and get back to it once the problem is resolved.
Here your bad tech reviews should start to disappear, or those five stars are coming. Your user is able to overcome the challenges when facing an error, and the success scenario is stable enough.
The death process
“Your Android application (process) can be killed at any time if it’s in paused or stopped state. The state of your Activities, Fragments and Views will be saved. When your return back to the application — the system will start the process again, recreate the top activity…” - Android Death Process
There is always that user that complains about losing the data on the screen after hanging a call or even switching to another app for a period of time. Being able to recover from a process death with value to the user is so important to give that extra polish to your application. Make sure to properly address it.
How annoying can be, when you are filing a form or setting up a search with filters and then you hang up a call, when you get back, you lost everything, and have to restart?
This feeling deserves a bad reviews because you are not taking care of your clients.
In this phase, it is important to test and make the recovery from a death process to bring as much value to the user as you can.
After this, what should be done?
Every team should have an engineering plan which addresses how the tech should evolve (architecture, frameworks, design patterns applied, etc.). With a defined plan and consistency across the codebase, you can safely start rebuilding or improving it, since your users can use a stable application.
The objective of this article was to tell a story that should be common these days, and the easy path is not always the most successful one. Do not give up on the work already done. There was a reason to be addressed like that, and it can always be improved. Planning and commitment are major keys to this process.
Top comments (0)