UI/UX Design Services

We design interfaces for software that has to work, not software that has to photograph well.

Most of the difference shows up away from the hero screen. Whether anyone designed the table with four hundred rows in it. Whether the error message says what to do next. Whether the form still makes sense when half the fields are optional and two of them depend on each other. These are the screens people actually spend their working lives inside, and they are the first thing a portfolio-led design process leaves out.

We also build software, which changes how we design it. A layout that would take three weeks to implement and a layout that would take three days are not obviously different on a screen, and we know which is which while there is still time to choose.

What We Design

Not every project needs all of this. These are the parts we go deep on when a product calls for them.

  • Interface design for web products

    Screens, components and layouts across the whole product, not only the parts that sell it. Dashboards, settings, admin, the long tail of pages that exist because the product is real.

  • Interaction and behaviour

    What happens on click, on scroll, on error, while waiting. Motion used to explain where things went, not to decorate. Keyboard behaviour for products people use all day.

  • The states nobody designs

    Empty, loading, error, partial, offline, and lists at the lengths they actually reach. We draw these as part of the work rather than leaving them to be improvised in code.

  • SaaS and multi-role interfaces

    Products where an admin, a manager and an end user see different versions of the same thing. Getting that right is an information architecture problem long before it is a visual one.

  • Visual design

    Type, colour, spacing and hierarchy, built as a system rather than decided per screen. Contrast and legibility treated as requirements, not preferences.

  • Visual identity inside the product

    Where a brand has to work in software rather than on a presentation slide. A palette with contrast that passes and states that stay distinguishable, a dark mode that was designed rather than inverted, type licensed for web and app use and legible at interface sizes, and an app icon that survives being sixteen pixels wide. We adapt an existing identity to work in a product, or build the product-facing half where one does not exist. We are not a branding studio, and for campaign work, naming or full brand strategy a specialist will serve you better.

  • Landing and marketing pages

    The pages that sell the product, designed to the same system so the product does not feel like a different company once someone signs up.

  • Responsive behaviour

    Designed at the breakpoints that matter for the actual audience, with the rules written down rather than left for a developer to infer from three fixed-width mockups.

  • Handover developers can build from

    Components, tokens, states, behaviours and edge cases, specified. We know what a usable handover looks like because we are normally on the receiving end of one.

When Teams
Come to Us

  • The product works and the interface is holding it back

    Functionality has outgrown an interface designed for an earlier, simpler version of the product. A redesign on a live system, done incrementally.

  • Nobody owns the design

    Screens were added by whoever was available. Nothing matches, and every new feature makes it worse. The fix starts with a system, not a repaint.

  • Conversion is the problem

    Traffic arrives and does not convert. We find out where it goes wrong before redesigning anything. See [LINK: UX research and audit | ].

    See
  • You need design and build from one team

    You would rather not manage a handover between a studio and a development agency.

    See
  • An interface you inherited

    Designs exist for the happy path and nothing else, and the build team is guessing at the rest. We complete the set.

Send Us the Product

Send us what you have — a live product, a prototype, or a set of screens. We will tell you what we would change and why, before anyone signs anything.

Let's discuss

How We Work

Who uses it, what for, and what they are trying to get done. The output is a scope you can price and argue with.

Information architecture and flows, agreed before any screen is drawn.

Interface design across the product, including the states most handovers leave out.

Components and tokens, so the product can keep growing without drifting.

Specs and behaviours in a form the build team can work from directly.

We stay available through implementation, because designs always meet questions once they become code.

Stack

  • Design: Figma, with components and tokens rather than loose frames
  • Prototyping: interactive prototypes at the fidelity the decision requires
  • Handover: documented components, states and behaviours, mapped to the build
  • Build targets: React and Next.js on web, React Native on mobile
  • Accessibility: WCAG 2.1 AA checks on contrast, targets, type and navigation order

Industries We Design For

We design for construction and PropTech, healthcare platforms, booking and scheduling systems, and travel and mobility.

How We
Work Together

  • Design only

    A defined engagement with a documented handover, for a product you will build elsewhere or in house.
  • Design and build

    One team from structure through to release. The shape with the least lost in translation.
  • Ongoing design

    A designer working to your roadmap alongside your own team.
  • Design review

    A shorter engagement ending in a written assessment of what to change and in what order. See
    We price every project individually. There are no packages, because the work does not arrive in packages.

Questions We
Get Asked

  • Product design is the work before the interface — what the product should do, for whom, and in what order. UI/UX design is the interface itself. On a new product they usually run together; on an existing one you often only need this half. See product design.

  • Usually yes, and it is often the right call. A redesign constrained by the existing build is a real discipline and we are comfortable working inside it. We will tell you which changes are cheap and which require build work, so you can decide where the budget goes.

  • We design, specify and hand over, then stay available while your developer implements it. Most of the cost of a bad handover is in the questions nobody is around to answer.

  • We give you a rough estimate as soon as we understand the product. The detailed number comes after the scope is agreed, broken down by module, so you can see what each part costs and decide what belongs in version one.

  • Yes. The Figma file, the components, the tokens and the documentation are yours.

  • Not as a standalone service. What we do is make an identity work inside a product — the palette, the type, the icon and the application across the interface. If you need a full brand programme, naming or campaign work, a specialist studio is the right call and we will say so rather than taking the work.

Let’s talk about your project

welcome@ideus.biz