Design
Product design for software people have to use on a busy day
We design the parts of a product people touch: task flows, screen structure, and the states that are usually forgotten, such as empty, denied, offline, and failed. Design is delivered so engineering can build it without inventing the rules.
- Task flows
- Interface structure
- Design for build
- Review against the working software
Design inside the delivery, not beside it
A separate design phase that ends in a static picture tends to ignore permissions, latency, and the data you do not have. We design the critical flows with engineering, then expand. Visual craft matters, and so does the screen that explains why an approval was rejected.
Arabic, English, and dense work
Many of the products we expect to build in the UAE are bilingual and data-heavy. We plan reading direction, labels, and tables early. A decorative homepage is not a substitute for a usable operations screen.
Design tied to a system
Designed for the release
- The task, not a moodboard
- States for empty, error, and permission
- The words staff will actually read
Not a separate brand programme
- A full visual identity
- Screens for flows that are out of scope
- Motion that hides a missing state
What changes the design work
The operator
A clerk on a deadline and a customer on a phone do not share a layout just because the data does.
The constraints
Arabic, dense tables, and a small phone are design inputs, not polish at the end.
What can be built
We design the interface the release will actually contain, including the admin.
What design needs before screens
- 01
The task
What the person is trying to finish.
- 02
The constraint
A phone, Arabic, or a dense table. Name the hard one.
- 03
The words
The labels staff already use.
- 04
The release
Which flows are in, so we do not draw the rest.
Marks a design is ready to build
- 01
A task was watched
The screens follow a job someone does, not a sitemap invented in a workshop.
- 02
Empty and error
The first release shows what happens when there is no data and when a step fails.
- 03
Their words
Labels use the language the operators already use.
- 04
Build can start
The repeated path is specified tightly enough that engineering is not guessing.
What we build
Task flows
The path for each role, including the points where a person must decide.
Interface structure
Navigation, forms, and feedback that match the domain language your staff already use.
Design for build
States, validation, and components an engineer can implement without guessing.
Review against the working software
The shipped interface is checked against the flow, not only against a mock.
How an engagement runs
- 01
Watch the current task
Even a spreadsheet has a flow. We start there.
- 02
Prototype the hard screen
The densest or most error-prone step, not the landing page.
- 03
Sit with the build
Adjust once real data and real permissions are on the screen.
Questions we hear
Do you only design, without building?
We can lead the product design on a system we are also building. A design-only engagement is possible when there is an engineering team to receive it and a named owner on your side.
Will we get a design system?
You get a coherent set of components for the product. A giant abstract system is not the goal of a first release.
Can you redesign an existing app?
Yes, starting from the tasks that fail today. A visual refresh that leaves the broken flow in place is not the engagement we recommend.