Simplicity Is A Buyer's Feature, Not A User's

A screen built to win a demo and a screen built to survive a ten-hour shift are not the same design problem, and most enterprise products only ever solve the first one. Every enterprise demo has a moment where the whole room nods because a workflow that used to take four screens now takes one. The people nodding are frequently not the people who will run that workflow eight hours a day. Two separate bodies of research describe that mismatch from opposite sides of the same product, and tearing down one real screen shows exactly where it splits.

Gartner's 2025 survey of business-to-business (B2B) buyers found that buying groups now range from five to sixteen people across as many as four functions, and that deals with more consensus among that group are reported as higher quality. That is a specific finding about who signs off on enterprise software, not about who uses it afterward. The people in a demo room are frequently evaluators, budget owners, and department heads. Gartner's own research is explicit that this buying group is diverse and often in internal conflict, a different population from a single power user typing into the tool for a full shift.

Nielsen Norman Group's research on complex enterprise applications makes the matching point from the usage side. Their studies of expert users found that as people move from novice to power user, they want fewer confirmations, more shortcuts, and denser information on screen, the opposite direction from what a clean, sparse demo screen optimizes for. NN/g's finding is specifically that supporting only casual users, the ones a demo is built to impress, actively fails the people who will spend the most hours in the product.

A documented case shows how differently a buyer's assumption and a user's actual need can diverge. In the ThoughtSpot mobile work described on this site, the original product brief assumed a phone was simply a smaller version of the desktop analytics tool, effectively a porting exercise. Interviews with working analysts, along with public analyst communities, found a different reality: mobile analytics was useful for specific, situational tasks a scaled-down desktop screen did not serve well. That research replaced the porting brief with explicit mobile use cases. The case study states its own limit directly: the sample was small and self-selected, directional evidence for reframing a brief, not validation of every resulting design decision.

Where this reasoning breaks down

The strongest objection to that split: a product that never survives procurement never gets a chance to serve a daily user at all, so optimizing the front door first can be the rational call, not a mistake, especially while the sale itself is genuinely at risk. That is a legitimate ordering argument, and dismissing it as short-sighted ignores that you cannot retain users you never acquired. It does not survive contact with steady state, though. Once a contract is signed, continuing to treat the demo screen as sufficient has no equivalent justification, and that is exactly where the split above starts to bite. Not every enterprise product has a meaningfully different buyer and user population either. Small-business tools, single-seat purchases, and products where the buyer is also the daily user do not carry this split, and building two layers for one audience is waste, not rigor. The boundary: prioritize the buyer's screen while the sale is genuinely at risk, and confirm the split exists before designing for it. Stop treating that screen as sufficient the moment the population using the product daily is no longer the population that signed off on it.

What this looks like in practice

• Identify who is actually in the buying group for this deal, by role, separately from who will log in weekly once it is signed.
• Design a front-door flow for the evaluation and onboarding moments the buying group will see.
• Design a separate daily-use layer with denser information and fewer confirmations for the people who stay.
• Test the daily-use layer with people doing the job for a full session, not a ten-minute walkthrough.
• Revisit the split each renewal cycle. The buying group and the daily user population both change.

None of this argues for cramming every feature onto one screen to seem serious, and it does not argue for two entirely separate products either. Much of the underlying data, permissions, and core objects can stay shared. What changes between the two layers is density, confirmation frequency, and how much the interface assumes the person already knows, which is a narrower design problem than rebuilding the product twice. Laid side by side, the teardown looks like this.