UX/UI Design
A product isn't understood because the design is pretty. It's understood because someone did the work of finding out how the people using it actually think. That's what we do before a single line of code gets written.
Who it's for
- You have a working product, but users get lost, contact support about the same thing over and over, or drop off halfway through.
- You're about to build something new and don't want to find out in production that the idea wasn't clear.
- The team argues about the interface in meetings without reaching agreement, because nobody has data on how people actually use it.
- You need the product to serve two different audiences that want opposite things.
What's included
User research
Interviews and observation of how the problem gets solved today, including the workarounds and side spreadsheets nobody admits to in a meeting.
Information architecture
What comes first, what gets grouped with what, and what everything is called. Most "I can't find anything" problems are solved right here.
Navigable prototypes
Medium and high-fidelity mockups you can walk through and test, not static images. Ideas get corrected in hours instead of weeks.
Validation with real users
Tests with representative people before development starts. It's far cheaper to find a problem in a prototype than in production.
Design system
Components, typography, colour and states documented, so the product stays coherent as it grows.
Accessibility from the start
Contrast, text sizes, keyboard navigation and screen readers considered from the design stage, not patched in at the end.
How we approach design
Three stages, each ending in something concrete you can review.
Understand
We listen to what you want to achieve, what resources you have and what's happening today. We come out with a written scope and the criteria the result will be judged by.
Propose
Information architecture and navigable prototypes. You see the solution working before it exists, and you can change your mind while it's still cheap to do so.
Validate
We test with representative users, fix what fails, and only then hand over to development with the design already proven.
A real case
App and platform for early childhood centres
A system with two faces and two opposing audiences. Staff record the day from a web panel built for desktop data entry: many fields, repeated use, keyboard-driven. Families receive that same information on their phone, in scattered moments, with a minute of attention. Designing a single interface for both would have half-served each group, so it was solved as two distinct experiences over the same data.
Frequently asked questions
- Can you do UX design if the product is already built?
- Yes, and that's the most common case. We start by measuring where people get stuck today and prioritise what does the most damage. You don't always have to rebuild everything: often the biggest change comes from reordering and renaming what already exists.
- How long does the design stage take?
- It depends on the size of the product and how clearly the problem is defined at the start. What's fixed is that every stage ends with something concrete to review, so weeks never go by without you knowing where things stand.
- Do we need user research, or is our internal experience enough?
- Internal knowledge is an excellent starting point and a poor finishing one. Whoever builds the product already knows where to click, and that bias is exactly what makes something feel obvious inside and confusing outside.
- Do you hand over files any developer can use?
- Yes. Prototypes and the design system are documented so any team can pick them up, whether you build with us or not.
Have a product people aren't understanding?
Tell us what's happening and we'll tell you whether it's a design problem, a product problem, or something else. No commitment.
Book a meeting