Design systems & component libraries

Area: UI/UX & Digital Identity · Usual shape: scales + component library + documentation · Serves: several products, or a team that keeps building

When two teams build two screens, three different buttons appear. A design system is the agreement that prevents it: defined scales, ready components with their states, and written rules for whoever comes next. It is not a handsome file — it is a library that gets used, and whose adoption you can actually see.

Talk to us about your project See the whole area

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

What this solves

Three products look like three different companies.
The same decisions get re-made every project.
Several projects are about to start at once.
The product grew until its own screens contradicted each other.

What we build

A colour scale with contrast measured against the surfaces it is actually used on.
A type scale covering Arabic and Latin together.
Spacing, radius and elevation scales.
A component library with every state, not only the happy one.
Direction rules built on logical properties, so right-to-left needs no second set.
Accessibility built into the component rather than added to it.
Light and dark both designed, neither derived from the other.
Usage documentation and handover to the team who will own it.

Where it is used

Three products that look like three companies.
A team re-deciding the same things every project.
An organisation about to start several projects at once.
A product that grew until its screens contradicted each other.

What this does not include

It is not a corporate identity and it is not a logo.
No print or off-screen brand guidelines.
We do not supply commercial component-library licences.
A system does not enforce itself — it depends on the team adopting it, and we say so plainly.

How the work goes

We start from the screens you already have, because the system has to describe reality before it improves it.
We agree the scales first — they are the decisions everything else inherits.
We build the components your products actually use, in the order they use them.
We hand over with documentation aimed at the next person, not at us.

Product & app interface design
when one product needs designing rather than a shared vocabulary.
Digital identity for products
when the question is what the brand looks like inside the interface.
UX review & interface audit
when the existing screens need diagnosing first.
Web applications
when the system is for a product we are also building.

Questions about this service

Do we need a design system for one product?

Usually not. For a single small product it is overhead. It earns its cost when several products, or several people, are making the same decisions repeatedly.

Does it work with our current team?

It has to, or it is shelfware. We build it in whatever their real workflow is and hand it over in a form they can extend without us.

Does it cover Arabic?

Yes, as a first-class part rather than an appendix. Type scale, direction and component behaviour are all defined for both scripts.

How do we maintain it after handover?

With one owner and a written change process, both agreed before handover. A system with no owner drifts back into three buttons within a year.

Can it be extracted from an existing product?

Often, and it is usually the cheaper route: the decisions already exist implicitly and mostly need to be made consistent and written down.

Tell us how many products need to look like one company.

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