UX Design Rooted in Research, Not Intuition
Redesign of digital products and websites, grounded in how your users actually interact — not aesthetic preferences.
From scratch or redesign
These are two different engagements and it's worth knowing which one you're in before starting. The final deliverable is the same; what changes is where the evidence comes from.
Design from scratch
The product doesn't exist yet. Structure, flows and screens have to be defined before there is anything to evaluate, so the evidence comes from comparable products, from the market, and from conversations with the users it targets.
Projects like this: Virtual Ofix, The X Office
Redesign
Something is already running. The question isn't what to build but what to change and, above all, what to keep: a good part of the work is identifying what works today and shouldn't be touched.
Projects like this: Malpo, BiometryPass
In both cases the deliverable is a navigable prototype. These days we prefer it as HTML, a static page: it can be implemented right away, or your development team can take it to production without first translating a mockup into code. On earlier projects the deliverable was a detailed high-fidelity Figma file. It is a preference of ours, not a condition.
Decisions this work lets you make
A redesign is expensive and hard to undo. These are the four questions worth settling before the team starts moving screens around.
Redesigning without losing what already works
A new site can quietly erase what Google already recognized and what your users already knew how to use. We evaluate the proposed design before it goes live, not after the numbers drop.
How we work on it: Heuristic evaluation of the current site and the proposed design, content architecture, before-and-after comparison.
Case studyOficina Virtual: full redesign with a backend changeWhen most people arrive from a phone
It's common to find that most traffic enters on mobile into an experience that was never designed for mobile. The problem there isn't aesthetic: the hierarchy and contact flows were built for a different screen.
How we work on it: Analytics review, heuristic evaluation, competitor benchmark, mobile-first redesign.
Case studyMalpo: over 65% of traffic arrived from mobileValidating before building
Changing a prototype costs hours. Changing something already built costs sprints. That's why the hard decisions get made on flows and prototypes, while they're still cheap to move.
How we work on it: Wireframes, user flows, interactive prototypes and user testing before anything reaches development.
So the team can carry on without us
If every new screen needs us back, the work wasn't finished. The design criteria get documented so your team can apply them without depending on us.
How we work on it: Design system, components, and documentation of the decisions and the reasoning behind them.
What you receive
It varies by project, but the criterion is the same: material your development team can start from, with the reasoning behind each decision visible.
- The findings from the prior research, prioritized by conversion impact rather than by the order they appeared.
- Information architecture and user flows, with the critical paths identified.
- A navigable prototype of the screens where the decision concentrates. These days we prefer to deliver it as HTML, a static page, rather than as a design file.
- A phased roadmap, so the redesign can be implemented in parts instead of all at once.
- The metrics the change will be evaluated against, defined before it ships.
How we work
We understand the problem
We research how your users interact with your product today and where they get stuck.
We understand what your customer needs
We translate those findings into concrete decisions: what to prioritize, simplify, or cut.
We design from there
Prototypes, flows, and high-fidelity mockups. Every decision has a reason behind it.
Malpo Case: Research & Web Redesign
UX audit and mobile-first redesign for lead generation.
See full case study“Paulina provided comprehensive guidance throughout the entire process [...] considered both business objectives and actual user experience.”
Frequently Asked Questions
What is the difference between UX Design and UX Research?
Research answers questions; design makes decisions. UX Research produces understanding — what happens to your users, where they get stuck, what they need — and it can end there, as findings your team implements. UX Design takes that understanding and turns it into concrete flows and screens. In our case design always starts from research, so the practical difference is where the engagement ends: if you need to know what is going on, that's research; if you already know and need someone to design it, that's this.
What is the difference between UX Design and Product Design?
It depends a good deal on who is using the term, which is why it's worth settling up front. In many companies Product Design names this same work plus the product decisions: what gets built, in what order, against what business criteria. UX Design tends to be scoped to experience and interface. Because the boundaries move from one organization to the next, when someone asks us for product design the first thing we do is ask what they expect to receive, rather than assume a definition.
Do you only do visual design, without research?
No. Every project starts with a research phase — audit, interviews, or data analysis depending on the case — before we touch a single screen.
Do you design products from scratch, or only redesign what already exists?
Both, and the work is different. From scratch, when the product doesn't exist yet and structure and flows have to be defined before there is anything to evaluate: that's what we did with Virtual Ofix and The X Office. Redesign, when something is already running and the question isn't what to build but what to change and what to keep, as in Malpo or BiometryPass. In a redesign, a good part of the work is precisely identifying what works today and shouldn't be touched.
What format do you deliver the design in?
A navigable prototype. These days we prefer to hand it over as HTML, a static page, rather than only as a design file: that way it can be implemented right away, or your development team can pick it up and take it to production without first translating a mockup into code. If you don't have a development team, that same deliverable is already something that can go live. It is a preference of ours and a recent one: on earlier projects the deliverable was a detailed high-fidelity Figma file.
About to design something, or redesign it?
Book a thirty-minute conversation. We look at your current product or site and tell you whether this helps with what you need or not.