Product & app interface design

Area: UI/UX & Digital Identity · Usual shape: full design + prototype · Handover: buildable by any team

Changing a screen in design takes an hour; changing it after it is built takes a week. So we design first: map who uses the product and what they are trying to finish, then build the screens and a clickable prototype before a line is written. And Arabic is designed alongside English, not after it, because a layout mirrored later looks exactly like a layout mirrored later.

Talk to us about your project See the whole area

Opens WhatsApp. Nothing is sent until you press send there.

What this solves

The idea is agreed and nobody can picture it.
It has to be shown to partners before it can be built.
There are engineers and no designer.
The screens grew complicated and nobody planned them that way.

What we build

A definition of the users and their core tasks.
Information architecture and a screen map.
The critical task flows, before any visual work.
Wireframes, then complete visual design.
Screen states: empty, loading, error, full.
Design in Arabic and English together, not one mirrored from the other.
A clickable prototype for review.
A developer handover covering sizes, states and behaviour.

Where it is used

An agreed idea nobody can picture.
A product that must be shown to partners or funders before it is built.
An engineering team with no designer.
Existing screens that grew complicated over time.

What this does not include

No illustration, motion graphics or video.
No advertising creative or print.
We do not build the product within this scope — building is a separate service if you want it.
No lab usability testing with recruited participants unless agreed separately.

How the work goes

We start from the tasks, not the screens — what someone came to finish.
We agree the flow before anything is made to look finished.
We review on a clickable prototype rather than on flat images.
We hand over so any competent team could build it, including one that is not us.

Design systems & component libraries
when several products need one shared vocabulary.
UX review & interface audit
when the product exists and the problem is using it.
Custom mobile applications
when the design should be built as a phone application.
Web applications
when the design should be built as a browser product.

Questions about this service

Can we take the design and build it with our own team?

Yes. The handover is complete and buildable by any team, and it is not conditional on us building it. We would rather hand over something usable than something that locks you in.

How many review rounds are included?

Agreed in the scope, in writing, along with what a round is. Unbounded revision is how design projects quietly become open-ended.

Do you design in both Arabic and English?

Yes, at the same time. An Arabic design derived from a finished English one looks like exactly that, and the problems it creates surface during build rather than during design.

What if the scope changes mid-design?

It sometimes should — design is partly how you find out the scope was wrong. We re-agree it explicitly rather than absorbing the change silently.

In what form is the design handed over?

As screens, states and a prototype, plus written notes on behaviour that a static image cannot carry. The intent is that a developer has no questions left that only a designer could answer.

Tell us what you are planning to build.

Talk to us on WhatsApp Or send the details through the form