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 is it for?
- For those who have a working product, but users get lost, contact support about the same thing over and over, or drop off halfway through.
- For those who are about to build something new and don't want to find out in production that the idea wasn't clear.
- For teams who argue about the interface in meetings without reaching agreement, because nobody has data on how people actually use it.
- For those who need the product to serve two different audiences that want opposite things.
What's included
Research and definition
Interviews, observation of how the work really gets done and detection of those workarounds nobody admits to in a meeting. We define what the project solves and what it does not.
Design and prototyping
Navigable medium and high-fidelity mockups to test and correct ideas fast, without waiting weeks to see whether something works.
Validation with users
Tests with representative people before development starts. We catch problems while they are still cheap to fix.
Handover for development
Components, styles and behaviours documented, with accessibility considered from the design stage, so the build is quick and coherent.
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