Developer Experience (DevEx) Designer Challenges and How to Overcome Them (Part : I)

When I moved from a general UX role into Developer Experience (DevEx) design, I thought the transition would be simple.

I assumed: Same UX process… just a more technical domain.

But I quickly realized something important:

• 👉 DevEx is not just UX in a technical space.
• 👉 It's a completely different design problem.

After working on open-source and developer-focused projects, I faced challenges that I couldn't find clearly documented anywhere. So I'm sharing what I learned for UX designers, researchers, and even developers working in this space.

Challenge 1: Wide and Unclear Learning Scope in DevEx

One of the biggest challenges in Developer Experience (DevEx) design is this:

There is too much to learn, and it's not always clear what to prioritize.

Depending on the project, the focus can change completely:

• One project may require understanding CLI tools and workflows
• Another may focus on documentation UX
• Some require working closely with APIs and developer onboarding
• Others involve improving end-to-end developer workflows

This creates confusion:

• What should I learn first?
• How deep should I go technically?
• Am I focusing on the right area for this project?

It's easy to feel overwhelmed or try to learn everything at once — which is not practical.

Solution: Learn Based on the Project Context, Not Everything at Once

Instead of trying to master everything in DevEx, focus on just-in-time learning based on your project needs.

1. Start with the Core Workflow

Before diving into tools, understand:

• What is the developer trying to achieve?
• What is the end-to-end workflow?

For example: "Deploying a model" or "setting up a cluster"

This gives you a clear direction for what actually matters.

2. Go Deep in One Area Per Project

Each project has a primary focus. Identify it early:

• If the project is CLI-heavy → learn commands, flags, and usage patterns
• If it's documentation-focused → focus on structure, navigation, and clarity
• If it's API-driven → understand endpoints, request/response patterns
• If it's workflow-heavy → map the entire journey across tools

You don't need to master everything just go deep where it matters.

3. Learn Just Enough Technical Depth

You don't need to become a developer, but you do need:

• Enough understanding to ask the right questions
• Ability to follow conversations with engineers
• Context to design meaningful solutions

Focus on:

• Concepts over implementation details
• Workflows over code

4. Collaborate with Developers as Learning Partners

Instead of learning everything alone:

• Ask developers to walk you through workflows
• Observe how they use tools in real scenarios
• Clarify terminology and assumptions

This accelerates your learning and builds trust at the same time.

5. Build a Mental Model, Not Just Knowledge

Over time, aim to connect the dots:

• How CLI, APIs, and documentation relate to each other
• How developers move across tools
• Where friction usually happens

This helps you move from:

"I learned a tool" to "I understand the system"

Key Takeaway

In DevEx, the challenge is not just learning, it's knowing what to learn and when.

The most effective approach is:

• Focus on the developer's workflow
• Go deep based on project needs
• Learn continuously, but intentionally

You don't need to know everything. You need to know what matters for the experience you are designing.