Design tip5 min read
How to choose the right interface
Users and context first, then platform conventions, right-to-left and accessibility, with cheap tests before you build.

A delivery driver checks the next drop with one thumb, standing in bright sun between stops. At head office, an operations manager follows the same deliveries on a wide monitor all day. Same data, two interfaces, each one right for a different person in a different place.
Start from users, context and tasks
Choosing an interface starts long before colours and components. The UK government’s Service Manual puts it plainly: without understanding who your users are and what they need, “you cannot build the right thing.” It suggests learning who your users are, what they are trying to do, how they do it today and where it goes wrong.
In practice, ask:
- Who? Experts who use the product every day, or people who open it once a month and have forgotten how it works.
- Where? On a phone in a car park, on a laptop in a meeting, on a shared tablet in a shop.
- Doing what? One quick task, such as paying a bill, or long sessions of comparing and editing data.
- In which language? Arabic, English or both on the same screen.
Native conventions or a custom interface
Each platform publishes its own rules. Apple’s Human Interface Guidelines show how to use and customise system components “to give people a familiar and consistent experience,” and how to make an app that “feels at home” on each platform. On iPhone, for example, Apple asks apps to let people swipe to go back. On Android, Google’s Material Design 3 comes built into Jetpack Compose, including dynamic colour, which on Android 12 and above takes an app’s colours from the user’s wallpaper.
Native components give you a lot for free: behaviour people already know and, as Apple points out, controls that can flip automatically for right-to-left languages. A fully custom interface lets the brand stand out, but you then rebuild and maintain all of that yourself.
For most products the sensible middle path is to keep navigation, controls and gestures native, and express the brand through colour, typography, imagery and words.
Designing for right-to-left and Arabic
Right-to-left (RTL) means more than aligning text to the right:
- Set direction at the root. The W3C advises setting the dir attribute to rtl on the page’s html element and to “never use CSS to apply the base direction.” For fields where people type, dir set to auto lets the browser detect it. On Android, use start and end instead of left and right, and declare android:supportsRtl in the app manifest.
- Mirror what has direction. Apple asks you to flip navigation, so a back button points right, along with progress bars and icons that show reading direction or motion.
- Leave the rest alone. Phone and card numbers keep their digit order. Logos, universal marks such as the checkmark, objects like clocks and photographs stay as they are.
- Choose your numerals. Apple notes that Arabic text might use Western digits (1, 2, 3) or Eastern Arabic digits (١، ٢، ٣), depending on country and region. Decide per market and stay consistent.
- Respect the script. Arabic is cursive: letters join and change shape with their position in a word, as the W3C’s Arabic and Persian layout requirements describe. Pick a typeface designed for Arabic on screens. Next to uppercase Latin text, Apple suggests setting Arabic about 2 points larger so the two look balanced.
Density, accessibility and familiarity
Density is how much fits on a screen. Material Design uses low density by default and offers higher density “when it improves the user experience,” mainly for lists, tables and long forms. The documentation for its web components warns that applying density turns off the standard touch targets, so higher density should be a deliberate choice.
Accessibility sets the floor. At level AA, WCAG 2.2, the W3C’s accessibility standard, asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, text that can be enlarged to 200% without losing content and layouts that work at a width of 320 CSS pixels without scrolling in two directions.
Familiarity is the quiet one. Jakob Nielsen observed in 2000 that “users spend most of their time on other sites,” so they expect yours to work like the ones they already know. NN/g calls this Jakob’s law. Put search, the basket and the menu where people already look for them, and save novelty for what makes your product different.
Test before you commit
You don’t need a finished product to learn whether an interface works. Nielsen describes paper prototyping as “one of the fastest and cheapest techniques” in a design process, and a clickable prototype in Figma serves the same purpose.
How many people? Nielsen’s model suggests five users find about 85% of usability problems, and that three rounds of five, with fixes in between, teach you more than one round of fifteen. If your audience splits into distinct groups, test three or four people from each group. For an Arabic product, that means Arabic-speaking users on their own devices, in conditions close to real use. If two directions both seem plausible, test both with the same tasks.
The takeaway
There is no best interface, only one that fits a specific person, place and task. Start with users and context, lean on platform conventions, treat right-to-left and accessibility as requirements from day one and test cheap versions before you build the expensive one.
Sources
- Start by learning user needs, GOV.UK Service Manual
- Human Interface Guidelines, Apple
- Designing for iOS, Apple Human Interface Guidelines
- Right to left, Apple Human Interface Guidelines
- Material Design 3 in Compose, Android Developers
- Support different languages and cultures, Android Developers
- Structural markup and right-to-left text in HTML, W3C Internationalization
- Arabic & Persian Layout Requirements, W3C, 2025
- Density, Material Components for the Web, Google
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C
- End of Web Design, Jakob Nielsen, Nielsen Norman Group, 2000
- Jakob’s Law of Internet User Experience, Nielsen Norman Group, 2017
- Paper Prototyping: Getting User Data Before You Code, Jakob Nielsen, Nielsen Norman Group, 2003
- Why You Only Need to Test with 5 Users, Jakob Nielsen, Nielsen Norman Group, 2000

