There are two completely different users of every SaaS product, and they're often the same person at different moments.
The first is the prospect. They're seeing the product for the first time, or close to it. They're evaluating whether it's worth their attention and their money. They want to be impressed. They respond to polish, to a clear value proposition, to a sense that this product is sophisticated and capable. The design that wins this user is a design optimized for first impressions — striking, confident, immediately legible.
The second is the daily user. It's Tuesday at 2pm. They've used the product four hundred times. They're not evaluating it anymore — they're trying to get something done, the same something they did yesterday and will do again tomorrow. They don't want to be impressed. They want to complete a repetitive task with minimum friction so they can move on to the next thing. The design that serves this user is optimized for the four-hundredth use, not the first — efficient, predictable, invisible.
Most SaaS products are designed for the first user. The polish that wins demos, the visual sophistication that impresses prospects, the carefully choreographed onboarding that creates a strong first impression. And then the same design has to serve the second user, four hundred times, and the things that made it impressive in a demo become the things that make it tiring on a Tuesday.
The Demo Optimizes for Novelty, Tuesday Punishes It
The fundamental tension between the demo user and the Tuesday user is that they have opposite relationships with novelty.
The demo user is encountering everything for the first time. Novelty is engaging to them — a distinctive interaction, an unexpected animation, a visually rich interface all contribute to the impression that this product is special. The things that stand out are assets, because standing out is what captures the attention of someone who's deciding whether to care.
The Tuesday user has exhausted novelty. The distinctive interaction that delighted them on day one is now a series of extra steps they perform every time they do the task. The unexpected animation that impressed them in the demo is now a half-second delay between their action and its result, four hundred times over. The visually rich interface that signaled sophistication is now visual noise they have to look past to find the thing they need.
This is the core design problem that products optimized for demos consistently get wrong: the features that perform best in a first impression often perform worst in repeated use. An animation that makes a demo feel premium makes daily use feel slow. A visually elaborate dashboard that impresses a prospect overwhelms a daily user who just needs to check one number. An onboarding flow that creates a great first experience becomes an obstacle the second time a user has to set up a new project and is forced through the same guided steps they don't need anymore.
The product that's been designed to win demos has, in many cases, been designed against the interests of the people who will use it most.
Where the Incentive Comes From
The bias toward demo design isn't a mistake anyone makes deliberately. It's the predictable result of the incentives that shape how products get built and evaluated.
The demo is where money is decided. The prospect who's impressed becomes a customer. The investor who's impressed funds the next round. The stakeholder who's impressed approves the project. The demo is the moment where the product's design has the most visible, most immediate consequence — and so the design naturally optimizes for the moment where its impact is most visible.
The Tuesday experience, by contrast, has consequences that are real but diffuse and delayed. A product that's slightly tiring to use every day doesn't lose a deal in a demo — it loses a customer three months later to a slow accumulation of friction that nobody traces back to any specific design decision. The cost of bad Tuesday design is paid in churn, in reduced usage, in the gradual erosion of the customer relationship — none of which produces the kind of clear, attributable signal that demo performance produces.
This asymmetry in feedback creates an asymmetry in attention. Demo performance is measured constantly — every sales call is a referendum on whether the product impresses. Tuesday performance is measured rarely and indirectly — through retention metrics that have many contributing factors and through usage data that's hard to connect to specific design decisions. The thing that's measured gets optimized. The thing that isn't measured drifts.
The people who evaluate the design are also, usually, demo users rather than Tuesday users. Founders, stakeholders, and decision-makers see the product in presentations and reviews, not in the daily grind of repeated use. They experience the product the way a prospect does — freshly, with attention, evaluating. Their feedback reflects the demo experience because that's the experience they have. The Tuesday experience is had by users who aren't in the room when the design is evaluated.
What Tuesday Users Actually Need
The needs of the daily user are different from the needs of the prospect in ways that are specific and designable.
Speed over richness. The Tuesday user values getting the task done quickly above almost everything else. Every interaction that adds time to a frequently repeated task is a cost they pay repeatedly. The animation, the confirmation dialog, the multi-step flow that felt thorough in a demo are all friction in daily use. Tuesday design strips the path to the common task down to the minimum number of actions and the minimum amount of waiting.
Predictability over delight. The daily user wants the product to behave the same way every time. The element that moved, the layout that changed, the feature that was relocated in the latest update — these are not improvements to a Tuesday user, they're disruptions to a workflow that depended on things being where they were. Delight is a first-impression value. Predictability is a daily-use value, and the two are sometimes in direct conflict.
Density over simplicity, sometimes. The conventional wisdom that simpler is better is a demo-user truth. A simple interface is easier to understand on first encounter. But the daily user who's mastered the product often wants more information visible at once, more actions available without navigation, more density than a first-time user could handle. The interface that's appropriately simple for a prospect can be frustratingly sparse for a power user who'd rather see everything than click through to it.
Keyboard and efficiency paths. The daily user benefits enormously from efficiency features that a demo user never discovers — keyboard shortcuts, bulk actions, saved configurations, command interfaces. These features are invisible in a demo and transformative in daily use. A product designed for Tuesday invests in the efficiency layer that rewards mastery, even though that layer contributes nothing to the first impression.
Forgiveness and recovery. The daily user, working quickly and repeatedly, will make mistakes — the misclick, the wrong selection, the accidental deletion. A product designed for Tuesday makes these mistakes cheap to recover from, with robust undo, clear confirmation only where the stakes warrant it, and a general assumption that the user is moving fast and will occasionally err. A product designed for demos often assumes a careful, attentive user who doesn't make mistakes, because that's the user who shows up in a demo.
The Onboarding Trap
The clearest example of the demo-versus-Tuesday tension is onboarding, where the conflict between the two users is most direct.
A great onboarding experience is a demo asset. It creates a strong first impression, guides the new user to value, and reduces the friction of the initial encounter. Products invest heavily in onboarding because it's where first impressions are won and where activation metrics are improved.
But onboarding is, by definition, a first-use experience. And many products force the onboarding experience on users repeatedly — every time they create a new project, set up a new workspace, or start a new instance of whatever the product's core unit is. The guided flow that was helpful the first time becomes an obstacle every subsequent time. The user who's set up forty projects doesn't need the project-setup walkthrough on the forty-first. But many products provide it anyway, because the onboarding was designed for the first-time experience and never adapted for the repeated one.
A product designed with the Tuesday user in mind distinguishes between genuine first-use, where guidance is valuable, and repeated use of a feature that happens to have a setup flow, where guidance is friction. The onboarding adapts — full guidance for the genuinely new user, a fast path for the user who's done this before. This adaptation requires recognizing that onboarding is not a one-time event but a recurring pattern, and that the same flow serves opposite needs depending on whether the user is new to the product or just new to this particular instance of a familiar task.
Designing for Both Without Sacrificing Either
The goal is not to abandon demo design in favor of Tuesday design. The demo matters — products that don't win first impressions don't get the chance to serve daily users at all. The goal is to design for both, recognizing where their needs align and where they conflict, and resolving the conflicts deliberately rather than defaulting to the demo user because they're the one in the room.
Where the needs align, there's no conflict to resolve. A clear visual hierarchy serves both the prospect trying to understand the product and the daily user trying to find what they need. Good information architecture helps both. Thoughtful defaults help both. Much of good design serves both users equally, and that's the foundation.
Where the needs conflict, the resolution is usually progressive disclosure and adaptive interfaces — designing so that the demo-friendly experience is available to those who need it while the Tuesday-friendly experience is available to those who've graduated to it. The new user gets the guided, simplified, impressive experience. The daily user gets the fast, dense, efficient one. The product adapts to the user's demonstrated familiarity rather than serving the same experience to both.
This requires designing the daily experience as an explicit design object, with the same attention given to the demo experience. It requires recruiting daily users — not prospects — into the design process, watching how the product is actually used in repeated, unglamorous practice rather than how it's experienced in a first encounter. It requires measuring Tuesday performance with the same rigor as demo performance — not just activation and first-impression metrics but the efficiency, satisfaction, and friction of repeated use.
And it requires a cultural willingness to resist the gravitational pull of the demo. The demo is seductive because its feedback is immediate and its stakes are visible. The Tuesday experience is easy to neglect because its feedback is delayed and diffuse. Designing for both means deliberately allocating attention to the user who isn't in the room, whose experience doesn't show up in the next sales call, but who will use the product four hundred times and whose accumulated experience of those four hundred uses is what actually determines whether they stay.
The Tuesday Test
A useful discipline for any product team is to periodically evaluate a design decision against the Tuesday test: not "how does this look in a demo?" but "how does this feel the four-hundredth time?"
The animation that adds personality — how does it feel when you've seen it four hundred times? The confirmation dialog that prevents errors — how does it feel when you've confirmed the same safe action four hundred times? The visually rich dashboard — how does it feel when you've parsed it four hundred times to find the one number you check daily? The onboarding flow — how does it feel the fifth time you're forced through it?
The answers to these questions are frequently different from the answers to the demo questions, and the difference is where the most important product design decisions live. The product that feels great in a demo and tiring on a Tuesday loses the users it worked hardest to win. The product that feels good in a demo and better on a Tuesday keeps them — and keeping them is, ultimately, the only metric that matters.