How I work
My process comes from three places: Bruno Munari's projectual methodology, the Double Diamond, and Teresa Torres's continuous discovery. I do not run all of it on every project. What changes is depth: how much research, how faithful the prototype, which version of the Design QA scorecard. What never changes is the order. Data is collected before a solution is drawn, analysis comes before ideas, and nothing reaches production without being measured. The diagram below marks both: solid lines are the steps I never skip, dashed lines are the ones that adapt to the project.
Discover
The problem, its definition, and its breakdown into smaller problems that can be solved one at a time. Then the collection: benchmark of comparable products, desk research, interviews and surveys with the people who will actually use the thing. Munari is strict here and I keep it that way. You do not move on until you know the limits of the work.
Define
Analysis of everything collected, insight mapping, and the cut. This is where the design challenge gets framed, and where the honest answer is sometimes that the problem is not the one we were asked to solve.
Ideation
Munari's most useful idea sits here: creativity replaces the intuitive, artistic idea, and it stays inside the limits of the problem. Ideas come out of the analysis, not out of imagination. Then the practical constraints (tools, stack, team), the flows and the screens, and a low fidelity model.
Delivery
Usability and concept testing on a high fidelity prototype with real users, the final design, and a specified handoff. Standard processes stop here. Mine does not.
Quantitative Design QA, the UXQA method
Between design handoff and production, every screen goes through a rubric based heuristic evaluation. A UX scorecard weights usability against Nielsen's heuristics at 30%, accessibility against WCAG at 25%, visual consistency with the prototype and the design system at 25%, and efficiency at 20%, into a single acceptance rate. Items that do not apply to a screen drop out of the denominator instead of dragging the score down. That rate is the acceptance criteria, and it is a quality gate rather than a review: at 90% or above the screen ships, between 75% and 89% it ships with a dated fix backlog, and below 75% it goes back to engineering with specific, actionable findings. MEI, the Integrated Evolution Method, came later but runs earlier. It is a separate process that belongs to the first phase of a project, next to the briefing: a weighted baseline per criterion, and targets per milestone (Sprint 1 to 70, Sprint 2 to 82, Go Live to 90). Design QA measures what was built. MEI decides what good has to mean before anything is built. I built it at Itaú Unibanco for the Salesforce ecosystem, in two versions: full for complex projects, reduced when speed matters. None of these instruments are new. Scorecards, quality gates and rubric based evaluation are established practice, and the method sits close to ISO/IEC 25010 and Google HEART. What is rare is getting a gate like this to run inside a regulated bank, with engineering as co-author, and to see it picked up by designers on other teams who were never required to use it.
Continuous discovery
In Teresa Torres's sense: the project does not end at launch. Heat maps, product data and continuous interviewing feed the next cycle. This is the one movement that depends on the project having a life after go live, and on my having access to the data. When that access is not there, I say so instead of pretending the loop closed.
Who is in the room
Business, data and engineering, on every one of these movements, since 2020. In the Design QA the engineering team is not consulted, it is co-author: where the gate sits in the flow was decided together with business and development, not handed to them.
What changed since 2023
The process above did not change. What changed is who does parts of it.
- Discover
- Meeting notes, transcripts, and insight mapping over raw research material.
- Define
- Data analysis.
- Ideation
- Prototypes that actually run, instead of clickable Figma files.
- Delivery
- Implementation.
The interview is still me on a call with a family. The design decision is still mine: in CoIn, making the allowance unconditional contradicted what the interviewed parents asked for, and no model makes that call. Design QA acceptance is the same. The score is calculated, the judgement of what counts as an acceptable deviation is not.
I use Claude Code, Lovable and Codex for the tasks above. The tools will change. What does not is that the research and the decisions stay mine.
Live
- Onde Assisto
Search a film or series and see which streaming services carry it in your region. Live, no sign up. The interface is in Portuguese.
- CoIn
A financial education app for families, built from my thesis at FAU USP. The prototype became a running product. The landing page is public and the interface is in Portuguese.
