I've lost count of the enterprise projects I've seen where user research amounts to a single workshop at kickoff, three personas written in a boardroom, and then 12 months of building based on assumptions. The irony is that enterprise software affects more people, for more hours per day, than any consumer app. And yet the investment in understanding those people is almost always lower.
What You Need to Know
- Enterprise user research doesn't need to be slow or expensive, but skipping it is always more expensive than doing it
- Stakeholder interviews aren't user research. The people approving the budget aren't the people using the system
- Contextual inquiry (watching people work in their actual environment) catches things interviews never will
- Personas should come from research, not assumptions. A persona built in a boardroom is fiction
The Enterprise Research Problem
Consumer product teams have largely accepted that user research is part of the process. Not all of them do it well, but the principle is established. Enterprise is different. Procurement processes, long sales cycles, and committee-based decision-making mean the people who buy the software and the people who use the software are almost never the same people.
The person who signs the contract has never done the job the software is supposed to support. That gap between buyer and user is where enterprise projects go wrong.
Rainui Teihotua
Chief Creative Officer
The result is software designed to satisfy a requirements document rather than to support a workflow. It ticks every box on the specification. And the people who use it eight hours a day find workarounds for half of it.
What Actually Works
Stakeholder Interviews (But Know Their Limits)
Start with stakeholders. You need their perspective on business goals, constraints, and politics. But don't confuse their perspective with user insight. A department head can tell you what they want the system to do. They can't tell you how their team actually works day-to-day, what shortcuts they've developed, or where the real friction is.
We typically run 6-10 stakeholder interviews at the start of an engagement. They're valuable for understanding organisational context, success criteria, and political dynamics. They're not a substitute for talking to users.
Contextual Inquiry (The One That Changes Everything)
This is the technique that consistently delivers the most useful insights. You sit with the person who'll use the system and watch them work. In their environment. With their actual tools. Doing their actual job.
It sounds simple. It is simple. And it catches things that no amount of interviewing will surface.
People don't accurately describe their own workflows. Not because they're lying, but because so much of what they do is habitual. They don't mention the spreadsheet they keep on the side because "everyone does that." They don't mention the five-step workaround for the current system because they've been doing it so long it feels normal. You only see these things by watching.
At IDESIGN, we aim for 4-8 contextual inquiry sessions per project. That's enough to identify the major patterns without turning research into a project in itself.
Persona Development (From Data, Not Imagination)
Personas are useful when they're built from research. They're dangerous when they're built from assumptions.
A good persona captures:
- Goals. What this person is trying to achieve (not what the system does, but what they need to accomplish)
- Context. Where they work, what tools they use, what pressures they're under
- Pain points. What frustrates them about their current workflow
- Behaviours. How they actually work, including the workarounds
A bad persona is a demographic profile with a stock photo and a made-up quote. We've all seen them. They look professional and tell you nothing useful.
Journey Mapping (For the Workflow, Not the Feature)
Map the user's workflow, not your feature list. Start with how work flows through their day. Where does information come from? Where does it go? Where do they wait? Where do they switch tools? Where do they make decisions?
The features you build should support this workflow. Not the other way around.
Making Research Practical for Enterprise
The biggest objection we hear is time. "We don't have time for research. We need to start building." This is backwards. Research reduces build time by preventing rework. But I understand the pressure, so here's how we keep it practical.
Week 1: Stakeholder interviews (remote, 45 minutes each). Understand the organisational landscape.
Week 2: Contextual inquiry (on-site, 2-3 hours each). Watch 4-6 users work. Take notes. Take photos (with permission). Capture the actual workflow.
Week 3: Synthesis. Build personas from real data. Map actual journeys. Identify the three to five pain points that matter most.
That's three weeks. Often less. And the clarity it provides saves months of rework later.
50%
estimated reduction in late-stage design changes when upfront user research is conducted
Source: Nielsen Norman Group, ROI of Usability Research
The Payoff
The projects where we've done proper user research deliver differently. Not just better designs, though they do. Better outcomes. Users adopt the system faster because it fits their workflow. Training costs drop because the interface matches their mental model. And the post-launch feedback shifts from "this doesn't work" to "can we add this?" - which is a fundamentally different conversation.
Enterprise software has the highest stakes and the lowest investment in understanding users. That's starting to change. But not fast enough.