Over the past years I’ve been involved in a mobile-oriented project, in everything that’s related to testing and quality, starting from processes and down to execution. Being there right from the start, and seeing the business grow alongside with me, gave me an overview on some of the best practices that you can follow in order to achieve great glory– if glory equals “having a 5 star app” out in the wild.
There is not a straightforward formula that you can apply in order to reach the final goal. But there are a lot of small things that can make the difference. There are many sources you can find online that can help guide you through the theory behind building great mobile products. What I’ll try to do is share from my own experience of working for an actual 5 star app.
User Story 1:
As a product owner, I want to build a mobile e-commerce application (iOS/Android) and adopt specific processes so that I can reach the final goal of having a 5 star app out Live.
How? Well, this is where the story begins:
Easy to say, hard to make it happen. One of the key factors here is the UI/UX. An intuitive user experience that can facilitate easy access to information and main app functionality, will generate positive feedback. Accessibility plays a crucial part here as well, as we’re all seeing lately this is an area where product owners are starting to invest more and more, in order to have their apps reach certain goals on that level and improve the overall reliability of their apps.
The competition out there is crazy, as everyone tries to come up with something new on a regular basis. But the success stories are limited and we are all aware of that. In this case, innovation goes hand in hand with users’ necessities. Usually a strong business has tracking metrics in place, and constantly measures “user habits.” Those are all great instruments that can be used by Product teams to come up with ideas and start building new features upon that.
Besides that, including latest “addons” from big players is always a plus and implementing those for your business will provide lift, but the main gain will be on your users’ perception: things like Apple Pay, OS-specific UI notifications or Google Wallet. Those are some examples, but the list can continue on and on, as there’s always something new rolling out. So being in line with latest technologies on the market and developing your product based on those will make the difference.
Another important factor here, and something that’s not that visible for “users eye” like UI, is the performance (e.g.: startup performance, scrolling performance, UX in general). So investing time and effort into tech refactors that constantly improve the performance of your app will add a significant lift on the ratings end, as users in general are more likely to provide feedback if their overall experience with the app is constantly improving, performance wise.
User Story 2:
As a product owner of a mobile e-commerce app (iOS or Android) I want to be able to check specific metrics and analyze “user habits” that will show us where they spend most of their navigation time, so that I can then determine, by extracting data, potential feature improvements.
Outcome example – checking the metrics and analyzing “user habits” shows us that they spend most of the time simply navigating through the product list and details, without going further into the checkout flow. Having the ability to see that, we can use that data and build a feature that will let the users buy directly from the product details page. We can call it “Instant Buy.”
And there’s your new, innovating feature rolling out into engineering for development/testing.
Of course, the next question here is, “Ok, now I that got my feature out and running, how am I going to be able to see if it’s running well or not?” Well thankfully, there’s a pretty mechanism in place that you could use for that, called A/B testing. In our particular case, what that means is that you start to roll out your your new feature for 50% audience of users out Live, and 50% will still see the old experience. Gather data for an “x” period of time, then compare and decide on a winner for 100% distribution. This is just the long story short, as A/B testing is super complex and requires constant monitoring from the Product owner, who is responsible to make to go/no-go final decision by relying on specific KPI’s, analyzing periodical usage revenue and comparing results that directly translates into financial increases.
TOP FIVE TIPS:
1. Don’t be afraid to say NO!
As a QA engineer, your are directly responsible for the quality of the app. You are testing existing functionality (e.g.: regression testing prior to submission) but you are also validating new functionality/new feature set regularly (e.g.: feature testing/integration testing). For the second one, it’s really important to stay diligent, be sharp and don’t be afraid to say “No!” when you have all the arguments in place. “No, we cannot ship this feature in the current state, because A, B or C …” In the end you are the one responsible for the parts you own and sign off for release by release. And the idea of ownership is to drive something from scratch, always follow up when there’s problems, reach goals and targets and stay in sync with anything that could potentially break or cause damage on what you are building. Our role it’s not a “pure execution” role. As a consultant, you need to be prepared and provide solutions, come up with process improvements and get involved in key decisions that could facilitate a better communication between parts.
Story flow example:
- Product team is building up a feature and plans to ship it into the next sprint. QA signs off on validation with two P2’s open (e.g.: mid-text truncation on highly visible action buttons, or choppy scrolling on the product list page)
- There’s pressure to have the feature released like that
- Both are non-blockers for delivery, but as a QA engineer it’s up to you to raise up concerns on the UX once we decide to get out with the feature in the current state. Maybe from a product perspective things like that are not critical, but from a user perspective, is something you’ll end seeing and dealing with everyday. So we’ll need to have that fixed!
Properly manage compromises and clearly define the areas where you won’t take a step back!
2. Anticipating is better than “reacting”
Anticipate a potential issue before it goes out Live. This is a key factor in driving a business toward success. And having the mindset oriented to that direction will easily pay off.
As a product owner I want to have my e-commerce mobile app developed for both phones and tablets, but drop landscape support and prioritize other features development, when the overall user base on tablets usage drops under 5%.
What happens if this decision gets shipped:
At this point, the app could get dozens of 1 star reviews, just for the fact that the landscape support was dropped. Users won’t even bother to discover new features that got implemented. Seeing something they took for granted until now, and made a “habit” out of it gone, that’s the key factor that lead them to bad review decision. So next you’ll have to revert, fix and patch. And that’s time and resource consuming.
In this case, anticipation plays a crucial part. A more thorough analysis, alongside with deeper user impact ackwnoledgement, could lead to avoiding the Prod issue. As a lesson learned here, would be to not overlook the areas that you might think are less important. Those are usually what make the difference between 4.5 star vs. a straight 5 star :).
3. Encourage your users (either internal or external) to report issues
How to do that? This is a simple to implement and feasible solution that could add a lot of value into the quality of the product. Think of a way to have the client engaged in the App review process, from the standpoint of the functionality and user experience.
It’s a so called internal “bug report and triage” mechanism. So once the project gets past feature development phase, and enters into the integration phase prior to regression, that’s the perfect timing for collecting customer/client feedback. The main purpose of the program would be to collect bug reports (functionality issues, crashes, UI, etc.) as well as suggestions for improvements (customer reviews, features related feedback) in a controlled and productive manner.
To give a quick example on how this process could look like, once implemented:
- Come up with a particular project name for this effort
- Implement this as an internal program distributed to a wider audience from which you will collect data/reports from
- Have a “triage” team in place. Usually the QA feature team is involved in these type of activities, due to their expertise on the project area
- Setup triage mechanism tools – data reports, filters, doc sheets with action items
- Escalate (log/track client reports) in order to have those fixed or implemented
- Provide feedback to customers with the resolution, once reports are solved by the dev team
I have experienced this process as we currently have it implemented in the project I’m involved in. And it’s simply something that adds value into the quality of the product, on the long run. It might be time consuming at its first stages, but once you get the wheels spinning, you’ll start seeing some positive outcome.
4. Keep your users happy
Get an idea of what they want to get out of your app, see where it needs adjustments or where things are missing proper UX. There are many ways to do that, but there are two that I’ve experienced and relied on.
i) Repetitive, short release cycle
A 4-5 weeks release cycle, means getting out features constantly, besides bug fixes, which are always welcomed. As a user, seeing that the business is always interested in innovating, in accommodating user needs and requests, and always oriented to keep everything in line with the quick growth of the technology, is always appreciated out Live. This goes hand in hand with making sure to keep the app intuitive and easy to use.
ii) Support team -> constantly checking out store reviews
Have someone to constantly look over and monitor Live reviews, right after submission, and during the first couple of days afterwards. Discover and react. Any problem that appears to be isolated could escalate on a larger scale in hours.
5. Team power
I don’t want to go into a bunch of details on how the engineering teams should work together in keeping up the quality rate, I’m not the expert on that. But what I would like to underline is the importance of the work environment. In the end, that’s mapped into how you run your day to day tasks. There is a thin line between “I love my job” and “I really hate what I’m doing.” In the end, finding the perfect balance on that it’s up to you, but make sure you’ll find it, because otherwise the quality of the work you are doing will damage the outcomes on the long run, business wise included.
Another strong point here is the relationship between engineering and product (starting from management and product part, going into Dev/QA/Design/Backend teams and finally support). A global team effort in general. These “entities” are the tip of the iceberg, the top of the pyramid. If the connection is solid, if there is always open communication between people, good things will happen. For example, strong Dev practices (design reviews, PR reviews, feature kick offs and creating solid documentation that can easily be mapped by QA into testcase base) alongside with a clear mindset from QA side oriented to quality (starting from well structured processes and down to execution) will make the entire system work smoothly. There’s a lot more to it, but you get the picture.
To wrap it up and to reiterate on one of the main ideas here, try to think outside the box and constantly research for new solutions that can help you achieve your final goal. Surely there are a lot more other “tips” in place that you can follow and apply in order to stay on top of the charts and build quality apps. Finding the perfect balance on what and how you manage those will be the key to success.
Feel free to add comments if you want to chat more about any of the topics above. This article catches the main ideas, but as you can imagine, there’s a lot more into it.