Skip to content
XSIS
Talk to an engineer

Software engineering

UX and UI design

Interfaces designed from research and tested with real users

User research, information architecture, interaction design and design systems for products people use every day.

Overview

People judge software by whether they can finish their task. Design decides that: what appears on each screen, in what order, with which words, and what happens when something goes wrong.

We start with research, not screens. We talk to the people who will use the product, watch them work and test ideas early with prototypes. From there we design the structure, the flows and the interface, and we build a design system so the product stays consistent as it grows.

We design to WCAG 2.2 AA as a matter of course, and for every language you need, including Arabic and other right-to-left scripts, where layouts mirror and type needs its own care. Designers work alongside engineers through the build, so what ships matches what was designed.

What we deliver

  1. Research findings

    Interviews, observation and analytics turned into clear findings about your users, their tasks and their problems.

  2. Information architecture

    The structure of the product: navigation, naming, and how content and features are grouped.

  3. User flows

    Each key task mapped step by step, including errors, empty states and edge cases.

  4. Tested prototypes

    Clickable prototypes in Figma tested with real users, with a record of what we learned and changed.

  5. Interface design

    Screens for every breakpoint, from phones to large desktop screens, ready for engineering.

  6. Design system

    Tokens, components and usage guidance in Figma and in code with Storybook, shared by designers and engineers.

  7. Accessibility review

    Designs checked against WCAG 2.2 AA for contrast, focus order, target size and screen-reader labels.

  8. Right-to-left layouts

    Mirrored layouts, icons and typography for Arabic and other right-to-left languages.

How we work

  1. 01

    Research

    We interview users, review analytics and support requests, and observe the work where it happens.

  2. 02

    Define

    We agree the problems to solve, the users to design for and how we will measure success.

  3. 03

    Design and prototype

    We sketch, structure and prototype the key flows, starting rough and refining as we learn.

  4. 04

    Test with users

    We test prototypes with real users, fix what confuses them and test again.

  5. 05

    Deliver and support the build

    We hand over designs and components, review what engineering builds and adjust with them.

Technologies

Languages
  • TypeScript
Frameworks
  • React
Testing
  • axe-core
Design and accessibility
  • Figma
  • Storybook
  • WCAG 2.2

Ways to work with us

Questions and answers

Do we need user research if we already know our users?

You know a great deal, and research builds on it. It tests assumptions with the people who do the work, and often reveals steps, workarounds and terms that never reach a requirements document. Even a small round of interviews and prototype tests before the build costs less than changing software after it ships.

Link to this question
What drives the cost of design work?

The number of user groups and journeys, how much research is needed, whether a design system already exists, and how many platforms and languages the design must cover. Redesigning an established product with many screens takes more than designing a focused new tool. We scope design in stages, so you can review the findings and flows before committing to the full interface.

Link to this question
How do you make designs accessible?

We design to WCAG 2.2 AA from the first wireframe: enough colour contrast, visible focus, a logical reading order, touch targets large enough to use, and a label for every control. We check designs before handover and test the built product with a keyboard and screen readers. Accessibility designed in costs little. Added later, it costs a great deal.

Link to this question
Can you design for Arabic and other right-to-left languages?

Yes. Right-to-left design is more than flipping the screen. Navigation, progress indicators, charts and icons that imply direction need mirroring, while numbers, logos and media controls usually do not. Arabic text needs its own typeface, size and line height. We design both directions together and review them with native readers.

Link to this question
What is a design system, and do we need one?

A design system is a shared set of colours, type, spacing and components, with guidance on when to use each, kept in step between design files and code. You need one when several teams or products must look and behave consistently, or when a product will grow for years. For a single small tool, a lighter component library is often enough.

Link to this question
How do your designers work with engineers?

In the same team and at the same rhythm. Designers join planning, hand over designs and components with their states and behaviour documented, and review what is built before it ships. Engineers join research and design reviews early, so ideas that are hard to build are caught before they are polished.

Link to this question
Who owns the code and the work you produce?

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That covers the custom code, documentation and other deliverables made for you. Anything we bring that existed before, such as internal tools or libraries, stays ours, and you receive a licence to use it in your systems. Open-source components keep their own licences, and we list them for you.

Link to this question

Tell us what you need to build or connect.

Describe the systems, the timeline and the constraints. The right engineers take it from there.

  • Our team will call you within 24 hours during your preferred time slot
  • Our team is available 24/7