why mobile ui/ux is its own thing
When I started building apps I assumed UI/UX on mobile was just desktop design with smaller buttons. I was so wrong. A phone is held in one hand, used in short bursts, in bad lighting, while someone is also doing something else. Every assumption you have about a user sitting still and paying attention goes out the window.
The thing that took me the longest to internalise is that people do not read your app, they scan it. On desktop you might forgive a cluttered screen because there is usually room to breathe. On a 6 inch screen, clutter is the difference between someone understanding what to do and someone closing the app. So most of what follows is really just me learning to remove things rather than add them.
thumb reach is real and you will get it wrong
The single most useful concept I picked up is the thumb zone. If you hold your phone in one hand, your thumb can comfortably reach the bottom and middle of the screen, but the top corners can be a stretch, especially on larger phones. This is why iOS puts navigation at the bottom and why the most important actions should live where the thumb already is.
When I was first making apps I spent a lot of time just looking at the apps I already used every day and asking why their navigation sat where it did. Why is the tab bar always at the bottom, why does the search bar pull down to the middle, why are the back buttons in the top left but the action buttons down low. Once you start noticing it you cannot stop, and it all comes back to the thumb. The apps that felt good in my hand were the ones that kept the things I tapped most within an easy reach. Now I treat the bottom third of the screen as prime real estate and the top as the place for things you look at but rarely touch, like titles and status.
A good test for this is to use your app for a week on your actual phone, with your actual hand, in the actual places you would use it. Not in the simulator on your desk.
the cost of a tap
Every tap has a cost, and it is higher than you think. On desktop a click is cheap, but on mobile a tap means moving your thumb, possibly hitting the wrong thing, waiting for a screen to push, and losing your place. So I try to ask does this really need to be its own screen?
A lot of the time the answer is no. A setting that lives three taps deep might as well not exist, because nobody will ever find it. I have moved features up and out of submenus more times than I can count, and almost every time the feature suddenly started getting used. People were not avoiding it because they did not want it. They were avoiding it because it was buried.
This does not mean cram everything onto one screen. It means be honest about which things people actually do often, and put those within reach. The rare stuff can live deeper. The trick is being honest about what is rare.
empty states matter more than you think
When you build an app you see it full of data, because you have been testing it with your own stuff for months. But every single user starts with a blank screen, and that blank screen is the most important screen in the whole app. It is the first impression and it is where people decide whether they get it or not.
A bad empty state is just a void with maybe the word “No items” floating in the middle. A good empty state tells you what this screen is for, what will eventually live here, and gives you one obvious thing to tap to get started. I spend a genuinely silly amount of time on empty states now because they do so much heavy lifting for new users.
The same goes for loading and error states. The happy path where everything has loaded is the easy part. The app feels polished or broken based on what happens when there is nothing yet, or when something went wrong.
design for interruptions
Nobody uses a phone app in one calm uninterrupted sitting. They get a text, they put the phone down, they come back ten minutes later having forgotten exactly what they were doing. So the app has to survive being abandoned mid-task and picked up again.
In practice this means a few things. Save state aggressively so nothing is lost when the app gets backgrounded. When someone comes back, make it obvious where they were and what they were doing. And avoid long multi-step flows that punish people for stepping away, because they will step away. If you have ever filled out half a form, switched apps, and come back to a blank form, you know exactly how that feels.
This is also why I am cautious with anything that demands the user’s full attention right now. A modal that blocks everything, a timer that punishes you for being slow, a flow that cannot be paused. The phone is a chaotic environment and your app is rarely the most important thing happening.
small touches that make it feel good
There is a difference between an app that works and an app that feels good, and most of that difference is small stuff that nobody consciously notices.
Haptics are a big one. A tiny buzz when you complete something, when you toggle a switch, when you hit a limit, makes the whole thing feel physical and responsive. Used sparingly it is lovely. Used everywhere it is annoying, so the restraint matters as much as the effect.
Animation is the other one. Not flashy animation, just things moving from where they were to where they are going instead of teleporting. When a new item slides into a list instead of just appearing, your brain understands what happened without you having to think about it. The animation is doing the explaining. The moment it gets slow or showy though, it becomes a thing you wait through, and then it is worse than no animation at all. Fast and subtle wins.
And then there is just respecting the platform. Use the system font, support dark mode properly, let people use the back gesture, do not reinvent the scroll bar. On iOS especially, people have deep muscle memory for how things should behave, and fighting that to be “unique” mostly just makes your app feel wrong in a way users cannot articulate but definitely feel.
accessibility is not a separate feature
For a long time I thought of accessibility as a checklist I would get to eventually. That was a mistake. Designing with bigger text, decent contrast, and proper labels does not just help people who need it, it makes the app better for everyone. The same large tap targets that help someone with shaky hands also help me when I am tapping with one thumb on a moving train.
Dynamic Type on iOS is the clearest example. If your layout breaks the moment someone bumps up their text size, that is not their problem, it is a sign your layout was too rigid to begin with. Building things that flex to bigger text usually forces you into a cleaner, more forgiving layout anyway.
the only real test
You can read every guideline and follow every rule and still ship something that feels off. The only thing that has consistently worked for me is watching someone who is not me use the app for the first time, and saying nothing while they do it.
It is genuinely painful. They will tap the wrong thing, miss the button you were so proud of, and get confused by the label you thought was obvious. But every single one of those moments is a gift, because it is a thing you can fix that you would never have found on your own. I have never once watched someone use one of my apps and not immediately found something to change.
Mobile UI/UX, in the end, is less about knowing the right answers and more about staying humble enough to keep noticing where it is still rough. The phone in someone’s hand does not care how clever your design was. It only cares whether it got out of the way.