Design & Product
UI/UX Design
Research, wireframes and interface design
Design decides whether people can use what you built. Not whether it looks current — whether a first-time user completes the task without being taught, whether your staff can get through two hundred records a day without errors, whether someone abandons the form on the third field. That is what we are designing for, and it is measurable.
We design interfaces for web applications, mobile apps, e-commerce stores and internal tools, and we do it as engineering's partner rather than as a decoration applied afterwards. A design that cannot be built at a sane cost is not a good design, so our designers and developers review the work together before it is signed off.
What's included
What the work involves
Research, proportionate to the risk.
Interviews with the people who will use the thing, a review of your support tickets and analytics, and a walkthrough of the existing product with someone who uses it daily. On a smaller project this is a week; skipping it entirely is how teams design confidently for a user who does not exist.
Information architecture.
What lives where, what the navigation is called, and how someone finds the one thing they came for. Most usability problems are structural, not visual.
User flows.
Every route through a task, including the ones nobody wants to draw: errors, empty states, expired sessions, partial data, failed payments and the back button.
Wireframes.
Structure and hierarchy agreed in grey before colour enters the conversation, because colour is where reviews go to die.
Interface design.
The complete, high-fidelity screens: typography, spacing, colour, states, iconography and imagery, consistent across every screen in the product.
Prototypes.
Clickable enough to test with real people and to hand to developers without a translation meeting.
Usability testing.
Five to eight people attempting real tasks. It is a small number and it reliably finds the majority of serious problems — before they are built.
Developer handover.
Specifications, spacing rules, component states, breakpoints and assets. Design that stops at a pretty picture becomes the developer's guesswork.
The screens most projects forget
A design is only finished when it covers the days that go wrong. We specify the empty state a new user sees before they have any data; the loading state; the error message that says what to do rather than what failed; the "no results" screen; the long-name and long-text cases that break a layout; the smallest phone you support; and the state a user hits when their permissions do not allow the thing they clicked. These are where products feel broken, and they are cheap to design and expensive to retrofit.
Designing for Arabic and English
Bilingual design is a structural constraint, not a translation task. Arabic text runs right to left, changing the entire reading order and the position of navigation, back actions and progress indicators. It typically sets longer or shorter than the English for the same content, so layouts have to tolerate both without breaking. Arabic typography needs its own line height, letter-spacing set to zero and a typeface that holds up at interface sizes. Icons implying direction must mirror; logos and media controls must not. We design both directions from the start, and review every screen in both, because an Arabic interface that was mirrored at the end always looks like it was.
Accessibility as a baseline
We design to WCAG contrast ratios, ensure every interactive element is reachable and operable by keyboard with a visible focus state, keep touch targets large enough to hit on a moving bus, provide labels that a screen reader can announce meaningfully, and avoid relying on colour alone to convey meaning. This is not extra work bolted on for compliance — it produces an interface that is easier for everyone, on a bad screen in bright sunlight.
On working with Codigoo
The reminder timing was their idea, based on our own no-show data. That one detail did more for us than the rest of the project combined.
Questions we are usually asked
- We already have a designer. Can you work with them?
Yes, and often that is the better arrangement — your designer knows your brand and your customers. We can take on the research, the systems work, or the interaction design for a specific complex area, and slot into the tooling and conventions they already use.
- Can you redesign our existing product?
Yes, and we would start by finding out where users actually struggle rather than by reskinning it. A redesign that changes the visual style and keeps the confusing structure is the most common way to spend a budget and change nothing. Sometimes the honest recommendation is a series of targeted fixes rather than a redesign.
- How do you handle feedback and revisions?
In structured review rounds at defined stages, with one person on your side who owns the final decision. Design by committee produces an average of everyone's preferences, which is a reliable way to arrive at something nobody chose. We ask for that decision-maker at the start.
- Do you deliver design files we own?
Yes. You get the working files, the exported assets and the documented specifications, in your own workspace. If you continue with a different team, they have everything they need.
If you have a product people find confusing — or a build about to start without a design — a consultation is the place to work out which part of that is a design problem.
Talk to us about UI/UX Design
Thirty minutes with an engineer and a strategist who do this work — not a sales team. You will get an honest answer about whether it is the right thing to buy, and what it would realistically cost.