User research and testing
We talk to the people who will use the product, before designing it. That is where the real problem comes out, which is almost never the one you started from.
A product nobody understands how to use is no use to you.
The best technology in the world is useless if the user cannot use it. For us design is the part of a project that decides whether the product will be used or abandoned.
And we take care of it from the start, not when it is too late to change.
You need it when a product works but people struggle to use it: users get stuck, support keeps answering the same questions, nobody finds the features you built. You also need it before writing code, to anticipate errors and changes and cut project costs.
Netech had a banking platform for anti-money-laundering checks. The backend was solid, but the interface was not clear to users. We redid the UX and UI, and a complex tool finally became clear and usable.
We talk to the people who will use the product, before designing it. That is where the real problem comes out, which is almost never the one you started from.
Fewer steps for the thing done a hundred times a day, and information where it is needed. On screens full of data, this is where you win or lose.
Components and rules written once: the fiftieth screen does not cost what the first did, and does not look designed by another company.
A prototype you can click before writing code: changing a flow in Figma costs an hour, changing it in production costs a week.
For Satispay we gave shape to the digital home of a European fintech. For the Osservanza of Imola we built the identity of a place that is changing: a former asylum becoming an innovation park, to explore in 3D as well.
That is where you find out whether the design works.
We run tests with real users and check whether they get stuck, look for buttons in the wrong places, give up halfway. What a person says about an interface matters less than what they do when it is in front of them.
Designers and developers work in the same room: what we design is what can really be built, not a gorgeous, impossible mockup.
Our design is tied to development, it is not a PDF nobody then follows. We start from research and prototype, put them in front of real users, fix where they stall, and only then build. So what goes into production has already been tried by someone who is not us.
We work with people who have a powerful product that is hard to use, and with those who have to simplify something intrinsically complex: financial platforms, healthcare tools, data-dense business systems, but also with those starting from zero who want to validate the idea before spending months of development on it.
Miro for collaborative workshops, Figma for designing and prototyping, design systems and component libraries to keep everything consistent as the product grows. But tools are the easy part.
The difference is the method: design-driven and tied to development. We do not just hand over a file, we stay in the project until it goes into production. A design nobody can build the way you imagined it is not a good design, it is a nice drawing.
Do you have a powerful product that users struggle to use? Let us start there. We will look at where they get stuck and what makes hard what should be obvious.
Let's talk Back to What we do