When first starting to conduct user interviews in Developer Experience (DevX), many designers make a common mistake: they sit down and immediately begin writing questions. The natural instinct is to jump straight into the tactical details:
- Should I focus on the MVP?
- Should I recruit frontend developers or backend engineers?
- Should I structure it by job title?
The assumption is that the interview guide is the first step in the process. However, this is incorrect.
The real first step is something most designers skip entirely and it's critical to get right before any questions are written.
When first starting to conduct user interviews in Developer Experience (DevX), many designers make a common mistake they dive straight into writing questions without establishing the foundation first.
Start With the Research Objective — Not the Questions
Before writing a single interview question, ask yourself:What decision will this research influence? If you can't answer that clearly, your interview will become a "nice conversation" instead of actionable research.
Your research objective should be specific and tied to a real problem. For example:
- Are you trying to reduce friction in a CI/CD setup?
- Are you improving onboarding for a developer tool?
- Are you validating a new CLI workflow?
- Are you testing a dashboard usability issue?
Your questions must serve a purpose. Not curiosity. Not assumptions. Not "let's just explore."
When the objective is clear, the structure becomes obvious and every question you write will drive toward insights that actually inform decisions.
When first starting to conduct user interviews in Developer Experience (DevX), many designers make a common mistake they recruit participants based on job titles rather than what actually matters.
Don't Start With Job Titles — Start With Behaviors
One of the biggest traps in Developer UX research is recruiting by title. You'll often see teams say:
"We need to interview 5 frontend developers and 5 backend engineers."
But here's the problem: job titles don't define behavior. Two developers with the same title can have completely different workflows, responsibilities, and pain points.
Instead of recruiting by title, recruit by responsibility and behavior. Ask screening questions like:
- Do you set up CI/CD pipelines?
- Do you manage infrastructure configurations?
- Are you responsible for debugging production issues?
- Do you maintain internal developer tools?
Behavior > Job Title
This shift in approach matters because UX problems live in workflows—not in LinkedIn titles. When you recruit based on what people actually do, you'll find participants whose experiences directly inform the decisions your research needs to support.
Where Does MVP Fit In?
Another common confusion arises when designers ask: "Should I design the interview around my MVP?" The answer depends on the type of research you're conducting. There are two major types of interviews in Developer UX, and understanding when to use each is critical.
1. Discovery Interviews (Before You Build)
This is where many teams rush—but discovery interviews are about understanding, not validating your solution.At this stage, you are validating the problem, not the solution.
Discovery interviews focus on:
- Current workflows
- Friction points
- Workarounds
- Mental models
- Tool ecosystems
You ask questions like:
- Walk me through how you deploy your application.
- What tools are involved?
- What usually slows you down?
- What's the most frustrating part of your workflow?
- When was the last time something broke? What happened?
Notice something important: You're not pitching. You're not suggesting features. You're not leading. You're learning reality. This stage prevents you from building a beautiful solution to a problem that doesn't matter.
2. Evaluative Interviews (After You Have an MVP)
This is when your MVP becomes central to the research. Now you're testing execution rather than discovering problems.
Evaluative interviews focus on:
- Clarity
- Usability
- Learnability
- Workflow alignment
- Mental model match
Questions shift to:
- What do you expect to happen when you click this?
- How would you approach this task?
- Is anything confusing?
- What feels unclear or unnecessary?
Here, you are validating execution—not discovering the problem.
The Right Order for Developer UX Interviews
If you want your research to create real impact, follow this order:
- Step 1: Define the Research Goal — What decision will this research inform?
- Step 2: Define Behavioral Criteria — Who actually performs this workflow?**
- *Step 3: Decide Interview Type *— Discovery or Evaluative?
- Step 4: Write Focused Questions — Only after the above is clear.
A Simple Structure You Can Use
Here's a clean framework you can adapt for any Developer UX study:
1. Screening Questions
- What is your role?
- How many years of development experience do you have?
- What tools do you use daily?
- Are you responsible for deployment or infrastructure setup?
2. Context Questions
- Can you describe your current development workflow?
- What tools are central to your process?
3. Workflow Deep Dive
- Walk me through your last deployment.
- What steps are manual vs automated?
- Where do you switch tools?
4. Pain Points
- What frustrates you most?
- What takes longer than it should?
- What do you wish was simpler?
5. Opportunity Signals
- If you could improve one thing, what would it be?
- What tools have you abandoned and why?
This structure keeps the conversation focused and actionable.
The Biggest Mistake in Developer UX Research
Many teams jump straight to solution validation. They say: "We built a better dashboard—let's test it."
But if you didn't deeply understand the following, you risk solving a surface-level issue:
- How developers think
- Where friction truly exists
- What trade-offs they accept
- What constraints they operate under
Developer workflows are complex. They include automation, scripts, legacy systems, internal tools, and cognitive shortcuts. You must understand the ecosystem before improving it.
Conclusion
If you're confused between focusing on MVP or demographics, remember this:
- MVP matters only after the problem is clear.
- Demographics matter only when they affect behavior.
- Research objective always comes first.
When you prioritize clarity of purpose over question-writing speed, your interviews stop being conversations—and start becoming strategy.And that's when Developer UX research becomes powerful.
Top comments (0)