JooMaa journal Mobile UX | Page 48

What NOT to do

Design for each native mobile platform - Android and iOS - because each has unique capabilities and visual languages , don ’ t replicate the web experience to apps , and don ’ t interrupt users .
Do not mimic UI elements from other platforms ( from Android to iOS and vice versa )
Each platform has a distinct set of conventions and qualities . If you replicate elements from one platform to another , you risk compromising the user experience and conversion . For example , some platforms support buttons with rounded corners , or actions may have different behaviours , and it is these details and affordances that provide the user with a familiar and consistent experience . ( see : sample of UI elements , icons , tabs , etc . from Android , iOS , and Windows Phone )
Do not use underlined links ( apps use buttons NOT 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 hardcode links ( to other sites or apps ) Avoid hard-coding links in your app , both to sites and other apps . Hard coded links will need to be manually changed and cost you time and effort .
Users navigating to broken links will have a poor experience and may abandon .
Do not take users to the browser ( users ’ stay in-app at all times )
Keep users in-app at all times , to maintain their geography and to optimise conversion . If your app lacks a specific feature or content , try to use an in-app browser ; but do not invoke the Smartphone browser , or you will cause users to lose their geography and not return to the app , which will increase abandonment and reduce conversion .
Do not ask users to rate your app too soon after downloading it ( i . e . don ’ t interrupt users )
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 ( that you can act on ). You could trigger the rating request after a specific number of app openings or tasks / goals have been completed . Also , never incentivise positive ratings , as this is against store rules .
48