Algeria AgencyBranding & design
UI/UX: an interface is judged on a task completed
Not on how it looks. Name the five things people come to do, watch five people do them, and fix what blocks them.
Interface design is filed with graphic design and differs from it in its success criterion: an identity is judged on what it expresses, an interface on whether a person finished what they came to do.
That criterion has an unwelcome consequence for both sides. An interface cannot be approved in a meeting, on a large screen, by people who already know where every button is. It is approved by watching somebody who knows nothing use it on their own phone.
This article handles what really decides here: the area a thumb reaches, the size of targets, and two subjects foreign manuals do not cover because they do not meet them — an interface that has to work in Arabic, and language switching as a front-line function.
It also handles the part that breaks projects: the states nobody draws. A developer who receives only the screen where everything goes well invents the other four, and that is where half the rework lives.
The criterion is a task completed
An interface is judged not on what it displays but on what it allows. The test is binary and not up for discussion: did the person finish, alone, without being told how?
That disqualifies approval in a meeting. Around a table everybody knows the structure, knows what each button does, and is looking at a twenty-seven-inch screen. None of those three conditions is the customer’s.
It also disqualifies the vocabulary of taste. "I do not like that blue" is not usable feedback; "I could not find how to go back" is. The first sentence opens a negotiation, the second closes a defect.
The method consequence is that the work begins and ends with observation. You watch people do things before drawing, then watch people do things with what you drew. Section 7 describes how, because the way of watching changes the result entirely.
And it fixes what a successful deliverable is: not a mock-up people like, but a set of tasks five people completed unaided. That is a criterion you can write into a quotation, and we do.
The five things people come to do
Before drawing anything, the list of tasks has to be written. Not the site’s sections — the tasks, phrased as the person would say them: "find out whether you have my size", "know the price with delivery", "find my order", "know whether you are open now", "reach somebody".
The real list nearly always comes to five entries. Beyond that they are variants or rare tasks, and treating them at the same level as the first five is what produces an eleven-item navigation where nothing stands out.
Those five tasks are not invented: they are drawn from the incoming messages, as the content-marketing article describes. It is the same survey used to write the pages, and that is natural — people ask about what they could not find.
Once written, the list arbitrates everything else. Each element added to a screen has to serve one of the five; if it serves none, it takes up room and takes room from the ones that matter.
It is also what allows a request for an addition to be refused cleanly. "That serves none of the five tasks" is a checkable argument, where "that makes the page heavier" is one opinion against another.
The thumb, and the hand holding something else
A local interface is used one-handed, often standing, often with the other hand holding a bag, a child or a car key. That is not an image: it is the main layout constraint.
A hand holding a phone comfortably reaches the lower half of the screen and reaches the edge opposite the thumb very badly. Frequent actions therefore go at the bottom, and the top of the screen is reserved for what is displayed rather than what is touched.
The most frequently broken consequence: the main button on a long page must not be at the top. It has to be where the thumb is when the person has finished reading, which is at the bottom, and it has to repeat if the page is long — the landing-page article says the same for its own case.
A second consequence, particular to the phones we actually see: the devices are large and many carry a thick case. That shrinks the reachable area and increases imprecise taps, which is paid for on targets that are too small or too close together.
And one constraint mock-ups consistently hide: the real screen is cut in half by the keyboard as soon as a field is active. The lower half disappears, and it is exactly the half where the button was put. That case gets drawn; it does not get discovered.
The size of a target
The size of touchable areas is the only point on this page for which a published, checkable threshold exists, and it is worth knowing because it is very often missed.
The web consortium’s accessibility guidelines set two markers. A minimum, introduced in the most recent version: twenty-four pixels across. And an enhanced threshold, older: forty-four pixels across.
The useful reading is practical rather than regulatory. Twenty-four pixels is roughly what a finger touches without aiming; forty-four is what a finger touches while walking, with a case on, without looking closely.
What fails in the interfaces we audit is almost never the main button: it is the small targets. The cross that closes a window, the terms checkbox, a carousel’s arrows, the quantity selector, the unsubscribe link.
One point that matters as much as size and has no threshold: spacing. Two correctly sized targets pressed against each other produce selection errors, and the most expensive mistake we have seen was a "delete" button three pixels from a "confirm" button.
W3C Web Content Accessibility Guidelines, versions 2.2 (2023) and 2.1 (2018)
Arabic is not French reversed
An interface that has to work in Arabic is not the French version put through a mirror. It is the subject imported manuals do not cover, and the one where we see the most expensive errors.
What flips: reading direction, therefore text alignment, the position of labels relative to fields, the order of table columns, the direction of a progression, and the place of the back control. All of that follows the direction and has to follow it automatically.
What does not flip: numerals, amounts, telephone numbers, times, product references. They read left to right inside a sentence running right to left, and treating them as ordinary text produces unreadable amounts and wrong references. The trap moves when the Arabic is produced by a machine rather than written, where eight places in the interface break without the text being wrong.
Icons require a decision rather than a transform. A progress arrow flips; a clock, a logo, a telephone icon do not. Flipping everything by reflex produces absurd symbols nobody notices before launch.
Finally, length changes. The same message is often shorter in Arabic than in French, sometimes markedly, and a layout pinned to the pixel on the French version leaves empty blocks or unbalanced buttons. The mock-up has to be checked in both directions, not translated afterwards.
Language switching is not a flag in the footer
On a trilingual site, choosing a language is one of section 1’s five tasks, and it is almost always treated as a footer detail. That is an error of hierarchy rather than of taste.
The selector has to be visible without scrolling, on every page, and it has to keep the page you are on. Sending people back to the home page on a language change is the commonest and most irritating behaviour: they lose what they were reading and start again.
Flags are to be avoided, for a simple and rarely stated reason: a flag denotes a country, not a language. Write the languages in their own script, which also solves the problem of somebody who cannot read the one currently displayed.
The chosen language has to be remembered, and the choice has to stay changeable. Automatic detection that imposes a language with no way to change it is the worst of both, and it is often wrong on devices configured in a language the person does not read comfortably.
One last point belonging to the brand as much as to the interface: the three versions have to carry the same information. An Arabic version missing half the pages is a commercial decision dressed as a technical constraint, and customers read it that way.
The states nobody draws
A conventional mock-up shows a full screen, with attractive data, in the case where everything works. That is a fifth of the job, and the other four fifths are what decide perceived quality.
The empty state: the first time, there is nothing. No order, no favourite, no history. An undrawn empty screen becomes a blank screen, and the user believes it is broken when they simply have nothing yet.
The loading state: on a mobile connection it lasts. It has to show that something is happening and, better, where. A screen frozen for four seconds produces a second tap, and therefore sometimes a second order.
The error state: it has to say what happened and what to do, in the person’s language. "An error occurred" meets neither condition. "The number has to start with 0" meets both.
And the partial state, which almost nobody plans for: the list that half loads, the missing photograph, the unavailable price. It is the commonest case on an average connection, and an interface that did not plan for it shows holes where the developer assumed data.
Watching five people: the method
The article on comparison testing points here: when traffic does not allow measurement, you watch. Five people are enough to find most of the major faults, and the way of watching decides what gets found.
The protocol comes to four rules. You give a task, not an explanation: "find the price of this model delivered to Blida". You say nothing during. You write down what the person does, not what they say. And you never defend the interface, however much you want to.
Silence is the hard part. The moment you help, you get a pleasant conversation and no information: the person finishes the task thanks to you, and the defect survives. Count to ten before intervening, and only intervene if they want to stop.
What to note is short: which screen they hesitate on, what they touch that is not tappable, what they look for and cannot find, and whether they finish. Four columns, five rows, one sheet.
Who the people are matters less than people think — they need to resemble your customers and not know the product. Your employees will not do: they know where things are, and that is precisely what is being tested.
The interface nobody designs: your employees’
The design budget goes to the public site, and the screen somebody uses two hundred times a day receives none of it. It is a poor arithmetic split, and it costs hours every day.
Internal interfaces have a property that changes everything: the user is expert and repetitive. They do not search, they know. So what matters is not discoverability but the number of gestures, the stable position of elements, and shortcuts.
The most frequent gains we find are crude. A field in the wrong place in the entry order, a pointless confirmation on every save, a form that loses its context on every submit, a search that does not search on the reference.
The method is the same as for the public one, with an advantage: the people are available and they already know the defects. A morning spent beside two employees produces a list of corrections each saving a few seconds multiplied by hundreds.
It is also the only place in this article where the return is simple to calculate: three seconds saved on an operation repeated a hundred times a day is an hour a week per person. No public screen is justified that easily.
What already exists in your customers’ phones
The best interface is the one the user already knows. It is a textbook sentence, and it has a concrete reach: the gestures, icons and positions installed by the operating system and the large apps are free assets.
Going back happens with a gesture or an arrow at the top left — top right in Arabic. The cross closes, the magnifier searches, three dots open a secondary menu. Reinventing one of those signs does not produce originality, it produces learning charged to the customer.
The rule that follows: you invent where the trade is particular, and nowhere else. A clinic, a workshop or a carrier have their own needs deserving their own screens; they do not need an original close button.
There is a useful local exception: the habits installed by messaging apps, which are what most people use most. A thread, an attachment, a send button on the right — those conventions are more familiar to your customers than a management package’s.
And a design consequence: when you hesitate between two ways of presenting something, look at how it is presented in the app your customers open twenty times a day. That is not copying, it is saving on learning.
What a developer has to receive
Interface quality is most often lost at handover rather than in design. A developer who receives three images and a palette takes dozens of decisions on your behalf, and takes them alone and fast.
What has to be handed over, at minimum: the five main screens in all three languages, with section 6’s four states for each. That is the part that triples the volume of the deliverable and halves the number of reworks.
Then rules rather than pixels: what text size, what spacing between blocks, what maximum content width, what behaviour at width breaks. A developer applies a rule to fifty screens; they cannot infer a rule from three images.
Then the edge cases, written down: the very long name, the six-figure price, the one-item list, the Arabic text shorter than expected, the missing image. Those five reveal half the layout faults before they are built.
And finally the list of tasks from section 1, handed over as it stands. It is what lets a developer decide when the mock-up did not plan for a case: they pick the solution that serves the task, which is nearly always the right one.
What we do, and what we will refuse to do
What we will refuse: delivering screens without their empty, loading, error and partial states. That is half the real work, it is invisible in a presentation, and its absence is what produces the reworks the client pays for afterwards.
We will refuse to approve an interface in a meeting without a single outside person having tried it. Collective approval around a large screen measures consensus, not use, and the two are unrelated.
We will refuse to deliver an Arabic version obtained by flipping the French one, and to flip icons by reflex. Numerals, amounts and references stay in their own direction; a clock does not flip.
What we do: the list of five tasks written from your incoming messages; reachable areas and target sizes checked on a real phone with a case; the three languages drawn rather than translated; the four states for every screen; the five-person observation session before and after; and the handover of rules rather than images.
And what you can do this week without us: ask two people who do not know your site to find the price of a product delivered to them, on their phone, saying nothing while they look. Note which screen they hesitate on. Half an hour, two people, and you will have more information than any approval meeting.
Frequently asked questions
How do we know whether our interface is good?
Write down the five things people come to do, then watch five people do them on their own phones without helping. The criterion is binary: the task is finished without explanation, or it is not.
How large should buttons be?
Twenty-four pixels across as a minimum and forty-four for comfortable use, per the web consortium’s accessibility guidelines. What fails is almost never the main button — it is close crosses, checkboxes and arrows.
Can the Arabic version be made by flipping the French one?
No. Reading direction flips, but numerals, amounts and references do not, and icons require a decision: an arrow flips, a clock does not. Text length changes too, often markedly.
Where should the language selector go?
Visible without scrolling, on every page, keeping the page you are on. Write the languages in their own script rather than using flags — a flag denotes a country, not a language.
What should a mock-up handed to a developer contain?
The screens in all three languages with their empty, loading, error and partial states; spacing and size rules rather than pixels; five written edge cases; and the list of five tasks, which lets them decide what the mock-up did not plan for.
Should internal screens be designed too?
It is often the best return available. Three seconds saved on an operation repeated a hundred times a day is an hour a week per person, and a morning beside two employees is enough to draw up the list.
Where we come in
Two people hesitating show you a screen. They do not tell you whether structure, slowness, or a mirrored Arabic build was what stopped them.
- We run the path again on an entry-level handset, on mobile data rather than wifi.
- We measure with a thumb what can actually be reached, screen by screen.
- We hand back the blockages ranked by what each costs to fix.
If your two witnesses found the price without hesitating, the interface is not your subject: the problem is further up, in what brings them there.
Read next
An AI writing in Arabic: what breaks in your interface
The Arabic a model produces is correct and your screen no longer is. Here are the eight places it breaks, and the check that finds them in an hour.Repairing an interface without rebuilding it: where to start
A redesign is the most expensive answer and rarely the right one. How to find the layer the fault is actually in, and fix it there.A small business’s visual identity: what works and what decorates
A logo is not an identity. What is almost always missing is what happens the day after it is delivered.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.