Design that survives contact with real users

A design is only as good as what people can actually do with it. We research the work, prototype the flows, test them with the people who will use the software, and then build what we designed, so the version that ships is the version that was tried.
The problem

A mockup that has never met a real user is only a guess.

It looks finished in the design tool. The screens are neat, the flow makes sense on a big monitor with clean test data and no rush. Then someone opens it on a phone, halfway through a job, with the messy data they actually have, and the parts that looked obvious turn out not to be.

Design that gets thrown over a wall to a separate build team loses something on the way across. Decisions get reinterpreted, edge cases get filled in by whoever is coding that screen, and what ships drifts from what was designed. The way to avoid that is to keep design and build close, and to test a design against real use before it is finished rather than after.

In SaaS platform development

The interface is the product. Onboarding, the empty state, the screen someone uses forty times a day: those decide whether a trial converts and whether a customer renews. Design here is a retention problem as much as a visual one.

In business operations software

People do not choose this software, they are handed it, and if it fights them they will route around it or resent it. Watts Group's surveyors use their app offline, in the field, on HS2 pre-condition surveys. That is the setting where a confusing screen costs real time.

How we work

We learn how the work is done before we design the screens for it.

  1. 01

    Research

    We spend time with the people who will use the software, through interviews, surveys and watching them work, to understand what they are trying to get done and where the current tools get in their way. The screens come out of that, not the other way round.

  2. 02

    Prototype

    Wireframes and interactive prototypes map the flows early, using story mapping to keep them anchored to real tasks. You get something to react to, and to argue with, while changing it still costs an afternoon rather than a sprint. Accessibility is considered here, as part of the design.

  3. 03

    Build what we designed

    Because we do the front-end build ourselves, the design is not handed to strangers to interpret. The people who prototyped it are the people who ship it, so its intent survives into the product, and once it is live we watch how it is really used and adjust.

What's included

What you get, in more detail.

  1. 01

    User research

    Interviews, surveys and usability testing with the people who will actually use the software, so the design starts from what they are trying to do and where they currently get stuck.

  2. 02

    Information architecture and story mapping

    We map the structure and the flows, often with story mapping and event storming, so the product is organised around the work someone is doing rather than the shape of the database behind it.

  3. 03

    Wireframes and interactive prototypes

    Page layouts and user flows you can click through and test before a line of production code is written, which is exactly when changing your mind is cheap.

  4. 04

    Accessibility, to WCAG

    Contrast, keyboard operation, screen-reader support and sensible target sizes, designed in from the start rather than retrofitted after an audit flags them. Accessible software tends to be clearer software for everyone.

  5. 05

    Front-end build, by the same team

    We build what we design. The front end is developed by the people who prototyped it, so the interface that ships is the one that was tested, and it stays maintainable because it was built to the same standard as the rest of the system.

“The app has been very well received and has been a great success. It is significantly faster and easier to use than its predecessor - allowing our surveyors to produce more detailed reports.”
Kevin Taplin, Director, Watts Group

Software people actually like using

We build the front end on the same AWS foundation we use for everything else, so the design and the system underneath it come from one team rather than getting handed between two. We are an AWS Select Tier Services Partner and run a Well-Architected review on every engagement, which is part of why the thing you designed stays fast and affordable to run once real users arrive.

Read the Cloud Excellence Framework
Questions

The things buyers ask us first.

  • We already work with a design or brand agency. Where do you fit?

    Alongside them, usually. We are software engineers who design for usability, not brand or graphic designers, and we do not pretend to be. Plenty of our best work has been taking an agency's visual design and turning it into a product that behaves the way it should, or handling the flows and interaction while they own the look.

  • Isn't UX just how the product looks?

    Looks are part of it, but the harder part is whether someone can do what they came to do without getting stuck. The interface is the surface; the experience is the whole business of using the thing. We care about both, and we lead with the job the user is trying to finish.

  • Do you design in a tool and hand it over to developers?

    We prototype, but we do not hand it over, because we do the build ourselves. Keeping design and development in the same team is how the intent in a prototype survives into the shipped product instead of getting reinterpreted on the way.

  • Can you improve the design of an app we already have?

    Yes. We can research where your users get stuck, redesign the flows that are costing them, and, because we also do the front-end build, actually ship the changes rather than just recommend them.

Work we have done for businesses like yours

Golf course
Insurance platform rebuild Published 2026

Rubber Ring

Rubber Ring's digital insurance business had outgrown its original platform.

Discover how we rebuilt it on a modern, event-sourced architecture on AWS - a single-table DynamoDB source of truth streamed into a PostgreSQL read model, with containerised React Router 7 and PHP applications on ECS Fargate - and migrated the entire live book in one cutover.

Rubber Ring logo
Read more: Rubber Ring
Duwio workspace interface
Cloud-native SaaS platform Published 2025

Duwio

Working with Spacesuit Media, we transformed years of experience in image delivery into Duwio - a new SaaS platform for creative professionals, re-engineered from the ground up on AWS.

Built on an AWS well-architected foundation, it enables photographers and agencies to store, tag, search and deliver images seamlessly from anywhere in the world.

Read more: Duwio
GT World racing cars in motion
React Native mobile app Published 2025

SRO Motorsports Group

Si Novi partnered with Whiteflame and SRO Motorsports Group to build a new GT World app, replacing a Europe-only version with one that covers every SRO championship worldwide.

It brings together live video, timing, schedules, team data and race reminders each fan can tune to the series they follow, on a single React Native codebase over a serverless AWS backend.

Read more: SRO Motorsports Group
A package-holiday beach with sun loungers at golden hour
Serverless API rebuild Published 2025

Distribute

Distribute serves package-holiday data to a range of downstream partners through a business-critical API.

Discover how we rebuilt that API as a modern, serverless service on AWS - introducing a clean HTTP/JSON interface while keeping every existing consumer working through a zero-downtime migration.

Distribute logo
Read more: Distribute
Jaguar Land Rover tooling and equipment
Distribution web platform Published 2024

Jaguar Land Rover

Discover how Si Novi partnered with Jaguar Land Rover to build a scalable, secure AWS-powered web application for global tooling distribution.

Learn about the innovative solution, including recent enhancements for electric vehicle tooling, that supports 13 languages and over 40 regions worldwide.

Read more: Jaguar Land Rover
All case studies