Navigating the unknown. How to design for highly technical domains?

Ever walked into a room where everyone’s throwing around buzzwords and jargon you’ve never heard before? Yeah, that’s what designing for highly technical domains feels like most of the time.

You’ve barely caught your breath, and suddenly you’re trying to wrap your head around workflows that sound like something from a sci-fi novel. It’s overwhelming. Your brain is juggling a million concepts, and then there’s a list of things you need to learn that just keeps getting longer.

Oh, and did I mention you’re also working with technical stakeholders who may have never worked with a designer before? Yep, that’s the cherry on top.

It might feel like you’ve been dropped into the middle of a conversation in a language you don’t speak. I know this feeling well because when I first started, I was drowning in jargon, complex models, and workflows that seemed impossible to untangle. But the challenge wasn’t just understanding the language — it was figuring out how all the pieces connected and how they impacted the business.

But hey, it’s not all bad.

Having spent five years in this world, I can tell you that designing for these spaces is one of the most rewarding challenges out there. There’s a lot of room for simplifying the complex, and let’s be honest, that’s where we designers thrive.

The problem, though, is wrapping your head around the domain itself. It’s like standing at the bottom of a mountain looking up, wondering how the heck you’re going to climb it. You want to make time to learn all the things, but your day is already packed. Sound familiar? I’ve been there too.

The designers who nail it in these domains? They’re the curious ones. They’re not afraid to step out of their comfort zones and ask questions — even if they feel clueless at first. And the more they learn, the more strategic they become. So, if you’re feeling lost in a sea of technical terms or can’t seem to make sense of a new domain, today we'll talk about six strategies that’ll help you navigate the chaos — and maybe even enjoy it.

Personal experience

One of the trickiest domains I’ve worked in has been external data platforms, where data engineers handle immense volumes of information. This isn’t your typical app or website. Here, the focus is on manipulating, transforming, and analyzing data, often with industry-specific processes and terminology that can leave even the most seasoned designer scratching their head.

At first, understanding the workflows felt like walking into a room full of people speaking a language I didn’t know. I had to understand not just how the platform worked but how it fit into the larger picture — how data engineers used it, what their pain points were, and how this impacted the businesses that relied on it.

I’m not someone who shies away from tough challenges, so I dove in. The key to my breakthrough? Finding relatable references. Even the most complex workflows have something in common with everyday experiences — whether it's explaining a data pipeline like a plumbing system or comparing intricate business models to something more tangible.

The moment I could relate these concepts to something I already understood, things started clicking. And I found a way to explain what I had learned in a way that made sense to others, too.

1. Start with the basics (seriously)

When you’re dropped into a new technical space, the first thing you need is a game plan. And that plan? It’s all about breaking things down into three key areas:

• The Product: What problem does it solve? Who’s the competition? How does it even work?

• The Users: Who are they? What are they trying to achieve? Where does the product help them — and where does it leave them frustrated?

• The Domain: What’s the foundational knowledge here? Think jargon, workflows, history, and the trends shaping the space.

When I first entered these complex spaces, I felt like I was drowning in new information. So, I started keeping a log of all the technical terms that kept popping up. In my downtime, I’d look them up. Slowly but surely, things started to make sense, and I didn’t feel as lost.

It also helped to sketch out flowcharts and diagrams — visuals to map out how everything connects. This not only filled in the gaps in my knowledge but became a handy onboarding tool for others on my team. Over time, you start to see the relationships between the product, users, and the technical domain, and that’s when things really start clicking.

2. Ask stupid questions

I’ve never been afraid of looking stupid. In fact, asking so-called “stupid” questions has been my superpower in technical domains. Whenever I didn’t understand something, I asked. And the more I asked, the clearer things became.

Coming from a technical background as a developer helped me, too. I knew how things should work under the hood — what made code function and what didn’t. This background gave me a head start when it came to understanding new concepts and figuring out how they applied to the design process.

So, when I needed to learn fast, I asked. I didn’t mind if the question seemed dumb because, at the end of the day, clarity was more important than saving face. And that curiosity opened doors — it led to deeper conversations and a much quicker understanding of the domain.

3. Make friends with experts

One of the most valuable moves I make when starting a project is investing time upfront with the experts. I spend the early days not just sitting in front of a screen but actively engaging with stakeholders, product managers (PMs), and subject matter experts (SMEs). These are the people who live and breathe the product. Their insights give me a holistic understanding of not just how the product works, but why it exists and how it serves the users.

If you want to fast-track your understanding, build relationships with Subject Matter Experts (SMEs) and key stakeholders. These are the people who’ll give you the inside scoop and help you see things from different angles.

At one of my previous projects, I connected with a bunch of sales experts early on. These folks had deep technical knowledge and were working with customers every day. Their insights were pure gold because they weren’t just theoretical — they were based on real customer experiences. Soon, these sales experts became my go-to when I needed feedback on a design or to get a quick pulse on what customers were struggling with.

4. Watch users in action

You can read all the research reports you want, but nothing compares to watching real users in action. Whether they’re stumbling over a task or breezing through it, observing them will give you insights that no amount of desk research can.

Start meeting with your users, and you'll see the shift in your designs. You won't be guessing anymore — you'll design based on real-world interactions.

If you can’t get direct access to users, ask to sit in on calls with your PM or researchers. Even if you’re just a fly on the wall, you’ll pick up invaluable insights.

5. Use the product (actually)

I worked with this designer once who was pretty much a legend in the company. He wasn’t just good at design; he knew the product inside and out because he used it every single day. He wasn’t just designing for users — he was one.

This guy inspired me to dive into the product I was working on. And while it’s tough, especially when you’re working on a product outside of your day-to-day world, using it yourself changes everything. You start to see where the product shines and where it completely falls apart. And when you experience the pain points firsthand, you can design with empathy.

At one of my companies, they had a program where new hires would go through key user journeys and share their findings. This wasn’t just a training exercise — it was a way to ensure that everyone, designers included, was using the product and seeing it from a user’s perspective.

6. Share what you're learning

Ever tried explaining something complicated to someone else? It forces you to make sure you actually understand it. Sharing your learnings with others is one of the best ways to solidify your own knowledge.

When I started on an external data product, I shared things I've been working on with the rest of the design team. What started as a simple presentation led to deeper discussions and even revealed gaps in my knowledge. It made me better.

Don’t worry — you don’t have to become a domain expert. You just need to know enough to advocate for your users and be the voice that connects different parts of the company.

Wrapping it up

Designing for technical domains is intimidating, but it’s also a huge opportunity to grow as a designer.

You’re not just creating pretty interfaces — you’re solving complex problems that can have a real impact.

The trick is to stay curious, keep learning, and never be afraid to ask questions (even if they feel dumb). You’ve got this.