What makes a designer technical?
Technical design 101 with Emilio Garcia (VP of Design at Onum)
Hello! in this this article I am chatting with Emilio Garcia (VP of Design at Onum) on all things technical design. With roles quickly merging in the AI world and products becoming very complex I thought it would be brilliant to speak to Emilio who has worked on technical products the majority of his career. He’s one of these rare designers who has genuinely got an engineering mindset who happens to be a designer.
Emilio is an ambitious designer with over 25 years of experience directly leading design teams of different sizes as well as the strategic design vision.
He specializes in product and user experience design and has contributed those skills to deliver high-quality products for top leading digital companies such as New Relic, Eventbrite, from media to tech startups such as CARTO, Tuenti and currently leading the design vision at Onum.
TL;DR:
How technical designers need to be
Why it matters in 2025
What makes a designer “technical”
How to hire for technical fluency in designers
How Onum had a design system before PMF
How the roles of design and engineering is becoming more blurred
How to level up as a non-technical designer in a very technical domain
How do you define a "technical designer" in 2025?
A Technical Designer in 2025 should be defined as a product designer with an engineer’s mindset and a user’s vision—someone who moves comfortably between technical complexity and ease of use, creating solutions that work great “on the inside” and feel intuitive “on the outside.”
It’s a hybrid that combines the strategic and experience-driven vision of a Product Designer with the ability to understand, design, and prototype solutions for highly complex technical products. Someone who doesn’t just focus on the interface or the experience, but also takes an active role in functional design, conceptual architecture, and the technical feasibility of the product and also (as this should be common for all the type of designers), be able to understand what the company is selling and the Go to Market vision.
What skills or traits separate someone who is technical from someone who isn’t — is it code literacy, systems thinking, or something else?
In general, I think there are a few big differentiating points:
Being able to understand technology overall—how the product works—and being able to design systems, not just screens.
Working closely with engineering teams—not just frontend—understanding how the product’s different APIs work, and being able to have real discussions with them. For example, understanding why you might need to add a “Save Filters” button or, if you save something on the fly, what technical implications that might have.
Someone with critical thinking—it’s super common in these kinds of companies to have a developer come to you and say, “I need a button that does this”. This still happens to me every single day. Having someone who understands why and can find the perfect solution for the user is key.
A strong tech culture—someone who tries new products and stays up-to-date with what’s happening in the market.
And if we want a real differentiator—someone with a special sensitivity for craft. Up until now, these types of products have usually been seen as more functional than beautiful, and I think that’s changing (and should change more). I don’t think those two things should be mutually exclusive. For me, the experience is a combination of both.
What types of companies or problems really demand a technical designer today?
I’ve always liked working in companies with a high level of technological expertise—places where technology is truly at the core.
The market for technical products is growing fast and has already grown a lot in recent years, and I think it’s a space where there’s still a huge opportunity to improve design. In very B2C-focused companies, design maturity has reached a really high level, but in these kind of companies there’s still a long way to go.
I’ve always believed that any company should invest in design from day one, but companies with highly technical products and very complex flows need a specific type of designer—someone who can understand how technology works and how to innovate to create an excellent user experience.
One of the biggest issues technical companies have faced—especially those with very technical products or developer-focused products—is that the design work was often done by engineers themselves (and I’m not just talking about the visual layer, but the entire platform experience). Or they would see designers as the people who would just “make the screens look nice” afterwards. Design used to be treated like a commodity. But that has completely changed—now it’s a real differentiator.
The time it takes for a user to decide if what they’re using feels good or not has shrunk to just a few seconds. If that first impression doesn’t hit, it’s extremely hard to change their mind later. I don’t think GitHub would have become what it is without a mindset that valued design (I think it’s one of the best examples in recent years).
You should also take a look at what Vercel is doing lately in design, or Tines who are doing incredible things with their visual language. At Onum, our CEO has always stated that design should be one of our differentiators, and that it had to be present from the very beginning of the company. Any Pull Request that impacts the interface needs design approval. Of course, right now we can afford to do this because of our company size; in a few years, we’ll see how we’re able to scale it.
What role did technical depth play at New Relic and Onum?
First, I think that to take on a role like this, you really have to like—or at least be genuinely interested in—the sector. I know incredible designers who’ve worked in these kind of companies but decided to leave because they realized they didn’t actually enjoy the space. They were looking for a product that felt more tangible and had a much broader, more mainstream user base.
Then, of course, technical knowledge is important. For example, when I joined New Relic, they were just finishing the migration from the old New Relic to New Relic One. A new landscape in software architecture brings with it new needs for observability tools. They translated the defining characteristics of cloud-based architectures into the core design principles of New Relic One—a product built from scratch to become the best observability platform for this new reality.
At Onum, it was a bit different. I already knew the CEO, and we’d always talked about working together. When he presented me with the idea—being 100% honest—I didn’t really know what I was getting into. It was just an idea at that point, and we had to bring it down to earth and build absolutely everything from scratch. I spent a few months researching the competition, reading about logs and their different formats, and working on defining a solid system for navigating and consuming information.
Did you need technical expertise to have direct impact on the product?
Onum is where I’ve been able to have the most impact.
Obviously, building something from scratch gives you the chance to tackle a thousand and one problems right from the start. One thing I think we did well was starting from the very beginning with a design system. There’s always been this idea that startups shouldn’t spend time on a design system until they have a clear product–market fit, that it’s not useful before then.
But I’ve experienced first-hand the pain of not having solid foundations and then having to implement a design system from scratch later on—once technical debt and design debt start piling up, it’s practically impossible. We started small, with a clear base. We needed design to have control over managing tokens, so almost the very first thing we did—even before the design was fully set up—was to create the connection between Figma and GitHub.
That way, adding or modifying a token wouldn’t be a problem for the engineering team. This has allowed us to generate themes in a pretty fast and transparent way.
Not being left behind in technical discussions etc
Absolutely. When I talk about design in this kind of product, I’m not focusing on the visual side—when I say design, I mean the entire experience. If you join the discussion too late, you might find that technical decisions have already been made that create constraints—and no matter how hard you try to find the best solution, you’re already stuck.
That’s why I believe it’s key to be involved in conversations from the start, with a technical profile—but not as technical as the developers—while always thinking about how things will impact the user. Otherwise, you risk exposing the user to problems that aren’t really theirs, but rather stem from the underlying technical architecture.
How does being technical change how you collaborate with product and engineering?
Collaboration is much easier when you speak the same language and everyone is in the same place. Of course, sometimes there are tensions around where the boundaries are, and often pushing to improve the experience means it’s not always easy.
The company also needs to have a certain level of product maturity and a culture of design to handle this well. But these small differences of opinion—people always talk about being 100% aligned, and that’s quite hard to achieve—ultimately make the output much better for the user.
Should designers code? If not, what level of understanding of engineering do they need?
Short answer: yes, 100%.
Long answer: it depends.
It depends on what we mean by “programming.” In general, when we talk about a designer knowing how to code, we always think of HTML/CSS/JS. But I think the range needs to open up a bit more—we need to think not just about coding, but about understanding technology itself: how an API works, how we can turn a JSON into an interface, how many requests we need to make for everything to run smoothly and for the user experience to be sublime.
For example, at Onum, one of the things we have is auto-generating screens from YAML files. One of the challenges there is understanding how it works and how we can represent different groups, and so on.
In short, it’s more important to know the medium—exactly like a graphic designer knows how a printing press works or how different types of paper affect the outcome, or like a fashion designer understands fabrics. We also need to find a balance—between knowing how to code (and being able to design something that solves a problem in a way that’s easy to implement and technologically sound) and not letting that knowledge limit you, so you can still think of innovative solutions—solutions that, as Steve Jobs used to say, make technology serve the needs of the user, and not the other way around.
Where do you draw the line between being technical and becoming a developer?
20 years ago, I had a moment where I wasn’t 100% sure if my career was going to lean toward becoming a developer. In the end, I went down the design path—but always with one eye on the code.
There was a time when the boundaries were very clearly defined, but I think now that line is becoming more and more blurred—especially with AI tools. I think we could draw that line between being able to ship code to production and “just” creating prototypes. And when I talk about shipping code to production, I’m not talking about simply making a PR to fix a margin or a token (I think every designer should be able to do that).
Should technical designers be shipping production code? Or is their value more in shaping architecture, constraints, and trade-offs?
There’s a difference between knowing how to code and actually shipping things to production.
In hybrid roles, from day one (I’ve shipped things to production in many of my previous companies)—and I admit I’m biased here because of my background—but I think that unless it’s very specific work (fixes, minor changes), or depending on the type of company, a designer’s greatest value isn’t necessarily in putting things into production.
That said, it’s a highly valuable skill—having that “secret weapon” can be key at certain moments. But where this type of designer truly stands out is in understanding constraints, having opinions on parts of the architecture, and ensuring everything fits together into a solid user experience. That’s where their impact can really be a differentiator.
How do you nurture technical fluency on a design team? or do you hire people with?
General rule: I like hiring for a learning mindset and collaboration, and developing the specific technical skills internally. That way, you get designers who can adapt to your product’s unique tech stack, instead of only those who already know it.
I break it down into two main points:
Hire for mindset, not just skills.
Look for curiosity about technology over pure coding experience—a designer who asks “How does this endpoint work?” will learn fast.
In interviews, I like to give them simple system diagrams, constraints, or API docs to see how they think. And I also value past collaboration with engineering—working closely with developers and adjusting designs for backend realities.
Foster technical fluency within the team. Even the most senior hires will have gaps in your product’s tech stack, so make learning part of the team’s culture.
It’s important for designers to be part of sprint planning, backlog refinement, and—if possible—pull request reviews, so they have much more context on everything happening in the product.
Something that’s worked well for me at times is having designers and engineers work side-by-side to prototype flows with real data—bringing real development constraints closer to the designers.
What are the most effective ways for non-technical designers to level up?
Ask questions early and often. Asking a lot of questions doesn’t make you a worse designer—or make you look like one. For example, when you join a company with a very technical product, the best way to improve and truly understand it is to ask questions, talk a lot with product managers, and especially with engineers.
Try to understand how it’s built, the product’s architecture—it doesn’t matter if you don’t understand 100% of every part. Ask for help: Reach out to the more experienced people on the team. Ask for very specific feedback and targeted questions about what you need to know. Start understanding the technology.
Key concepts: APIs, databases, client–server architecture, cloud services, microservices.
Read real API docs and practice simple integrations using tools like Postman.
Dig into performance, security, and scalability so you can understand the technical decisions developers make.
Get familiar with SQL, JSON, and data structures so you can prototype and analyze information.
And find a company to work for where there’s a leader who will help you grow—someone who can lead by example. I think many times it’s better to join a team because of your manager than because of the project itself.
How can you gauge technical depth in an interview?
I think the way someone presents their portfolio matters. For certain roles, showing a static PDF—no matter how good it is—already says something. Another thing I pay attention to in an interview is how they handle certain questions. For example, how they think when faced with challenges like:
Problems handling real-time data
How they choose types of data visualizations for technical audiences
How they plan error messages, loading states, and updates
I also always try to identify how they take into account things like scalability and maintainability.
Do technical designers think differently about design itself?
I don’t think they should think in a fundamentally different way. Any designer should have a deep understanding of the industry they work in—designing an experience without knowing how all the pieces work will leave you with limitations that won’t let you take the product to the next level.
As designers, we have to bring innovation to the forefront and be able to create experiences that hook the user from the very first minute. For example, you may like more, less, or not at all the latest design trends in iOS—but it’s clear that at least they’re trying to innovate, to create something different.
As designers, we have an obligation to build a better internet. Lately, we’re just repeating pattern after pattern, creating things with no soul. I believe that both technical designers and any other kind of product designer need to push for innovation and create experiences that captivate the user from the very first moment.
Thanks Emilio for such great depth.
Until next time!