Skip to content

Design & UX

UX Design

The structure and behaviour beneath the interface — researched, mapped and tested so the product is understandable, efficient and worth using.

Overview

User experience design is about how a product works, not how it looks. It is the invisible structure underneath the visuals: how information is organised, how someone moves from intent to done, which step comes before which, what happens when they get something wrong, and whether the whole thing makes sense to a person who has never seen it before. That structure is decided long before anyone chooses a colour or a typeface — and when it is wrong, no amount of visual polish rescues it. A beautiful screen that nobody can navigate is still a failure; it just fails more attractively.

This is a deliberately different service from UI design. UI is the visual layer — the type, colour, spacing and components that make an interface look considered and coherent, and it matters. But UX is the layer beneath it: the research into who is actually using the thing, the personas and jobs they are trying to get done, the journeys and flows, the information architecture, the wireframes and the usability testing that tells you whether any of it works. You can have excellent UX with plain visuals and it will still be a good product. You cannot have good visuals rescue broken UX. If what you need is the visual craft, our UI Design service is the right place; this page is about the structure and behaviour.

The uncomfortable truth about UX is that it is evidence-led, not a matter of taste. The strongest opinion in the room is not data, and a founder’s certainty about what users want is a hypothesis until users are watched trying to use it. Good UX comes from research and testing — from watching real people struggle, misread and abandon — and the most expensive UX mistakes are the ones baked into the structure early, when they are cheap to fix and easy to ignore. Get the structure right and you reduce support load, cut abandonment, and stop paying for confusion every single day the product is live.

Who it’s for — Teams building something new who want the structure right before they commit engineering to it, or teams whose existing product confuses people, loses them partway through, or generates support tickets that are really design failures in disguise.

What you get

  • User research — interviews, observation and, where it exists, analysis of your real usage and support data — so decisions rest on evidence rather than the loudest opinion
  • Personas and jobs-to-be-done that describe who is actually using the product and what they are trying to accomplish, grounded in research rather than invented for a slide
  • User journeys and task flows mapping the real routes people take to a goal, including the error paths and dead ends that get skipped in a happy-path demo
  • Information architecture — how content, features and navigation are organised and labelled — validated rather than assumed, so people can find what they came for
  • Wireframes and interactive prototypes that make the structure testable before it is expensive, and that give engineering something unambiguous to build against
  • Usability testing with real people, with the findings turned into specific, prioritised changes rather than a report that sits unread
  • An accessibility and inclusive-design pass through the structure itself, so the product works for people using keyboards, screen readers and assistive technology — not just a mouse on a fast laptop

What UX Design does for you

  • Fixing structure early is where the money is

    A flawed information architecture or a confusing flow costs almost nothing to change on a wireframe and a fortune to change once it is built, shipped and woven into your data model. UX front-loads the cheap decisions so you are not paying engineering rates to undo a structural mistake that a day of testing would have caught. The whole discipline earns its place by moving the expensive discoveries earlier.

  • Good UX quietly lowers your support cost

    A large share of support tickets are not bugs — they are people who could not work out how to do something the product technically lets them do. Every confusing label, hidden action and unexplained error becomes a message someone on your team has to answer. Design the structure so people can succeed unaided and that volume falls, which is a running cost saved every month, not a one-off.

  • Less abandonment, more of what you built getting used

    People leave products at the point where they get stuck, confused or asked for too much too soon — and they rarely tell you why, they just go. Understanding where the drop-off happens and redesigning the journey around it keeps more of the people who arrive, and gets more of the features you already paid to build actually used instead of quietly ignored.

Why teams choose us for UX Design

  • We treat UX as evidence, not decoration. Decisions come from research and testing with real users, and when we do not have evidence for something we say so plainly rather than dressing an opinion up as a finding.
  • We are clear about the line between UX and UI, and we will tell you which one your problem actually is. Sometimes a product looks dated but works fine, and sometimes it looks polished but is structurally broken — the fix is completely different, and conflating them wastes money.
  • Senior people do the research and the thinking. The person who interviews your users and runs the usability sessions is the person shaping the flows, not a junior handing findings up a chain where the nuance gets lost.
  • We hand you structure engineering can build without guessing. Wireframes, flows and an information architecture that remove ambiguity, so developers are not quietly inventing UX decisions at 4pm because the design left a gap.

What UX Design includes

The concrete pieces of work this covers — scoped to what your problem actually needs.

  • User research and interviews

    Talking to and watching the people who actually use — or will use — the product, so the design rests on how they genuinely think and behave rather than on how the team assumes they do. This is where most of the useful surprises live, and skipping it is why so many confident products miss.

  • Personas and jobs-to-be-done

    Turning research into a clear picture of who the users are and, more usefully, what job they are hiring the product to do. Framing design around the job to be done keeps the team building for a real goal rather than for a demographic on a poster nobody consults.

  • User journeys and task flows

    Mapping the actual routes people take to get something done — including the wrong turns, the error states and the moments they abandon. A flow that only documents the happy path hides exactly the places where real products lose people, which are the places worth designing for.

  • Information architecture

    Deciding how content, features and navigation are structured, grouped and labelled so people can find what they came for and understand where they are. IA is the least visible and most consequential part of UX; get it wrong and every screen built on top inherits the confusion.

  • Wireframing and interaction design

    Laying out screens and defining how they behave — what each control does, what happens on success and failure, how state changes are shown — at low fidelity, before visual design and before code. Wireframes make the structure concrete and arguable while it is still cheap to change.

  • Prototyping and usability testing

    Building interactive prototypes and putting them in front of real people to watch where they succeed, hesitate and fail. Usability testing is the reality check that separates a design the team likes from a design that works, and it is far cheaper than shipping and finding out live.

Where it fits

  • Structuring a new product before it is built

    You have a product to build and want the flows, information architecture and core screens researched and tested as wireframes before committing engineering to them. This is the highest-leverage moment for UX, because the structural decisions are still cheap to change and have not yet hardened into the codebase.

  • Fixing a product people find confusing

    An existing product that works technically but that users struggle to understand — support tickets pile up around the same few tasks, and onboarding takes hand-holding. We research where the confusion actually lives and redesign the structure around it, rather than repainting the surface and hoping.

  • Rescuing a high drop-off flow

    A checkout, sign-up, application or onboarding flow where people start and do not finish, and the analytics show where but not why. We combine the drop-off data with usability testing to find the real cause — a confusing step, a badly timed ask, an unexplained error — and rebuild that stretch of the journey.

  • Untangling an information architecture that has sprawled

    A product or site that has grown feature by feature until nobody can find anything and the navigation is a museum of old decisions. We reassess how it is organised and labelled, validate a new structure with real users, and give you an architecture that reflects how people actually look for things.

How we approach UX Design

We start from the same principle every time: we do not yet know what users need, and neither do you, until we have watched them. So the first work is research — interviews, observation, and a hard look at whatever real usage and support data already exists — aimed at the questions that matter: what are people trying to do, where do they get stuck, and what do they misunderstand. We hold our own assumptions loosely on purpose, because the point of research is to be surprised, and a process that only ever confirms what the team already believed was not research at all.

From there we work outward in increasing fidelity, and deliberately keep the structure separate from the surface. Jobs and journeys come first, then information architecture, then wireframes, then testing — and only once the structure holds up under real users does it make sense to hand it to visual design. Working this way means the expensive, hard-to-reverse decisions get made and validated while they are still cheap, and the visual layer is applied to a foundation we already know works rather than to a guess.

How we deliver UX work

We begin by understanding the problem and the people, not the screens. That means agreeing what questions the research needs to answer, then getting in front of real or representative users through interviews and observation, and mining any usage analytics, session recordings and support logs you already have. Existing products are a gift here — they are full of evidence about where people struggle, if anyone bothers to look. The output is not a deck of quotes; it is a clear read on who the users are, the jobs they are doing, and where the current experience or the proposed one is likely to fail them.

Next we design the structure and make it testable. Journeys and task flows map the routes to each goal, the information architecture decides how everything is organised and labelled, and wireframes turn that into concrete, low-fidelity screens that define layout and behaviour without the distraction of visual styling. We keep fidelity low on purpose: it is faster to change, and it stops feedback drifting onto colours and fonts when the conversation needs to be about whether the structure works. Then we prototype and test — real people, real tasks, watched rather than surveyed — and turn what we see into specific, prioritised changes.

Finally we hand over something engineering can build without inventing the missing pieces. That is the flows, the wireframes or prototype, the information architecture, and the interaction detail — what each state looks like, what happens on error, how edge cases behave — documented clearly enough that a developer is never silently making UX decisions the design forgot to make. Where the work continues into visual design, this is the point at which it makes sense to bring in the UI layer, on top of a structure that has already earned its place.

Information architecture

Information architecture is the part of UX with the longest shadow and the least visibility. It is how everything in the product is structured, grouped, named and connected — the categories, the navigation, the hierarchy, the labels — and it is decided so early that most teams never consciously decide it at all; it just accretes, one feature at a time, until the product is a filing cabinet organised by the order things were added rather than by how anyone looks for them. By the time the confusion is obvious, the structure is load-bearing and expensive to change, which is exactly why it deserves deliberate attention up front.

We treat IA as something to be validated, not asserted. The words a team uses internally are frequently not the words users would look for, and the way a business is organised on an org chart is frequently not the way its customers think about its products. We test the structure directly — with techniques like card sorting to see how people naturally group things, and tree testing to see whether they can find a given item in a proposed navigation — so the architecture reflects the users’ mental model rather than the company’s internal one. The difference between those two models is where a great deal of everyday confusion quietly comes from.

A good information architecture pays off invisibly and forever: people find things, they understand where they are and how to get back, new features have an obvious home instead of being bolted onto a menu that is already overflowing, and the product stays coherent as it grows. It is the single structural decision that most determines whether a product feels simple or feels like a maze, and it is far cheaper to get right on a diagram than to unpick once every screen, URL and data relationship depends on it.

Accessibility and inclusive UX

Accessibility is a UX concern before it is a visual one. Long before contrast ratios and colour — which sit in the UI layer — there is the question of whether the structure itself works for someone who is not using a mouse on a fast laptop with full attention. Can the whole flow be completed with a keyboard alone? Does the order things are read in make sense to a screen reader? Are errors explained in a way that does not rely on noticing a colour change? These are decisions about behaviour and structure, and they are far cheaper to get right in the flows and wireframes than to retrofit once the product is built around assumptions that quietly excluded people.

Inclusive design goes wider than disability. It means not assuming everyone is confident, unhurried, on a good connection and familiar with your conventions. Real users are distracted, interrupted, new to the product, occasionally anxious about getting it wrong, and sometimes doing the task for the first and only time. A journey designed only for the fluent power user fails the person who most needs it to be clear. So we design for the harder cases — the first-timer, the person who made a mistake, the person under pressure — because a structure that works for them works comfortably for everyone else too.

We build accessibility into the research and testing rather than treating it as a compliance box bolted on at the end. That means considering assistive-technology users when we define flows, checking that the information architecture and interaction patterns hold up without sight or without a pointer, and, where it matters to you, testing with people who actually rely on those tools. It is both the right thing and the pragmatic thing: an accessible structure is a clearer structure, it widens who can use the product, and it lowers your legal and reputational exposure at the same time.

Signs it’s time

  • People consistently misunderstand your product, and onboarding only works when a human walks them through it
  • A sign-up, checkout, application or onboarding flow has high drop-off and the analytics show where but not why
  • Support keeps answering the same questions, which are really design failures wearing the costume of user error
  • You are about to build something new and want the structure researched and tested before engineering commits to it

Evidence over opinion

The core of how we work is refusing to let the loudest opinion win. Every team has strong instincts about what users want, and some of them are right — but instinct is a hypothesis, and the only way to know is to watch real people try. So we run small, frequent tests rather than one grand validation at the end, because five users watched attempting a task will reveal more real problems than a hundred surveyed about their preferences. People are unreliable narrators of their own behaviour; what they do under observation is worth far more than what they say they would do.

That discipline extends to how we report. We separate what we observed from what we infer, we tell you when a finding rests on a small sample, and we resist the temptation to launder a design preference into a research conclusion. When the evidence contradicts something the team was sure of — including something we ourselves proposed — we say so, because the entire value of testing is that it can prove you wrong while it is still cheap to change course. Research that only ever confirms the plan is theatre, and we would rather deliver an inconvenient finding than a comfortable one.

Technologies we build it with

Chosen per problem, not per fashion — this is the stack we most often reach for on this work.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves — including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

What changes

  • Structure that works, proven

    Flows and an information architecture validated with real users before engineering commits, so the expensive structural decisions are right rather than hoped.

  • Lower support and abandonment

    A product people can use unaided, which quietly cuts the tickets that were really design failures and keeps more of the people who arrive.

  • A clear brief for the build

    Wireframes, journeys and interaction detail unambiguous enough that developers build the intended experience instead of inventing the missing pieces.

Industries we serve

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

How pricing works

  • The dominant driver is how much genuine research and testing the work needs. Designing structure from evidence — recruiting and interviewing users, running usability sessions, analysing what you find — is where the real effort and the real value sit, and it is not the part to cut if you want the confidence that the structure holds.
  • The size and complexity of the product matters directly: a single high-stakes flow such as a checkout is a contained piece of work, while restructuring the information architecture of a sprawling multi-feature product touches everything and costs accordingly.
  • Whether you are starting fresh or fixing something existing changes the shape of the job. An existing product comes with real usage data, support logs and users to observe — often faster to diagnose — whereas a new product needs more upfront research to stand in for evidence that does not exist yet.
  • How much you want carried through into interactive prototyping and repeated test rounds affects the figure. A single well-scoped round of testing is very different from an iterative cycle of prototype, test, refine and test again — both are legitimate, and we cost them honestly rather than pretending one round is always enough.

Typical timeline

  1. 01

    Research and discovery

    We agree the questions that matter, then interview and observe real or representative users and mine any existing usage and support data — so the design that follows rests on evidence, not assumption.

  2. 02

    Journeys and architecture

    We map the user journeys and task flows and settle the information architecture, validating how things are grouped and labelled against how users actually look for them rather than how the team names them internally.

  3. 03

    Wireframes and prototype

    We turn the structure into low-fidelity wireframes and an interactive prototype that define layout and behaviour, deliberately without visual styling, so it is fast to change and testable while it is still cheap.

  4. 04

    Testing and handover

    We put the prototype in front of real people, turn what we observe into prioritised changes, and hand engineering a clear structure — flows, wireframes, IA and interaction detail — to build against.

Why teams choose us for UX Design

  • Evidence, not taste

    We design from research and usability testing with real users, and we are honest about the difference between what we observed and what we assume. When we lack evidence, we say so rather than presenting an opinion as a finding.

  • We operate what we build

    Because we build and run software, the UX we design is grounded in what can actually be built and maintained — flows and structures that hold up in a real product, not idealised journeys that quietly ignore the edge cases engineering then has to handle.

  • Senior people throughout

    The person interviewing your users and running the tests is the person shaping the flows and the architecture. Research insight does not get diluted passing up a chain, and the nuance that matters most survives to the design.

  • Clear about UX versus UI

    We will tell you honestly whether your problem is structural or visual, because the fix is entirely different. We do not sell you a research programme when you need a repaint, or a repaint when the structure is broken underneath.

How to engage us

Three ways to work with us on this — chosen to fit the problem, not our margin.

Related services

Part of Custom Software Development. Other work we do alongside this.

Common questions

What is the difference between UX design and UI design?

UX is how the product works; UI is how it looks. UX covers the structure and behaviour — the research, the personas and jobs, the journeys and flows, the information architecture, the wireframes and the usability testing that decide whether the product is understandable and efficient to use. UI is the visual layer applied on top: type, colour, spacing and components. They are different disciplines with different skills. Good UX with plain visuals is still a good product; polished visuals cannot rescue broken UX. This page is the former; our UI Design service is the latter, and larger jobs usually need both, in that order.

Do we really need user research, or can you just design from best practice?

Best practice gets you sensible defaults, but it cannot tell you how your specific users think, what words they look for, or where your particular product loses them — and those are exactly the decisions that determine whether it works. Research is what separates a design that the team likes from one that users can actually use. If budget is tight we scope research to the highest-risk questions rather than skipping it, because designing structure with no evidence is how confident, expensive products end up missing. We would rather do a focused amount of research than none.

How many users do you need to test with to get useful findings?

Fewer than most people expect. For usability testing, watching around five representative users attempt real tasks surfaces the large majority of the serious problems, because the same obstacles trip up person after person. The value is in observing behaviour, not in a big sample — this is not statistics, it is watching where people get stuck. We would rather run small tests often, refining between rounds, than stage one large study at the end when it is too late to act cheaply on what it finds.

Our product looks dated. Is that a UX problem or a UI problem?

Possibly neither, possibly both, and telling them apart is worth doing before you spend money. If people can complete their tasks but it looks old, that is a UI problem and a visual refresh is the fix. If people get lost, misread things or abandon partway, that is UX, and a new coat of paint will leave the underlying confusion exactly where it was — arguably worse, because it now looks trustworthy while still failing. We will diagnose honestly which one you have, because the two need completely different work and conflating them wastes budget.

We are early and moving fast — is UX worth it before we have built anything?

That is the single best time for it. The most expensive UX mistakes are the structural ones baked in early, when they are almost free to change on a wireframe and ruinously expensive to unpick once they are built into the code and the data model. A focused round of research and tested wireframes before you commit engineering does not slow you down; it stops you building the wrong thing quickly. Moving fast in the wrong structure is just reaching the rebuild sooner.

Let’s talk about UX Design.

Tell us what you’re building or fixing. A senior engineer reads every enquiry and replies within a business day.

Prefer to book a call?Or email support@yarqat.com

Two fields required. We reply to real enquiries — no list, no sequence.