As I sit on my bed, struck down with malaria, trying not to work and not to work at the same time, I am reminded of the consequences of underestimating mosquitoes. (For those who don't know, mosquitoes are the vectors of malaria.) This got me thinking that there is something else in the mobile world that is underestimated but is the biggest source of user-perceived bugs: bad UX. I decided to write a quick article on it and share my perspective.
You resume work on a calm Monday morning. Less than two hours later, Slack is buzzing. Customer service is forwarding a common complaint from users about some strange bugs happening in the app. No one, including them and the QA team, seems to be able to reproduce the bug. It's a big conundrum. You try to replicate it, but you also hit the same snag. You decide to hope and pray that this issue goes away. But annoyingly, this problem seems to arise at intervals.
I'm guessing this is a common situation in many companies. The reason is that you can never fully test the ways users will use your app. It will be used by thousands, if not millions, of consumers on different devices in different conditions. Your app will be pressed by angry people, busy people, sad people, happy people. It will be virtually impossible for you to test all the different flows that can happen when your app is used.
This article is not meant to discourage you. It is just meant to share, to the best of my limited experience, things you could do to prevent strange bugs.
The most important thing is to have robust validations. For each input field in your app, are you sure that the correct format is inputted before the data is sent for processing? Many mobile devs leave validations only for the login and signup phases of the app. However, it is important for it to be used everywhere your app allows your user to input data. Remember, validation without a clear message is not the correct way. A clear message telling the user why the input is wrong is better than no message at all. Also, using the correct input field for either numbers or emails is the proper way to go.
Your users are impatient. Don't think that the user will just click that button and wait for its outcome. Also, for users with slow devices, the effect of clicking a button might not be immediately apparent. You want to make it impossible for the user to double-click a button until the outcome of the button click is returned. Either disable the button or cover the screen with a dialog. In all cases, you cannot prevent this. But you need to also be sure that double-clicking of that button does not cause an unexpected bug or a bug.
Your users will pause what they are doing on the app and navigate to another app temporarily, then come back. Are you handling for that exact scenario? For Android developers, does Android's aggressive memory management cause unexpected bugs for you? Have you simulated what could happen in these scenarios? And can your app live with the consequences of Android's aggressiveness?
Your users will not navigate the app the way you want them to. They will ignore that back button you provided for them and click on the system back button. Are you properly shepherding them to the page you want them to go to no matter where they navigate to?
Who knows? I might make this a longer series with each one dedicated to a particular war story. Or it might go the way of the majority of my stories: forever in my drafts.
shout out to Nubison for the image
Top comments (0)