Principles of mobile interface design

Where does a mobile interface differ from a desktop one?

In three ways, and none of the three is technical. First, the input: a mouse pointer is a point and a thumb is a soft blob; what a mouse hits precisely, a thumb misses half the time. Second, the posture: a desktop user is sitting and a mobile user is usually walking or waiting. Third, interruption: on a phone a call or a notification arrives at any moment, and the user comes back and has to work out where they were.

A mobile interface is the same visible, touchable layer, but under those three constraints. Everything else follows from there: why one primary action per screen, why the main buttons sit low, why the form is short, why the loading state matters.

Four pillars do the job. Thumb reach says what can be hit without shifting the phone in your hand. Hierarchy says where the eye lands first. Feedback says how the screen shows that something is happening after a tap. Consistency says one pattern stays the same across every screen.

One thing up front so the rest of the lesson is clear: the principles of interface design apply on mobile too and we are not repeating them here. If you have not read the basics, the principles of user interface design are the place to start, and this lesson covers only what mobile adds or changes.

How far does the thumb reach, and how big should a target be?

Hold the phone in one hand and swing your thumb without shifting it. The screen falls into four zones: the comfortable zone low down on the same side as the hand, the stretch zone in the middle and near the top, the far corner you have to slide the phone in your hand to reach, and the top bar, which on a large phone is effectively out of one handed reach. The primary action of a screen belongs in the first zone, and a dangerous action such as delete goes deliberately where it is harder to hit.

Target size, though, is not a guess, because it has numbers and the numbers are published. WCAG 2.2, criterion 2.5.8, says the target for pointer inputs is at least 24 by 24 CSS pixels, with the exceptions it lists itself: a smaller target with enough spacing around it, or where the same function is available another way on the page, or where the target sits inside a sentence. Android own accessibility guidance gives a larger number: at least 48 by 48 density independent pixels, with at least 8 units of separation between two targets, and it explains that 48 units works out at roughly nine physical millimetres on any screen.

That same Google page carries a point more useful than the number itself: the touch target extends beyond the visual bounds of the element. An icon that looks 24 units across becomes a 48 unit target through the padding around it. So you do not have to make the button big and ugly; you have to make the area that listens for the touch big.

And a warning about the number everybody quotes. "Apple says 44 by 44 points" is a sentence repeated in every article on mobile design in English and in Persian. We searched Apple Human Interface Guidelines today: the layout page, the accessibility page, the buttons page, the gestures page. The number is not written on any of them as a minimum touch target. The only place we found 44 points was a table of button sizes for visionOS, which is a different thing. So it is not that the number is wrong; we could not find a live source for it, and we would rather say we do not know than put words in Apple mouth. The numbers you can cite are the two above.

Should I follow the platform convention or use my own design?

Short answer: anything the user moves around with belongs to the platform, and anything that is your brand belongs to you. How the back button behaves, the edge swipe gesture, where the tab bar sits, how the keyboard acts and what the date picker looks like are all things your user has met a thousand times before installing your app. Change them and you have not been creative; you have taken away something the user already knew.

Colour, illustration, the tone of the copy, the onboarding screen and the product card are yours, and there being like everyone else buys you nothing. The practical boundary is simple: if changing something forces the user to learn it again, do not change it.

A point contractors usually mention late: keeping the platform convention is cheaper, not more expensive. Standard Android and iOS components already work with the system font size, with dark mode, with a screen reader and with right to left. A hand built copy of the same component has to rebuild all of that, and usually does not. Where you genuinely need a custom component, budget for all those states, not only for the happy one.

And a position you rarely see on a sales page: if your budget is tight, implement the conventions properly first and go after visual distinctiveness second. An app whose interface is ordinary but correct gets used more than one that is distinctive but confusing.

Where does a Persian screen break on a phone?

Right to left is not finished by one line of CSS, and this is where most Persian apps limp. Apple Human Interface Guidelines carry a whole page on right to left, and several of its rules are exactly the ones we keep running into in practice.

First, numbers. Apple says the order of the digits inside a specific number is never reversed: a phone number, a card number and the number 541 keep the same order in any direction. But the order of numerals that show progress or counting must be reversed, because the control itself has been mirrored. Those two rules look alike and in practice they are opposites.

Second, paragraph direction. Apple rule is that a block of three lines or more aligns to its own language rather than to the page direction, so an English paragraph inside a Persian screen stays left aligned; otherwise the start of every line gets lost. One and two line text goes with the page direction.

Third, icons. The back arrow has to point right in Persian, but a clock, a logo and a checkmark are never mirrored, and neither is an icon that genuinely points at a physical direction. Apple even makes a point that is rarely written down anywhere: Arabic and Hebrew text looks too small next to uppercased Latin because it has no capitals, and increasing it by about two points restores the balance. The same holds for Persian.

Fourth, something invisible on desktop that shows up immediately on a phone: the numeric keyboard. If your input does not convert Persian digits to Latin before validating, a user typing their number on a Persian keyboard gets an invalid number message and has no idea why. That is a design error, not a user error.

The states nobody ever draws in the first pass

Any screen that fetches data has at least five states, and the first design usually shows one of them. The empty state, when there is nothing yet. The loading state, while it is coming. The error state, when it did not come. The offline state, which is common on mobile and rare on desktop. And the full state, the picture that got drawn in Figma.

That is what feedback means. After a tap, a mobile user must see a sign within a fraction of a second that the tap registered, even if the server takes two seconds to answer. Without that sign the same button gets pressed again and you have a duplicate order. Offline is a real state on a phone rather than an edge case: the lift, the underground, the car park.

Consistency can be counted here too. Pick one pattern for showing an error across the whole app and use it everywhere. If one screen puts the error above the form, another under the field and a third inside a floating message, the user has to hunt for the error every time.

And the last item, which is really the first thing to do: open the app on your own phone with the system font size turned up and in sunlight. Most of the problems listed in this lesson surface in that one minute, long before any formal review.