The person who signs the contract is almost never the person who uses the software. This is the fundamental tension of enterprise design, and it explains why so much enterprise software looks impressive in a demo and fails in daily use. At IDESIGN, we've learned to design for both audiences. It's harder than designing for one. It's also the only way the project succeeds.
What You Need to Know
- Enterprise purchasing decisions are made by stakeholders who evaluate features, cost, and strategic fit, not daily usability
- The people who use enterprise software daily rarely have input into the buying decision
- Designing only for buyers produces feature-rich software that nobody wants to use. Designing only for users produces software that never gets funded
- The solution is involving both audiences from the beginning and translating between their priorities
The Demo That Sells vs The Tool That Works
We've all seen the enterprise demo. The dashboard is polished. The feature list is comprehensive. Every checkbox in the procurement document gets ticked. The CTO nods. The CFO checks the pricing. The contract gets signed.
Six months later, the help desk is flooded. Staff are building workarounds in spreadsheets. The "comprehensive" feature set turns out to include twelve features nobody uses and is missing the three things people need most. Usage drops. The organisation starts talking about "change management" and "user adoption," which are polite ways of saying the software doesn't work for the people using it.
This isn't a failure of technology. It's a failure of audience. The software was designed to impress stakeholders in a meeting room. The people in the meeting room don't use the software.
Two Audiences, Two Languages
Buyers and users care about different things. Not because one group is wrong, but because they have different jobs.
Buyers care about: strategic alignment, total cost of ownership, integration with existing systems, compliance, scalability, vendor reputation, and the feature list that maps to their requirements document.
Users care about: can I do my job faster? Does this make sense? Will it save me time or cost me time? Can I find what I need? Does it work on the days when I'm tired and distracted and have thirty things to process before lunch?
These aren't opposing priorities. But they're expressed in different languages, and most enterprise projects only speak one.
A buyer asks "does it do X?" A user asks "how long does X take?" Both questions matter. The second determines whether the project succeeds.
Rainui Teihotua
Chief Creative Officer
How We Handle It
At IDESIGN, we've developed a practice of bringing both audiences into the process early. Not just consulting them, involving them.
Discovery includes users, not just stakeholders. When we scope a project, we insist on speaking to the people who will use the system daily. Not a representative. The actual people. We watch how they work. We ask what frustrates them. We map their tasks and identify where time is lost. This happens before we propose a solution, not after.
Design presentations speak both languages. When we present design concepts, we show the same interface from two perspectives. For stakeholders: how the system addresses business objectives, handles reporting, and supports compliance. For users: how a typical task flows, how many steps it takes, and how it compares to their current process. Same screens, different narration.
We prototype workflows, not features. Features are a buyer's language. Workflows are a user's language. Instead of showing a list of capabilities, we walk through a complete task: "Sarah arrives at work, logs in, sees her tasks for the day, processes the first request, escalates the second, and runs the end-of-day report." Stakeholders see the features in context. Users see their actual job reflected in the design.
The Tension Points
Three specific tension points come up on almost every enterprise project.
The dashboard. Stakeholders want a dashboard with KPIs, charts, and high-level metrics. Users want a task list that tells them what to do next. Both are valid. The solution is usually a role-based home screen: executives see metrics, operators see tasks. The mistake is building one dashboard that tries to serve everyone and serves no one.
The feature count. Stakeholders evaluate software partly on capability breadth. More features equals more value, in procurement logic. Users evaluate software on whether it makes their specific job easier. More features often means more complexity, more menus to navigate, more options to get wrong. The solution is progressive disclosure: the full capability is there for those who need it, but the common tasks are fast and simple.
The reporting. Stakeholders need reports. Monthly summaries, compliance documentation, performance metrics. Users need the system to not interrupt their workflow with reporting requirements. The tension is real: every field a user has to fill in "for reporting purposes" is friction in their daily task. The solution is designing data capture into the natural workflow so reporting happens as a byproduct of use, not as an additional burden.
Why It Matters
Enterprise software that users don't use is a waste of money. It's that straightforward. You can have every feature in the requirements document. You can pass every compliance check. You can come in under budget. If the people who use it every day find workarounds instead, the project has failed.
The organisations that get this right involve users from the start, design for daily workflows rather than feature checklists, and measure success by adoption rather than deployment.
We've been on both sides. We've built systems that buyers loved and users tolerated. We've built systems that users loved and buyers had to be convinced about. The projects that work best are the ones where both audiences feel heard. That takes more effort in discovery and more skill in design. It's also the only way to build enterprise software that actually sticks.