UI/UX & Product Design
Interface, interaction and design systems, designed against the constraints the engineering will actually have.
Overview
Interfaces, interaction patterns and a design system for a product that has to be built, not only presented. The work covers the states real data produces: empty, loading and permission-denied. It matters most when design and engineering run at the same time, and the interface has to match the data model rather than a demo.
- Product flows and screen states
- Design system and component library
- Design tokens the front-end reads directly
- Arabic and English layouts, mirrored rather than translated
- Forms, validation and error messages
- Contrast, focus order and target sizes
- Prototypes for the interactions that are hard to describe
What you receive
- 01A component library in Figma, carrying the variants and states each component has in the product.
- 02A token file for colour, type, spacing and radius, read by the front-end rather than copied from it.
- 03An interaction spec per flow, covering entry points, failure states and what the back button does.
- 04RTL mirroring rules for layout, icons and directional components.
- 05Interface copy in Arabic and English for labels, empty states and error messages.
- 06An accessibility record per screen: contrast ratios, focus order and target sizes.
- Figma
- Figma Variables
- Figma Dev Mode
- DTCG design tokens
- Style Dictionary
- Storybook
- Tailwind CSS
- Radix UI
- CSS logical properties
- WCAG
How the engagement runs
Design starts with the architecture read, not after it. The first pass is flows and states on the screens that carry the most logic, drawn against the data model rather than ahead of it. The populated screen is the easy half. Components are built once and named the same in Figma and in the repository, so a change to a token moves both. Arabic and English layouts are reviewed together at every stage, because mirroring is a structural decision and not a translation pass. Review sits with the engineers who will implement it: what cannot be built at the agreed cost is changed while it is still a drawing. After launch the library is versioned, and a new screen is added to it rather than drawn beside it.
- A front-end that implements from a library rather than interpreting a picture.
- Screens that already have an answer for empty, slow and denied.
- Arabic and English that stay one product rather than two layouts drifting apart.
- A visual change made in one token, landing everywhere that token is used.
Tell us what you are building.
Send the outline and we will come back with an honest read on scope, sequence and what it takes to run it in production.