UI/UX Design
If your team keeps a cheat sheet for using your own software, and support answers the same where-do-I-click question every week, the interface is what is costing you.
Somebody on your team made a document explaining how to use your own system. It has screenshots with red arrows drawn on them. New staff are sent it on their first day, and whoever wrote it updates it every time a screen changes.
The same signs turn up elsewhere. A support inbox answering the same question about where to find something. A form that a quarter of the people who start never finish. A feature you paid to build that almost nobody opens. An Arabic version that looks like the English one flipped in a mirror, with the icons pointing the wrong way and the numbers in odd places.
None of that is a training problem. It is a design problem, and design problems are cheaper to fix than to keep paying for.
What we actually do
Watching people use what you already have
We start with what exists rather than a blank canvas. An hour spent beside a few real users doing a real task tells you more than a month of internal debate: where they hesitate, what they misread, which button they never see because it sits where nobody looks. Your support tickets are a second, free record of every place the interface has already failed.
Structure before appearance
Then arrangement: what belongs on which screen, what a person has to decide and when, and what can be removed altogether. Most difficult interfaces are not ugly, they are overloaded, because every request from every stakeholder was granted. Deciding what not to show is the larger half of the job. Flows are tested as clickable prototypes before anything is made to look finished.
Arabic and English as equals
Right-to-left is not a mirror image. Numbers, dates, mixed Arabic and Latin text, icon direction, form alignment and comfortable line length all behave differently, and a layout designed only left-to-right reads as wrong to Arabic-speaking users in ways they notice immediately even if they cannot name them. We design both directions from the beginning rather than adapting one into the other at the end.
What you get
- A findings report from user sessions and a review of your support tickets, with issues ranked by how much they cost you
- Flows and wireframes for the screens that carry the work
- A clickable prototype you can put in front of real users before development starts
- Interface designs for the agreed screens in Arabic and English, on mobile and desktop
- A component library and style guide so screens added later stay consistent
- Design files handed over in a form your developers, or ours, can build from directly
- Designer availability during the build, so the details get decided rather than guessed
Why Netronsoft
We test with users instead of arguing about taste. Five people attempting a real task settle most disagreements in a meeting faster than any amount of internal opinion.
We will tell you when a redesign is not the answer. If your users are frustrated because a report takes forty seconds to load, new visuals will not help, and we would rather say so than sell you a project that does not fix it.
Arabic gets designed, not translated. That is ordinary practice for us and it changes how the layout is built from the first screen.
Our designers work alongside engineers, so what you receive can actually be built at a sensible cost, and the person who designed it is reachable while it is being built.
Questions people ask before they call
Do we need a full redesign? Often not. Frequently three or four screens carry most of the pain, and fixing those is faster, cheaper and less disruptive than redoing everything.
How do you know a new design is better? Because we watch people use it. Task completion, hesitation and error rates are observable, and they settle arguments that opinions cannot.
Can you work with our existing brand? Yes. If you have brand guidelines we design inside them, and if you do not we will keep to a restrained set of colours, type and components you can extend later.
Mobile first or desktop first? Whichever your users are actually on, which your analytics already answer. For internal systems that people use all day on a laptop, designing mobile-first can be the wrong call.
What if our real problem is speed, not design? Then we say so, and it becomes an engineering job rather than a design one. It is a common finding and it is not one we hide.
What do our developers actually receive? Design files with the components, spacing, states and behaviours documented, in both directions, plus a walkthrough. Not a flat picture they have to guess from.
How many users do you need to test with? Fewer than people expect. A handful of the right users, watched properly at each round, surfaces most serious problems.
Can you build it as well? Yes. Design, web and mobile development sit in the same team here, so the design does not have to be handed across a wall — though we are happy to hand over to your own developers instead.
Let's talk it through
Send us a link, or a few screenshots of the screens people complain about most. We will tell you what we would look at first, whether the problem is really the interface, and whether a focused piece of work would fix most of it.
Message us on WhatsApp, call +962 7 9087 9419, or email [email protected]. If you have support tickets or analytics showing where people drop off, those make the first conversation much more useful.
What's included
Benefits
Design that follows the work
Screens shaped around the task your users are actually doing, rather than around a visual trend that will look dated in two years.
Fewer questions about where to click
When the interface answers the question itself, the internal cheat sheet stops being necessary and support stops repeating the same explanation.
Arabic designed, not mirrored
Right-to-left layouts built from the start, with numbers, mixed text, icons and alignment handled properly instead of flipped and hoped for.
Right on the device people use
Designed for the screen your analytics say your users are on, with the small-screen version treated as a real design rather than a squeeze.
Tested before it is built
A clickable prototype put in front of real users settles disagreements while changes still cost an afternoon instead of a development cycle.
A handover developers can build from
Components, states, spacing and behaviour documented in both directions, so the build matches the design instead of drifting away from it.
Our process
How we work
Research and review
Sessions with real users on real tasks, a review of your support tickets and analytics, and a written list of where the current experience costs you.
Flows and structure
What belongs on each screen, what the user decides and when, and what can be removed — agreed as wireframes before anything is made to look finished.
Prototype and test
A clickable version put in front of a handful of real users, with what we observed written down and the flows adjusted before development is committed.
Interface design
Final screens in Arabic and English across the devices that matter, built on a component library so what comes later stays consistent.
Handover and build support
Documented files, a walkthrough with the developers, and the designer available during development so details are decided rather than improvised.
Frequently asked questions
Usually just some fixes. In most systems three or four screens carry the majority of the complaints — a form, a dashboard, a search result, a checkout — and reworking those is faster, cheaper and far less disruptive than redoing everything. A full redesign makes sense when the underlying structure is wrong rather than the surface, and we will tell you which situation you are in after looking, not before.
Because we watch people use it rather than debate it. Whether someone completes a task, how long they hesitate, where they click by mistake and what they say while doing it are all observable, and they settle disagreements that opinions cannot. Testing happens on a clickable prototype before development, so a wrong assumption costs an afternoon of design time rather than a build cycle.
Yes, and most of our work does. If you have brand guidelines we design inside them and flag anywhere they cause a genuine usability problem, such as a colour pair that fails contrast for readers with low vision. If you have no guidelines, we keep to a restrained set of colours, type styles and components that you can extend later without it falling apart.
Whichever your users are actually on, which your analytics usually answer in a minute. A public-facing site in this region is overwhelmingly phone traffic. An internal system that staff use for six hours a day on a laptop is not, and designing it mobile-first would make their working day worse. We check before deciding rather than applying a rule.
Then we will tell you, and it becomes an engineering job. Users describe slowness as a bad experience, and a redesign of a screen that takes forty seconds to load will not change how it feels. It is a common finding and not one we bury in order to keep a design project alive — our development team can look at the cause instead.
Design files with the components, spacing, typography, colours, interactive states, empty and error states, and behaviour documented, in both left-to-right and right-to-left, plus a walkthrough session with whoever is building it. The aim is that a developer never has to guess what happens when a list is empty or a field is invalid, because guessing is where a build starts drifting from the design.
Fewer than most people expect. A small number of the right users, watched carefully on a real task, uncovers the majority of serious problems, and it is more useful to run several small rounds than one large study. Recruiting the right people matters far more than the count — five of your actual customers will tell you more than fifty strangers.
Yes. Design, web development and mobile development sit in the same team here, so the design does not have to be thrown over a wall and interpreted by people who were not in the conversation. If you would rather your own developers build it, that is equally fine — the handover is prepared for exactly that, and we stay available for questions during the build.