The hard part
was never the screen.

I have been a product designer for over ten years. My job is to set design direction and look after design system governance in large products, with a lot of people working on them at once. I also build the AI tools that hold that work up. At Signify I led seven designers across more than one country. Before that, between 2019 and 2021, I built the design practice from scratch at Genial and grew the team to four: I hired, gave feedback, and mentored interns and designers. Always the same way: direction and craft before title.

The screen is the part people see. The heavy work sits before it: turning scattered patterns into a system other teams can use without having to ask, and getting design into the business conversation while the decision is still open.

What I go deep on

Applied AI, concretely: agent systems, human-in-the-loop pipelines, and internal tools I design and run myself. Practice, not vocabulary: design and technology in one motion.

I got here from the bottom. In 2022 I spent nights on a Discord server typing commands at a bot, hoping something close to what I had in mind would come out. It rarely did. Without realising it, I was training the skill everything I do now rests on: asking with precision.

I read CSS, HTML, Python and a bit of JavaScript, enough to talk as an equal with the people who code and with the machine: ask properly, understand what comes back, and catch the moment something does not add up. Becoming a developer was never the point. Design systems taught me this, because that is where design and code actually touch.

And there is the part no agent takes off your hands, which is people. I study people management, mentorship and design leadership as seriously as I study tooling: how someone joins as a junior and leaves able to decide on their own, and what kind of conversation makes that happen.

Accessibility is ongoing study here, and universal design is the root of it: designing for the wide range of people from the start, instead of opening an exception later for whoever was left out. It is the subject where the gap between what a team thinks it shipped and what a person can actually use tends to be widest, and it is what I write about most often.

And there is a question that will not leave me alone: where Brazilian identity went on screen. We design Brazilian products with imported references, and out comes a lot of interface that could have been born anywhere in the world. I am after an answer that fits inside the UI discipline, with rules, criteria and examples, the size of something you can teach.

How I work

I start with the problem. Before designing, I want to understand the real constraint, who's affected, and which business decision is at stake. Design comes in early, where the direction can still change.

I research before I open Figma. Interviews with the people who use it, conversations with the people who run it from the inside, and quantitative work to check whether what I heard holds beyond the people I talked to. That turns into material the team can actually use: personas built on research, empathy maps, what was heard written down with names and frequency. The finding that changes a project is rarely in a benchmark: it shows up when someone describes the actual job, workarounds and all.

I work in the double diamond, and the first diamond is the one that saves the most time. Before proposing anything, I open the problem up: who feels it, how often, what they already tried and why it did not stick. I map the whole journey and, when the pain is a service problem, I go down to the blueprint, which is where the backstage breakage shows up and never reaches the screen. I only close it when the problem fits in one sentence the team repeats the same way. A solution born before that is usually beautiful and solves the wrong thing.

Then lean takes over. Every proposal becomes a hypothesis, and the question turns into what the smallest thing that answers it is: a clickable prototype in Figma, a quick session with someone who uses it, a number analytics already holds and nobody went to look at. I measure instead of guessing. A hypothesis that falls early falls cheap; the same hypothesis six months on has already become roadmap.

Accessibility comes in early, with the first design decision: measured contrast, focus order, touch target size and what the screen reader will announce all shape the layout, and solving it there costs far less than an audit six months later. I run IBM Equal Access in the browser, the contrast and simulation plugins inside Figma, and I listen to the screen on a screen reader instead of only looking at it.

Where I teach

I teach Interface Design and DesignOps at undergraduate and graduate level. Teaching is where practice becomes method: what I do on autopilot has to become an explainable step, and anything that only works in my own context does not survive the first question from a student.