Frequently asked questions

I come from a traditional product design background: user research, validation, interaction design, UI craft, prototyping, and building and maintaining design systems in Figma.

Over the last few years, my practice has moved closer to design engineering. I still bring the same product and design fundamentals, but now I also work directly in codebases using AI-assisted development tools.

I think of myself as a product designer whose medium has expanded beyond Figma.

I bring together three areas that are often treated separately: strong visual craft, product thinking, and a growing design engineering practice.

I care deeply about how an interface looks and feels, but I also care about why we're building it, what users actually need, how the business benefits, and whether the solution can realistically be implemented.

More recently, I've been working directly alongside engineering in the same repositories and using AI-assisted coding to reduce the distance between a design decision and the actual product.

I'm most interested in roles where I can keep pushing the boundaries of product design, AI, and design engineering.

I'm especially excited about teams building AI products, developer tools, agentic experiences, or new ways of creating software. Big tech and AI companies are particularly interesting to me, but I'm not limiting myself by company size or title.

The thing I care about most is being somewhere where I can keep learning, experimenting, and helping shape what product design becomes next.

I'm not a software engineer, and I don't pretend to be one.

I understand how modern product codebases work, can navigate Git, create branches and pull requests, make UI changes, and work with AI coding agents such as Claude Code, Codex, and Cursor.

More importantly, I understand my boundaries. I know which changes I can safely own and when something needs an engineer.

I don't see AI-assisted coding as replacing engineering. It simply allows me to work much closer to the product I'm designing.

Absolutely.

I've spent years working deeply in Figma, building component libraries, tokens, variables, modes, documentation, and scalable design systems. I've also mentored designers on how to use and maintain them.

Figma is still a great tool. It's just no longer the boundary of my work.

When it makes sense, I prefer moving from Figma into the actual product much earlier.

Sometimes.

Figma can still be the right handoff depending on the team, repository, security requirements, and level of access I have.

But it's no longer my only way of working.

I've designed directly in product code, created branches, and handed engineering a working implementation as the starting point instead of asking them to recreate a static design from scratch.

It depends on the environment.

If I have repository access, my preferred workflow is to create the design in a branch, open a PR, and let engineering take that implementation forward into production.

If direct write access isn't appropriate, the same work can be handed over through a patch, bundle, or another workflow agreed upon with engineering.

The important part isn't the format. It's reducing unnecessary translation between design and implementation while respecting the technical and security boundaries of the team.

The boundary has become blurrier, but it still exists.

I can comfortably own many interface-level changes: layouts, components, interactions, states, icons, styling, and other product UI decisions.

When the work involves architecture, databases, authentication, security, infrastructure, or complex application logic, that's engineering territory.

Designers and engineers don't suddenly become the same role because AI makes code easier to produce. We can simply collaborate much closer than before.

Very closely.

In some projects we're working in the same repository, discussing constraints together, reviewing the actual experience, and iterating on the same product rather than working across a Figma-to-development divide.

Technical constraints are not something I see as engineering "blocking" design. They're part of the problem we're solving together.

No.

I can review the implementation from a product, UX, interaction, accessibility, and visual QA perspective, but I don't perform technical code reviews.

I'm a designer working closer to engineering—not a software engineer responsible for architecture, security, or engineering quality.

It depends.

I've worked with Design Thinking, Double Diamond, Design Sprints, Shape Up, and other structured methodologies. I know how to use them, but I don't believe every project needs the same process.

A new product, an optimization inside an existing funnel, and a two-week experiment shouldn't all be approached in exactly the same way.

My process adapts to the problem, the team, the time available, the budget, the evidence we already have, and the level of risk involved.

The method is a tool. The goal is to understand the problem well enough to make a good product decision.

I start by trying to understand what is actually happening.

That might mean talking to users, watching session recordings, looking at analytics, speaking with customer success, reviewing support conversations, talking to stakeholders, or digging into the existing product.

I don't like jumping into solutions before I understand the problem.

Ambiguity usually becomes manageable once you identify what you don't know and who—or what—can answer it.

There's always more research you could do.

The question I ask is whether we have enough evidence to make the next decision with reasonable confidence.

Sometimes that comes from interviews. Sometimes usability testing, analytics, customer feedback, or existing behavioral data already tells us enough.

I prefer learning in cycles: gather enough information to move forward, build or prototype something, learn from what happens, and continue refining.

Research should reduce uncertainty, not become a reason to avoid making decisions.

A product needs all three.

A technically perfect experience that doesn't support the business isn't sustainable. A product that hits a business KPI but creates a terrible experience eventually creates another problem. And an ideal UX that cannot realistically be built isn't a solution.

I start by understanding the business outcome we're trying to achieve, then the user behavior required to make that possible, and finally the technical reality we're designing within.

The job is rarely to maximize one of those things. It's to find the strongest solution inside all three.

I start with the outcome we're trying to create.

What needs to change for the business or the user?

From there I work backward toward the smallest meaningful version that can create that outcome and teach us something.

"Easy to build" is useful information, but it isn't automatically the right prioritization strategy. The thing we ship still has to solve the problem.

AI is integrated throughout my workflow.

I use it for research, competitive analysis, benchmarking, synthesizing large amounts of information, exploring transcripts, finding patterns, generating and testing ideas, building prototypes, working with codebases, creating UI, automating repetitive tasks, and running experiments.

I also build reusable skills, instructions, and agent workflows instead of starting from zero every time.

The biggest change is speed. Work that previously required multiple disconnected tools and handoffs can now happen inside a much tighter feedback loop.

AI doesn't make the product decisions for me. It gives me much more leverage when executing them.

Completely.

My workflow today looks very different from even a year ago.

I can explore more directions, process more information, prototype at much higher fidelity, test ideas inside real product environments, and move from a decision to something tangible much faster.

The biggest shift isn't just productivity. It's that the gap between designing something and building enough of it to evaluate the real experience has become much smaller.

Not necessarily.

Product design is already a broad discipline, and I don't think every designer needs to evolve in the same direction.

Some designers will move deeper into strategy. Others into research, systems, design operations, leadership, or other specialties.

Design engineering is another branch of that evolution.

And even within design engineering, "coding" increasingly means something different. I don't manually write most code from scratch. I work with AI coding agents and need enough technical understanding to direct them, evaluate their output, and know when engineering expertise is required.

For many designers and teams, yes.

For me, no longer exclusively.

When design and engineering can work on the same product surface, we're no longer comparing a prototype with an implementation. We're evaluating the actual experience.

That shared medium dramatically improves the conversation between design and engineering.

Agents interpret systems differently from humans.

They're highly literal, instruction-driven, probabilistic, and influenced by the context they're given. They don't "understand" a design system the same way a human designer does.

Designing for agents means structuring rules, patterns, constraints, examples, and product knowledge in ways an LLM can reliably use when generating interfaces.

The goal isn't to make LLMs deterministic. Their non-determinism is part of what makes them useful.

The goal is to give them a better environment in which to make decisions.

Because agents are becoming active participants in how software gets built.

Traditional design systems were primarily written for humans: designers interpret Figma, engineers interpret documentation and Storybook, and then implementation happens.

Agents can generate interfaces in seconds, but without enough context they'll also make inconsistent decisions very quickly.

A machine-readable design system gives them the same kind of product context we expect a human contributor to learn: tokens, components, composition patterns, design rules, and examples of how those rules appear in complete screens.

The point isn't to compete with AI on speed.

It's to give AI better constraints.

The Onion Design Framework is a design framework for LLMs.

It structures a product's design language into layers that agents can progressively use: tokens, primitives, composed patterns, written rules, and screens.

Instead of giving an agent a collection of components and hoping it interprets them correctly, the framework provides increasingly rich context about how the product should behave and how interfaces should be composed.

The goal is consistency: allowing humans and AI agents to build new product experiences while preserving the intent of the design system.

AI helped me create parts of it, in the same way Figma, code, analytics tools, and other software help me do my work.

I use AI heavily, but I'm still responsible for the problem framing, design decisions, direction, evaluation, constraints, iteration, and final outcome.

The tool changed.

The responsibility didn't.

Hermosillo, Sonora, Mexico.

I'm based in UTC−7, but I've spent most of my career working with distributed teams and I'm comfortable adjusting my schedule when collaboration requires it.

Yes.

Most of my professional experience has involved working with US-based clients and distributed teams.

Yes.

For the right opportunity, I'm open to relocating.

Absolutely.

I'm open to the right opportunity.

I'm primarily interested in work where I can continue growing at the intersection of product design, AI, and design engineering, whether that happens through a full-time role or another meaningful collaboration.

I'm less focused on optimizing for a specific title than on the scope of the work.

I want to keep growing into roles where I can contribute strong product design fundamentals while pushing further into AI-native product development and design engineering.

Yes. I work professionally in both English and Spanish.

A significant portion of my work is covered by NDAs or confidentiality agreements, so I can't publish everything I've worked on.

The projects in this portfolio were selected specifically because I can discuss them publicly without exposing confidential client information.

The easiest way is by email:

arelyriverap@gmail.com