When I have started exploring my self interest in the developer experience domain, I have noticed that the majority of the engineering teams are focusing on conducting surveys methods in (User research). To know the feedback on the product, workflows, architecture, Tooling stack, methods, process to improve experience on these dedicated areas for the engineering teams.
Whether the survey conducting teammate is Engineer or Project Manager not particularly UX designer or the researcher is focused on conducting the survey and working on the analysis results and presents results with the teammates.
Let’s learn why behind the creating surveys:
Most engineering teams focus on surveys because they’re the easiest, fastest, and most scalable way to collect feedback — especially in technical environments.
But there are deeper reasons behind it 👇
Surveys Scale Easily
Surveys are a great fit for engineering teams because they scale well. These teams typically build things like developer platforms, internal tools, APIs, and infrastructure and their users can range from hundreds of internal developers to thousands of external ones. Trying to schedule and run individual interviews with that many people is time consuming and hard to coordinate. A survey solves that problem by reaching everyone at once, requiring far less effort to organize, and delivering results quickly. For engineering organizations that are always busy, that kind of efficiency is really appealing.
Engineers Prefer Quantifiable Data
Engineering culture is built around measuring things. Engineers are used to working with metrics, dashboards, and concrete outcomes so when it comes to understanding their users, they naturally gravitate toward data that feels the same way. Surveys deliver exactly that: percentages, NPS (Net Promoter Score) scores, satisfaction ratings, and trend graphs that can be tracked over time. This kind of output fits neatly into the ways engineering teams already communicate their work, whether that's through OKRs (Objectives and Key Results), sprint reviews, or reports to leadership.
Qualitative methods like interviews and observations, while valuable, can feel too abstract or "soft" to many engineering teams because the findings are harder to put into a chart or tie to a specific number.
Time & Resource Constraints
Most engineering teams don't have a dedicated UX researcher on staff, and the people doing research often have no formal training in it. They just need quick answers to move forward. In that context, surveys feel like the obvious choice, they're low effort, low risk, and can be sent out in a matter of hours. Compare that to something like usability testing or contextual inquiry, which requires careful planning, recruiting the right participants, moderating sessions, and then spending significant time analyzing what you found. That's a real investment of time and resources that many teams simply don't have. So surveys seem like the cheaper, faster path and on the surface, that's hard to argue with.
Perceived Objectivity
There's something powerful about a number. When a survey comes back showing 72% satisfaction or a 6.8 out of 10 usability score, it feels decisive and trustworthy like the data is speaking for itself. Leadership responds well to this because it looks like objective, data-driven decision making. Interviews and qualitative research, on the other hand, can feel subjective to people who aren't familiar with how rigorous those methods actually are. Without that understanding, findings from a conversation can seem like "just opinions" compared to a clean percentage on a slide. So surveys carry a perception of credibility that makes them easier to sell internally, even when the numbers don't always tell the full story.
Tooling Makes Surveys Easy
The tooling available today makes surveys almost frictionless to run. Platforms like Google Forms, Typeform, in-product feedback widgets, and various internal tools let anyone put together and launch a survey in just a few minutes, no special skills required. Deep research methods like interviews or contextual inquiry don't have that same kind of ready-made infrastructure. There's no equivalent "click and go" tool that makes those approaches just as easy to set up and scale. So naturally, teams reach for what's most accessible, and right now, that's surveys.
Engineering Mindset Bias
Engineers are trained to think in systems to optimize, troubleshoot, and find patterns in data. That's a real strength, but it can create a blind spot when it comes to understanding user experience. UX problems are often behavioral, emotional, and deeply tied to context and workflow, which are things that don't surface cleanly in a spreadsheet. Surveys can tell you that 40% of users find a feature difficult, but they rarely explain why the friction exists, what workarounds people have quietly invented, how users are actually thinking about the problem, or where the hidden pain points live. Despite that, surveys can feel sufficient to an engineering mindset because they produce the kind of structured, numerical output that feels familiar and complete. The gap between what surveys capture and what's actually happening in users' workflows often goes unnoticed
The Real Issue
Surveys aren't the problem, it's how they're used.
They're genuinely good at certain things: tracking trends over time, helping teams prioritize, and benchmarking satisfaction across releases. But they have real limits. They struggle to uncover problems you didn't know to ask about, they can't capture the nuance of how someone actually moves through a workflow, and they fall short when the goal is to deeply understand complexity. This matters especially in areas like developer experience, platform UX, and internal tooling, where the problems are often subtle, context-dependent, and buried in the details of how engineers do their work day to day.
Using surveys as the only research method in these spaces means you'll get data, but you'll likely miss the insights that would actually move the needle.
Surveys Are a Starting Point, Not the Whole Story
Engineering teams reach for surveys for all the right reasons — they scale, they produce numbers, they fit into existing workflows, and they're fast to deploy. In environments where time is short and data-driven culture is the norm, surveys feel like the natural, responsible choice. And in many ways, they are. There's nothing wrong with using them.
But the problem emerges when surveys become the only tool in the research toolkit. Surveys can tell you what is happening at a surface level — satisfaction scores, adoption rates, feature preferences — but they rarely explain why it's happening, how users are actually working around it, or what problems haven't surfaced yet because no one thought to ask the right question.
This gap matters most in developer experience, platform UX, and internal tooling — exactly the spaces where engineering teams tend to rely on surveys most heavily. These environments are complex, workflow-driven, and deeply contextual. The friction that slows down an SRE or breaks a platform engineer's flow often lives in the in-between moments — the workarounds, the unspoken frustrations, the mental models that don't match the system's design. A survey won't find those. An interview will.
The path forward isn't to abandon surveys. It's to use them for what they're genuinely good at — tracking trends, benchmarking, and validating at scale — while pairing them with qualitative methods that can uncover the deeper behavioral and contextual insights that numbers alone can't capture. Interviews, usability testing, and contextual observation aren't replacements for surveys. They're complements to them.
The most effective research practice is a mixed-methods one. Use surveys to scale. Use qualitative research to understand. Use both together to build products and platforms that engineers actually love to use.
Top comments (0)