UX/UI Design Principles: From Nielsen's Heuristics to an Arabic RTL Interface

Twenty screens are on the Figma board, they all look attractive, and the question you cannot phrase is: are these screens correct? UX/UI design principles are the vocabulary that answers it — rules published since the 1990s, some of them resting on a peer-reviewed paper, all of them convertible into a specific, actionable objection. "This button doesn't tell me what happened after I tapped it" is something a designer can work with. "I don't like it" is not.

This guide covers three layers: Jakob Nielsen's ten usability heuristics, four laws with an experimental basis along with the limits that usually get dropped, and the decisions that belong to Arabic interfaces read from right to left — the layer that falls out of every English reference because it simply isn't its problem.

UX and UI: where the difference actually lands in your project

User experience (UX) answers one question: what steps does a person go through to reach what they came for, and what does that cost them in attention and time? User interface (UI) answers the next one: how does each step look on screen. The difference shows up in the kind of failure you see after launch. A UX failure: customers reach the payment page and then call to ask about shipping, because the cost only appeared after they entered an address. A UI failure: the button sits in the right place, but its colour against its background cannot be read in sunlight on a phone.

The practical rule: UX decisions are settled in prototypes before anyone writes a line of code, and correcting them after development means changing the database and the integrations, not a colour. Changing UI decisions costs less, as long as a unified design system keeps the change in one place. If you are still choosing who will do this stage, the contract questions are in how to choose a UI/UX design agency, and the pricing components in the UI/UX design cost guide.

The ten usability heuristics: where they come from and how to use them

Jakob Nielsen published his list on 24 April 1994, and the page was last reviewed on 30 January 2024. Its origin is older: he developed it with Rolf Molich in 1990, then refined it based on a factor analysis of 249 usability problems to arrive at the set with the greatest explanatory power. He calls them heuristics because they are "broad rules of thumb and not specific usability guidelines": questions you put to a screen, not specifications to be implemented literally. They appear here in four groups by the question each one answers, because memorising ten bullet points helps nobody during a review.

Does the user know what is happening?

1. Visibility of system status. The interface keeps the user informed through appropriate feedback within a reasonable time. InstaPay in Egypt is a direct example: its FAQ page states three transaction states — successful, rejected with the amount reversed to the sender's account, and pending, meaning it was sent to the beneficiary bank and will be updated shortly. The third state is the one most local systems forget: the success path and the failure path get designed, "in progress" is left without a screen, and the gap turns into a call to customer service.

9. Help users recognise, diagnose and recover from errors. Error messages are written in human language, describe the problem, and suggest a fix. NN/g's error-message guidelines add three points that are easy to skip: show the message close to the source of the error rather than at the top of the page; do not show it prematurely, because flagging an error the moment focus leaves an empty field treats exploration as a fault; and do not blame the user with words like "invalid" or "incorrect".

Does the interface speak the user's language?

2. Match between the system and the real world. Use your users' words, not your internal terms. The clearest local application is address fields. The "Address line 1 / line 2 / ZIP code" form is translated from American templates, while the Saudi National Address has published components: a four-digit building number, a street, a four-digit secondary number, a district, a five-digit postal code and a city — plus a short address of four letters and four numbers. Fields that match what the customer reads in a government app get filled correctly the first time.

4. Consistency and standards. Nielsen distinguishes internal consistency (the same button means the same thing on every screen you own) from external consistency with industry conventions. Internal consistency is a question of structure rather than discipline: it is set once in the component layer, explained in detail in the design systems guide.

10. Help and documentation. It is best if the system needs no explanation; when it does, the help belongs in the context of the task with concrete steps, not on an FAQ page everyone is referred to.

Can the user go back?

3. User control and freedom. People act by mistake, so they need a clearly marked emergency exit: undo, a visible cancel, and a labelled way out.

5. Error prevention. The best error message is the one that never appears. The heuristics text makes a useful distinction here: slips are unconscious errors caused by inattention, addressed with constraints and good defaults; mistakes are conscious errors caused by a gap between the user's mental model and the design, addressed by reducing memory load and confirming before committing. A numeric example: InstaPay's published transfer limits as of September 2026 are EGP 70,000 per transaction and EGP 120,000 daily per bank. Showing that limit before the user types an amount is error prevention; showing it after they press "transfer" is an error message.

How much are you asking their memory to carry?

6. Recognition rather than recall. Keep options visible instead of making users retrieve them from memory. Saudi Arabia's Nafath app is a clear example: the user guide published by SDAIA shows on page eight a "request number" screen with three two-digit options and the instruction to pick the number displayed by the service provider. No code is copied from a message into a field; you recognise a number you can see. That flow and its alternatives are covered in identity verification in Saudi apps.

7. Flexibility and efficiency of use. Shortcuts hidden from the novice speed up the expert: search by SKU for the warehouse clerk, one-tap reorder for the repeat customer.

8. Aesthetic and minimalist design. Every extra unit of information on a screen competes with the important one and reduces its relative visibility. The goal is a visual priority order that serves the user's objective, not an empty interface.

Four laws with a paper behind them — and with limits

Articles pass these laws around as slogans. It is more useful to know what the original experiment actually measured, because their limits are what stop you applying them in the wrong place.

Fitts's law (1954): size and distance

Paul Fitts published his paper in the Journal of Experimental Psychology in 1954: the time for a pointer to reach a target depends on the target's size and the distance to it, and the relationship is logarithmic rather than linear. NN/g's explanation adds two practical details: error rates fall as targets grow, and an icon with a label is a larger target than the icon alone, provided the whole area is clickable. The decision that follows: put the submit button next to the last field in the form, not at the top of the screen.

And the limit: the familiar claim that screen edges are "infinite targets" holds for the mouse, because the cursor stops at the edge and needs no deceleration. On touchscreens, Avrahami's study at CHI 2015 found the opposite — targets at the edges take longer — so a toolbar pinned to the edge of a phone screen in the name of Fitts's law is the law applied out of context.

Hick's law (1952): the number of choices

W. E. Hick published "On the rate of gain of information" in the Quarterly Journal of Experimental Psychology in 1952, followed by Ray Hyman in 1953. The commonly cited form, as Proctor and Schneider's review in the same journal in 2018 reports it, is RT = a + b log2 n for equally likely alternatives.

Look at the experiment before generalising: ten lamps arranged in a small irregular circle, ten fingers resting on response keys. That is not a user scanning a menu. The same review notes that Longstreth concluded in 1988 that the law does not apply beyond about eight alternatives, and that Seibel in 1963 confined the linear relationship to between two and eight.

Correct use: on a single decision screen (account type, payment method, plan) every extra option delays the decision, so remove what nobody picks. Incorrect use: shortening a store's category list because "Hick said so", when a list is scanned by eye rather than compared option by option.

Jakob's law (2000): expectations built elsewhere

Nielsen stated it in "End of Web Design" on 22 July 2000: "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know".

In Egypt and the Gulf specifically, your customer's expectations were built in their banking app, their delivery app and their government app. The cart is a cart icon, back is an arrow, the account lives in the corner. Innovating on those elements charges a learning cost nobody will pay; innovate where your product is genuinely different and follow convention everywhere else.

Miller's law (1956): chunks, not seven

George Miller's paper "The Magical Number Seven, Plus or Minus Two" appeared in Psychological Review in 1956. What it actually says: the span of immediate memory is a fixed number of chunks, and recoding — grouping inputs into larger units — increases what a single chunk carries. Miller closed the paper by suspecting that the recurrence of seven across different domains is "only a pernicious, Pythagorean coincidence". Nielsen settled the most common misuse in an article on short-term memory: believing that memory limits force menus of seven items is "a common misconception", because a menu relies on recognition, not recall.

So the decision that follows from Miller concerns chunking long numbers, not menu length: account, card and phone numbers are displayed and entered in groups. The same idea sits behind InstaPay's instant payment address in the form name@InstaPay instead of sharing a full account number — one hard-to-carry chunk replaced by one that sticks.

Right-to-left design: the decisions English references leave out

Mirroring an interface is not an "RTL" toggle in a design tool. Material Design's bidirectionality documentation and Apple's right-to-left guidelines agree that mirroring is the default, and the exceptions are what separate a sound Arabic interface from a literally flipped one.

What mirrors and what does not

Direction of progress in forms and steppers

The costliest mistake here is mirroring the layout while the progress indicators keep their left-to-right logic: a stepper that starts on the left in a screen read from the right, so the user thinks they are on the last step when they are on the first. The rule: anything representing elapsed time or progress towards completion starts on the right. The same applies to tabs — in an Arabic screen the user swipes right to reach the next ones.

One detail from Apple's guidelines is useful in forms: numerals that indicate progress or counting are reversed in order to match the mirrored control, while the digits of a single number are never reversed, since a phone number and a card number read in the same order in every language.

Numbers and dates inside Arabic text

A number in Arabic text is written left to right even inside a line read from the right, and that is normal behaviour rather than a bug. What does produce a real fault is mixing digit shapes within one page, and the unexpected ordering that follows around currencies, percentages and dates; the details and examples are in the web accessibility guide for Arabic sites.

The decision required of you: pick one digit form and keep it across the whole interface, and fix the date and currency formats in the design system rather than on each screen. Untranslated text (links, product codes, file names) stays in its Latin order inside the Arabic paragraph, as Material's documentation states.

Arabic type next to Latin text

You will notice an Arabic word looking smaller beside an English word in capitals inside a button or a heading, because Arabic has no uppercase letters. Apple's guidelines recommend increasing the Arabic font size by about two points for visual balance — one of the cases where using the same size for both languages fails.

Accessibility as a principle, not an add-on

Accessibility is not an item appended at the end of a project, because three of its decisions are taken in the first week of design:

• Contrast. WCAG 2.2 requires a ratio of at least 4.5:1 for body text and 3:1 for large text. The number is not arbitrary: the W3C document explains that 20/40 visual acuity is associated with a contrast sensitivity loss of roughly 1.5, so 3 × 1.5 = 4.5:1. This is settled in the colour palette before any screen is drawn.
• Touch target size. WCAG 2.2 sets a minimum of 24×24 CSS pixels, while Material's documentation recommends 48×48dp (about 9mm in physical size), and on iOS the recommendation is 44×44 points. They do not contradict each other: the first is a conformance floor, the second a comfortable-design recommendation. Design to the platform recommendation.
• Keyboard navigation. Every function must work from the keyboard. An admin dashboard used eight hours a day gains more from this than from any visual improvement.

Mistakes that cost money, and the number that exposes each one

Off-the-shelf statistics about "cart abandonment rate" tell you nothing about your product. It is more useful to know where each mistake shows up in your own data.

Every line here is a measure you can pull from your own dashboard within a day, with no market research. If those numbers belong to a specific landing page, how to measure them is in landing page design, while techniques aimed at lifting conversion are in design that raises conversion.

How to review a screen before you approve it

Review it with the rules, not with taste. In front of each main screen, ask six questions:

1. If I tap here, will the screen tell me what happened? And where is the waiting state?
2. Are these my customer's words or our internal ones?
3. Where is undo or cancel on this screen?
4. What am I being asked to carry in my head from a previous screen?
5. In sunlight, with one hand, can I reach the primary button?
6. What breaks if this screen is read from the right: arrows, the stepper, button order, the icon's position in a field?

Three people reviewing the same screens separately and then comparing notes find several times what one person finds; that is the basis of the heuristic evaluation method the rules were written for in 1990. And when you need to know your customers' language rather than assume it, the methods are in user research.

The rules above do not make a product succeed on their own, but they prevent most of what gets fixed later at a higher price. If you are planning an app, a site or an Arabic admin dashboard, put your idea in front of the Snaabble team: within 24 hours you get an outline of the scope and an estimate of time and cost, at no charge and with no commitment.

Sources

• Nielsen Norman Group: 10 Usability Heuristics (1994, reviewed 2024), Fitts's Law (2022), End of Web Design (2000), Short-Term Memory and Web Usability (2009), Error-Message Guidelines.
• Hick's law for choice reaction time: a review, Proctor & Schneider, Quarterly Journal of Experimental Psychology, 2018.
• The Magical Number Seven, Plus or Minus Two, George A. Miller, Psychological Review, 1956.
• Material Design: Bidirectionality and Accessibility.
• Right to left, Apple Human Interface Guidelines.
• Understanding SC 1.4.3 Contrast (Minimum), W3C WAI.
• FAQ, InstaPay; Nafath user guide, SDAIA; National Address, Saudi Post.