The person who uses it 200 times pays for the design
Every extra click is two hundred clicks, and every slow modal is two hundred waits. The screen was designed for a demonstration, not for a Tuesday.
Services
UI and UX design
The software was approved in a meeting, built around the data, and handed to people who use it two hundred times a day. That is where it fails: not in the feature list, but in the eleven clicks between a customer's name and a receipt in the printer. Interface work is counting those clicks and deciding which ones to remove, and in what order.
Who it is for
- Teams whose software is accurate and still slow to use at the counter.
- Managers who hear "the system is difficult" and cannot tell which screen causes it.
- Products about to add Arabic and discovering the layout was built for one direction.
Problems it solves
Whitespace bought with hidden information
The table shows six columns and hides the rest behind a click so it can breathe. Whoever works on it opens every row to know what it contains.
Errors explain the database, not the mistake
A constraint violation appears on a screen where the operator only chose a customer. The message does not say what happened or what was not saved.
Use cases
A counter screen rebuilt for speed
Keyboard entry, the barcode field focused on load, and the total and the change visible without scrolling.
Arabic and RTL as the default layout
Mirrored navigation, logical spacing, numbers and dates that read correctly, and no letter-spacing on joined script.
A dense table that stays readable
A calculated row height, a sticky header, a filter that survives navigation, and columns the operator can hide.
Error and empty states written for the operator
What happened, what to do now, and what was not saved. Three short sentences instead of an error code.
What is in scope
Fixed scope. Fixed price.
Agreed in writing before anything is built. You approve before we start.
- A short usability audit of the screens that generate the most calls
- A task list taken from real work: the five things done most often
- Wireframes in both directions, Arabic and Latin
- A design system: spacing, type scale, form states, table behaviour
- A prototype tested with two or three of the people who do the work
- Handover: components named and documented for whoever builds them
How it is delivered
- 01
Watch someone do the task
Not a demonstration. The real task, on real data, with the interruptions that actually happen.
- 02
Count the steps
Two hundred times a day turns one click into a week of work. Counting is how a change gets prioritised instead of argued about.
- 03
Change the smallest thing that removes the pain
A screen does not need a new visual language because the buttons are in the wrong order.
- 04
Test with the operator, not the manager
The manager approves the direction; the operator decides whether it is usable. These are two different tests and only one of them is handed to us honestly.
FAQ
Questions about this service.
What owners usually ask before requesting a quote for it.
Do we need a full redesign?
Usually not. Two or three screens cause most of the complaints, and fixing those gives more than redesigning everything at half the quality.
How do you handle Arabic and RTL?
Arabic is designed first or at the same time, never after the space is filled. Navigation, tables, forms and numbers are checked in both directions, because a layout that works one way shows its fault in the other.
What if the team resists the change?
Resistance is usually a sign the new screen was not tested with the people who use it. We train, keep the old way available for a fixed period, and measure which is faster.
Is this just a new coat of paint?
If the workflow itself is wrong, no visual change fixes it. Sometimes the honest answer is a change in the process rather than the interface, and we will say that instead of invoicing a redesign.
Start a project
Want this scoped for your business?
Send the brief. It comes back as a written scope and a fixed quote before anything is built.