For twenty years the job has been the same underneath: take something complicated and make it feel simple and trustworthy to use. Only where it shows up changes: from the logos and print I started in, to the apps I design now, to the AI agents I’m designing today.
Graphic design is a wide umbrella. This is the honest list of what lives under it for me: one craft, pointed at steadily bigger problems.
The mark and system a company is known by: the logo, its palette (set of colors), the whole feel.
Art drawn by hand from clean, scalable shapes (vector): characters, tattoo flash (ready-to-ink designs), and small numbered prints.
Work that has to hold up in the physical world: brochures, packaging, and dielines (the cut-and-fold templates behind a box).
Things that move: animated logos and brands, short videos, the occasional 3D piece.
How products work and look, and the design systems (shared kits of reusable parts) that hold them together. My lead practice.
Designing how people work with AI: automation they can actually trust.
jump down ↓Long before product UI, the work was brand identity, illustration, and animation, the craft everything since is built on. A slice of it: tap a logo or drawing to enlarge it.
Two halves, one job. UX (user experience) is how it works: the path, the order, whether it feels effortless. UI (user interface) is how it looks: the type (fonts), color, and controls you actually touch. I do both. Here’s the sequence I run to get there, step through it:
Before anything gets drawn, I define the real problem: who uses this, what they’re trying to finish, and what’s in their way. The work starts by listening.
The fastest way to ship consistent product at scale isn’t designing screens one by one. It’s designing the kit the screens are built from. I build and look after design systems: the tokens (saved values for color, spacing, and type), the reusable components, and the patterns that keep dozens of surfaces coherent, so design and engineering work from one source of truth (a single place everyone trusts). Here’s one I built end to end.
An agent is automation you set up once and let run on its own: software that watches your work and does things with it. Point it at a stream of incoming items (tickets, orders, requests, records of any kind) and it can act on each one: flag the risky ones, sort and label them, route them to the right place, or follow up with someone who’s gone quiet.
The hard part was never the automation. It was the interface (the screens people use to set it up). The people setting these agents up are everyday professionals, not engineers, and because an agent acts on its own, a setup screen they can’t read isn’t just annoying, it’s a trust problem. If someone can’t tell what their agent will do, they won’t turn it on. That’s the problem I design against.
Tell it what you want, in your own words:
None of this is about the model (the AI) being clever. It’s about being honest and legible (easy to read and understand). These are the principles I designed the whole thing around.
Everything the agent follows is an “instruction”, never a rule, task, step, or workflow. I locked the vocabulary across the whole feature, because switching terms is how people lose the thread on an already-abstract idea.
Every instruction, goal, and change arrives as a proposal with a button. The system says what it will do, never what it’s done. On something that runs autonomously (acts on its own), that gap between proposed and live is the entire basis of control.
An agent’s capabilities are framed as a kit it was given (the tools it actually uses), not a list of everything it wasn’t forbidden. It turns a wall of pre-ticked checkboxes into a legible “here’s what this can do,” and makes granting a new power deliberate.
When someone asks for something the product can’t do, it says so plainly and offers the nearest real thing. It never quietly maps the request onto the closest available tool. Approximating “flag the risky ones” by acting on everything is worse than doing nothing.
When the agent offers options, they’re built from the user’s own tags, statuses, and fields: “tag it High Risk when the risk score is 80 or above,” not a vague “tagging.” You see the outcome before you commit to it.
A configured agent describes itself back in plain language, and a review pass reveals dead weight, conflicting instructions, and gaps, so people catch problems they’d otherwise never notice.
Whether it’s a logo, a product surface, or an autonomous agent, the job underneath doesn’t change: take something complicated and make it feel simple, clear, and safe to use.
The tools keep changing. The part I keep is the one that doesn’t: making complex things legible, and making people trust them enough to use. That’s the practice, and where it’s headed. Carlos