Skip to content

How I Work

How I Work

I don't start with interfaces. I start by understanding the system.

Most of my work starts the same way: by learning how a system actually operates, not how it’s supposed to and not what the interface implies. That means talking to the people who use it, watching how the work actually gets done, and reading whatever documentation, spreadsheets or workflows already exist. From there the work moves into definition, prototyping and validation. Design Thinking, Lean UX, Service Design, Agile and Design Sprints all inform how I move through that, but none of them run the show. The problem does.

A solution only really works if it holds up on more than one axis at once: useful for the people who rely on it, realistic about how the organization actually runs, technically buildable, accessible, and worth the effort for the business behind it.

01

Understand the system

I start by mapping how the system actually works: the people, the information, the constraints, and the product or business goals involved, not just the interface. Understanding operational reality and business context early is what keeps discovery from staying on the surface.

More on this move

Why it matters

A screen is only the visible layer of a system. Redesigning it without understanding what’s underneath just makes the same problem look better.

How I approach it

Contextual inquiry, stakeholder mapping, and direct process observation, sitting with the people actually doing the work, not just interviewing them about it afterward.

AI and human judgment

AI helps me process and organize a large volume of interview notes, documents and observations faster, but deciding what actually matters, and confirming it with the people involved, stays a human judgment call throughout.

In practice

On Presupuestador, the internal quoting system, that meant sitting on the shop floor at Guzmán Villalba to see how a quote actually got built, with paper, memory and a spreadsheet nobody fully trusted, before assuming the fix was a better form. Related case: Presupuestador (content written, not yet published).

02

Find the real problem

From that map I look for the specific point where user pain, operational friction and barriers to product goals actually meet. Not a general list of issues: naming the real problem precisely is what keeps the rest of the work from becoming decoration.

More on this move

Why it matters

Teams often ask for a redesign when the real issue actually sits one step earlier or later in the process. Solving the wrong problem well is still solving the wrong problem.

How I approach it

Root-cause analysis, journey mapping, and structured evaluation of where the friction actually shows up, not just where it’s reported.

AI and human judgment

AI can help surface patterns across a large set of notes or tickets faster than reading them one by one, but naming which pattern is the real problem, versus just the loudest one, is a judgment call I don’t hand off.

In practice

In Trazur, the interface had real usability issues, but the deeper problem was trust: people didn’t believe the platform understood their situation, so they disengaged before the screen ever became the issue. Related case: Trazur Cursos.

03

Gather evidence

I build the case with whatever evidence is available and relevant: interviews, field observation, workflows, documents, and product data such as errors, time or adoption. User research turns a debate about opinions into a decision grounded in what’s actually happening.

More on this move

Why it matters

A strong opinion in the room isn’t evidence, no matter how senior it comes from. Evidence is what turns a debate about taste into a decision about the system.

How I approach it

Interviews, field observation and, where the volume of material justifies it, AI-assisted synthesis to process more evidence without skipping the review step.

AI and human judgment

AI can help process a larger volume of interviews, documents or notes than would be practical by hand, but every AI-synthesized finding still gets reviewed by a person before it counts as evidence, not just accepted at face value.

In practice

For Trazur, that meant pairing traditional research methods with AI-assisted analysis to work through a heavier volume of material without skipping that review step. Related case: Trazur Cursos.

04

Explore and define

I turn what I’ve learned into structure: prioritised opportunities, hypotheses, information architecture and user flows. I generate several alternatives and compare them on value, effort and risk before committing to one, so the plan stays honest about what it depends on.

More on this move

Why it matters

Every proposal quietly depends on something nobody’s confirmed yet. Finding that assumption, and testing the one that would be expensive to get wrong, is cheaper than discovering it after launch.

How I approach it

Assumption mapping, information architecture, user flows, and comparing alternatives side by side instead of committing to the first workable idea.

AI and human judgment

AI is useful for generating a wider set of alternatives to compare quickly, but choosing which trade-off is actually acceptable for this team, this budget, and this timeline isn’t something AI has the context to decide.

In practice

On Presupuestador, that meant checking with the person who actually prices jobs that a proposed shortcut wasn’t quietly removing a judgment call they relied on. Related case: Presupuestador (content written, not yet published).

05

Design and prototype

Not every problem needs a new interface; sometimes the strongest move is fixing what sits underneath it. When an interface is the right call, I move from structure to interaction and UI: wireframes, prototypes, and reusable components when the project justifies them. Accessibility and responsive behaviour belong here, not in a check at the end.

More on this move

Why it matters

A solution that only works under ideal conditions doesn’t survive a busy shop floor or a slow connection. Practical means it still works on a bad day, and accessibility, clarity and maintainability are considered from the beginning, not added as a final compliance layer.

How I approach it

Service blueprints, wireframes and prototypes, plus systems-level decisions about what actually needs to change versus what just needs to be documented better. I work early with the people who will build it, developers and product included, so handoff isn’t where the surprises show up.

AI and human judgment

AI can help explore layout or content variations faster, but whether a solution is genuinely usable under real conditions, for the people who’ll actually rely on it, gets confirmed with people, not inferred.

In practice

Trazur’s proposed solution was built around low-connectivity, low-fidelity conditions from the start, instead of assuming a fast connection and a confident, tech-comfortable user. Related case: Trazur Cursos.

06

Test, learn and iterate

I treat a first version as a hypothesis and test it with users and against the real context, not just in internal review. What “wrong” would look like, and what to measure, gets defined up front: task success, errors, time, adoption or support load. Iterating against that is what makes the next version better rather than just different.

More on this move

Why it matters

Iteration without a defined target just produces motion, not improvement. Deciding in advance what would prove a version wrong is what makes revisiting it worthwhile.

How I approach it

Usage review, structured feedback loops, and versioned documentation, so a decision made in an early version isn’t lost by the time a later one needs to build on it.

AI and human judgment

AI can help track and summarize feedback or usage patterns over a longer period than I could review manually, but deciding whether a result counts as success, and what to do next, is a human call.

In practice

What success might look like here is fairly concrete: fewer manual re-checks of a quote, less dependency on one person’s memory, or a shorter gap between a request and a usable estimate. Across projects, from Presupuestador to institutional work at Ceibal, the versions that held up were the ones designed to be revisited on purpose, not treated as finished at delivery. Related case: Presupuestador (content written, not yet published).

AI in the work

AI accelerates the work. Human judgment defines the direction.

Across all six moves, AI helps me move faster through research synthesis, documentation, and early exploration, organizing interview notes, drafting first-pass structures, and summarizing longer material. It doesn’t replace the judgment calls: what the evidence actually means, which trade-off is acceptable, and whether a result is good enough to ship stay decisions I make, checked against the people and the system the work is actually for.

See how this plays out on a real project.

View selected work