Adopt, Use, Transact, Return |
Investing time and effort in creating, testing and optimising services can have a significant effect on how ‘sticky’ your app becomes.
The basics that need to addressed include optimising conversion, and avoiding interrupting users, or forcing them to think about things that should be simple. Google expresses this as a four-stage ‘Adopt, Use, Transact, Return’ framework.
Adopt, Use, Transact, Return
Adopt - Remove roadblocks to usageRemove all roadblocks to usage - and adoption - of your mobile app. Get users into the content / substance as quickly as possible, so that they can use, assess and experience its value to them.
First impressions count, and a splash screen gives you a short but vital window to engage a user in your proposition. But, never make users wait.
Tips / help or an onboarding sequence should only be employed if really necessary - so as not to interrupt users - but when used appropriately at key decision points, tips/help can guide the user in their initial experience and adoption.
Use - Make conversion decisions simple
Enable people to use your app in the way that suits their needs. A clear structure combined with an excellent search facility using a range of methods, from keyword to product scanning and image search, will help users find what they want quickly and easily, satisfy their needs and drive conversion.
Transact - Provide the ultimate in convenience
Help users progress through each checkout stage with minimal effort, and with sufficient reassurance, to convert without hesitation.
Return - Self service, engagement and delight
Be useful, to engage and delight, in order to retain customers or encourage member loyalty. Because, mobile apps are the most appropriate touchpoint for repeat interactions and frequent transactions, customers and members already loyal to a brand, and mobile first use cases (that couldn’t exist without unique smartphone services leveraging rich and contextual data; etc.), are more likely to return if an app provides an engaging experience.
What not to do
Do not mimic UI elements from other Platforms
Design for each native mobile platform – Android and iOS - because each has unique capabilities and visual languages
Do not use underlined links
Avoid using text with underlined links, which are part of the web / browser / page model, and not part of the app / screen model. Apps use buttons, not links.
Do not take users to the browser
Keep users in-app at all times, to maintain their spatial geography and to optimise conversion.
Do not ask users to rate your app too soon after downloading it
Avoid interrupting users by asking them to rate your app if they’ve only recently downloaded it or only used it a few times. Instead, wait until they prove to be repeat users and they’ll be more likely to rate your app favourably and provide more informed feedback