Your app isn’t only being judged against your competitors.
Every time someone opens it, they bring years of experience from WhatsApp, Instagram, Amazon, Google Maps, their banking app and countless other digital products.
They already know what a search icon should do. They have an idea of where account settings should live. They expect a back button to behave in a certain way. And when they tap something, they expect something to happen.
Your customer isn’t sitting there thinking, “This navigation is better than Competitor X.”
They’re thinking, “Why can’t I find what I’m looking for?”
And they’ll make that judgement pretty quickly.
There’s an awkward point for a design studio to make here: not everything needs to be original.
Originality absolutely has its place. Your visual identity should feel like yours. Your product should solve a problem in a way that gives people a reason to use it. But there comes a point where creative differentiation starts getting in the way of usability.
You can create the most beautiful interface in the world. If people have to stop and work out how to use it, your app UI design is creating a problem rather than solving one.
So, when we describe an app as “intuitive”, what do we actually mean?
What Does “Intuitive” App UI Design Actually Mean?
Intuitive is one of those words that gets thrown around in design meetings until it loses its meaning.
An interface doesn’t magically make sense because a designer has found the perfect arrangement of pixels. Most of the time, it feels intuitive because the person using it has seen something similar before.
That’s essentially Jakob’s Law. Users spend most of their time using products other than yours, so they arrive with expectations formed by everything else they use.
In other words, familiarity is doing a lot of the heavy lifting.
A magnifying glass means search because thousands of other interfaces have taught us that. Familiar navigation doesn’t need a tutorial because people already understand the relationship between the icons and the sections behind them.
Apple takes a similar approach in its Human Interface Guidelines, encouraging designers to adopt platform conventions and familiar controls so apps feel at home on the device.
You’re not starting with a blank slate. Your users have already been trained.
Familiar Doesn’t Mean Generic
There’s a lazy interpretation of all this: just copy what everybody else does.
That’s not the point. Two apps can use exactly the same underlying navigation logic and still look completely different.
Your brand can come through in typography, colour, illustration, motion, content, hierarchy, tone of voice and all the little details that make an interface feel like yours.
The goal isn’t to make every app look identical. It’s to avoid being unconventional for the sake of it.
Your user shouldn’t have to learn what your clever new icon means because somebody wanted the navigation to look different. Save their attention for the parts of your product that actually deserve it.
What Your Users Have Already Learnt
For most mobile users, Apple and Google have done a lot of the teaching already.
Their design guidelines aren’t simply rulebooks for designers. They reflect patterns that millions of people have become familiar with through everyday use. Following those conventions isn’t boring. You’re taking advantage of training somebody else has already paid for.
Here are three good examples.
1. Important Actions Are Easy to Reach
Mobile UI isn’t desktop UI squeezed onto a smaller screen.
People physically hold their phones. Often with one hand. That means the position of a button can make something easier or harder to use.
Apple notes that controls around the middle and bottom areas of an iPhone display tend to be easier and more comfortable to reach. That also connects with Fitts’s Law, which broadly tells us that interactions become easier when targets are large enough and easy to reach.
You don’t need to turn every design meeting into a debate about thumb-zone diagrams.
Ask the useful questions instead.
- Is the main action easy to reach?
- Are your tap targets comfortably sized?
- Have important controls ended up in an awkward corner because the layout looked nicer that way?
- Can somebody complete a common task comfortably with one hand?
App UI design has to work with the human holding the screen, not just the screen itself.
2. Navigation Works the Way It Does Everywhere Else
People already understand bottom navigation, back buttons, tab bars, search icons and “more” menus.
They expect yours to work in much the same way.
That means keeping important sections accessible, making it obvious where someone is within the app and preserving the behaviour they expect when they hit back.
The same applies to icons. If you hide a common action behind a completely bespoke symbol, don’t be surprised when nobody taps it.
You can put plenty of personality into an interface without reinventing how people move around it.
3. Permissions Are Asked for When They Make Sense
We’ve all opened an app for the first time and immediately been bombarded with permission requests.
- Camera access.
- Location.
- Notifications.
- Contacts.
You haven’t even worked out what the app does yet.
Android’s guidance recommends requesting permissions in context, when someone actually tries to use the relevant feature. If they tap “Scan document”, that’s a pretty logical time to ask for camera access. They know what they’re trying to do, so they also understand why you’re asking.
Trust works better when there’s context.
There’s a practical business reason too. If somebody rejects a permission because you asked for it too early, you could make an important part of your app more difficult for them to use later.
Design for Real Life, Not the Perfect Demo
Nobody uses a mobile app under laboratory conditions.
Your App Will Get Interrupted
Someone starts filling in a form. Their train goes into a tunnel. A call comes through. They reply to a WhatsApp message. They lock their phone.
Ten minutes later, they come back. What happens?
If the form has reset and everything they entered has disappeared, they’re not going to care how nice your app looks.
Good mobile UX needs to survive real life.
That means thinking about application state, backgrounding, different devices, patchy connections and interruptions rather than only testing a perfect prototype on fast office WiFi.
Design the Messy States Too
Designers naturally spend a lot of time looking at screens when everything is working properly and there’s plenty of content to show.
Real apps aren’t always like that.
Sometimes there’s nothing to display yet. The app might be loading, the internet connection might drop, a search might return nothing or something might simply go wrong.
You need to design for those moments too.
Imagine opening an expenses app before you’ve added your first expense. A completely blank screen can feel broken. Instead, the app should explain why there’s nothing there yet and make it obvious what you can do next.
The same goes for errors. “Something went wrong” doesn’t tell you much. Where possible, explain what happened and what the user can do about it.
Loading deserves the same attention. Research summarised by Nielsen suggests something feels instant at around 0.1 seconds. At around 1 second, people notice the delay but can stay focused. By roughly 10 seconds, you risk losing their attention altogether.
If someone taps a button and nothing seems to happen, they’ll probably assume it hasn’t worked. Then they’ll tap it again. And probably once more for good measure.
Good app design should make it clear what’s happening, even when everything isn’t going perfectly.
When the UX is good, users won’t even notice it. It’s usually when something doesn’t work as expected that they start to notice the design.
Why We Start With Wireframes
A polished interface can be very persuasive. Sometimes, too persuasive.
Once you’ve added colours, typography, imagery and branding, it’s easy to respond to how professional something looks rather than asking whether it actually works.
There’s a recognised principle behind this too. The aesthetic usability effect describes our tendency to perceive attractive interfaces as more usable than they objectively are.
So we deliberately take that advantage away at the beginning.
Grey boxes are unforgiving. A wireframe makes you focus on the questions that actually matter:
- What comes first? What does the user need to see or understand straight away?
- What can they do here? Every screen needs a clear purpose.
- Where do they go next? The journey should make sense without somebody explaining it.
- Is anything missing? Have we given them everything they need to complete the task?
- Does the whole thing actually work? Before we make it look good, the structure needs to hold up.
Only when those answers hold up do we start making it look great.
How We Approached Breedera
Breedera is a good example of this process in action.
It’s a dog breeding app that allows breeders to log heats, weights and temperatures, manage contacts for buyers and vets, and predict future heat cycles.
We didn’t start by deciding what the finished screens should look like. We started with discovery and feature definition. From there, we mapped the essential user flows, created wireframes, built an interactive prototype and put it in front of real users.
Then we refined it.
The testing was particularly important because Breedera has an international user base working at very different scales.
A tidy prototype with ten test records can work perfectly. A breeder who has accumulated years of information is using something very different.
Testing with people in realistic situations exposed behaviour and requirements that a small internal test could easily miss.
That’s exactly why user testing exists.
When Should App UX Break the Rules?
If every convention had to be followed blindly, every app would eventually become the same product wearing a different colour scheme.
That’s not good design either.
The better question is: where does being different actually create value?
Use convention when someone is doing something they’ve already done a thousand times before. Put your creative energy into the one or two things your product does differently.
Sometimes Friction Is Good UX
We talk a lot about removing friction from digital experiences.
But friction isn’t automatically bad.
Imagine someone is about to permanently delete five years of records. Asking them to confirm the action adds another tap. Technically, you’ve created friction. You’ve also potentially saved them from a fairly disastrous mistake.
A little friction can be useful when you need to:
- Prevent an irreversible mistake, like permanently deleting years of data
- Protect sensitive information before someone accesses or changes it
- Give someone a chance to reconsider an action with bigger consequences
- Add reassurance around payments or other important transactions
The goal isn’t to create the fewest taps possible.
It’s to make the amount of effort appropriate for the consequence of the action.
How Do You Know Whether Your App UI Is Working?
Downloads look nice in a report. Retention tells you whether you’ve built something people want to keep.
Once an app is live, you need to measure the experience against what people are actually supposed to accomplish. Depending on the product, that could mean looking at:
- Retention. Are people coming back after that first download, or opening it once and disappearing?
- Task completion. Can users actually do the thing the app was built to help them do?
- Drop-off. Where are people giving up halfway through an important journey?
- Support demand. If people keep asking how to find or use the same feature, there’s probably something worth fixing.
- Errors. Are users getting stuck, making mistakes or having to go back and try again?
- Time to complete. If you’ve made a journey “simpler”, has it actually become quicker and easier to complete?
Imagine one app gets 50,000 installs but 45,000 people delete it. Another has 10,000 users who depend on it every week. The bigger download number doesn’t automatically mean you’ve built the better product.
Not every app needs the same success metric.
Which brings us straight back to user research.
Before debating button styles and animations, decide what somebody needs to achieve and what behaviour would demonstrate that your product is useful.
Then design around that.
Familiar Enough to Use. Different Enough to Matter.
Good app UI design is partly about knowing which battles aren’t worth fighting.
People already understand search. They understand tabs. They understand familiar form controls, confirmations and common gestures.
You gain very little by teaching them all of that again.
The creative opportunity is somewhere else.
It’s in your brand. It’s in the details of the experience. And most importantly, it’s in the functionality that makes your product worth opening in the first place.
That’s why our app design process at TH3 starts with users rather than screens.
We research what people need, map how they should move through the product, test the structure before visual design gets in the way and prototype the interactions that matter before development begins.
If you’re planning a new app or trying to improve one that people aren’t sticking with, take a look at our app design services to see how we approach research, UX, UI and prototyping.
Or get in touch with TH3 and tell us what you’re trying to build.
Sources
- Alex Glushenkov (2024). Optimistic UI: Making Apps Feel Faster Even When They’re Not. Medium.
- Anon (2026). Request runtime permissions. Android Developers.
- Anon (2024). Human Interface Guidelines. Apple Developer.
- Anon (n.d.). Skeleton Screens 101. Nielsen Norman Group.
- Jakob Nielsen (2000). End of Web Design. Nielsen Norman Group.
- Jakob Nielsen (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
- Jon Yablonski (2023). Fitts’s Law. Laws of UX.
- Kate Moran (2024). The Aesthetic-Usability Effect. Nielsen Norman Group.
- Sanjay Dey (2025). Thumb-Zone Optimization: Mobile Navigation Patterns That Reduced User Effort by 55%. Medium.
- Sarah Mischinger (2020). The How and Why of Interrupt Tests for Mobile Apps. Smartbear.
