# Business needs during ideation

> Learn how to balance user needs with business goals when generating ideas, using the desirability, feasibility, and viability lens.

Source: https://uxspot.io/business-needs-ideation

<section id="why-business-needs">
<h2>Why business needs matter</h2>
<p class="blockquote">Ideation doesn't happen in a vacuum. Every idea you generate has to serve two masters at once: the user who will use it and the business that will build it.</p>
<p>It's tempting to treat ideation as pure creative freedom, where the only question is "what would users love?" But a product idea that ignores the business behind it is a sketch, not a solution. <strong class="highlight">The best ideas live at the intersection of what users need and what the business needs, and your job during ideation is to search for that overlap.</strong></p>
<p>Think of a food delivery app. Users may want free delivery on every order. That idea would score perfectly in a user survey and still sink the company. A better idea, like a subscription that bundles delivery with perks, serves the same user desire while keeping the business alive to serve it.</p>
<p>This doesn't mean the business always wins. It means you ideate with both sets of needs on the table, so the ideas that survive are ones that can actually ship, scale, and last.</p>
<ul>
<span>keywords</span>
<li>#BusinessGoals</li>
<li>#UserNeeds</li>
<li>#Ideation</li>
</ul>
</section>
<section id="triad">
<h2>Desirability, feasibility, viability</h2>
<img src="/images/desirability-feasibility-viability.webp" width="2400" height="1330" alt="Three overlapping circles for desirability, feasibility and viability, with the sweet spot highlighted at their intersection" title="Desirability, feasibility, viability">
<p>A simple lens for judging ideas <a href="/design-ideation" class="redirect">during ideation</a> is the triad of desirability, feasibility, and viability. <strong class="highlight">An idea is only worth pursuing when people want it, the team can build it, and the business can sustain it.</strong> Miss any one of the three and the idea will fail, just in different ways.</p>
<div id="desirability">
<h3>Desirability</h3>
<p>Desirability asks: do users actually want this? This is the question your <a href="/design-research" class="redirect">research phase</a> answers. An idea is desirable when it solves a real problem you observed, not one you assumed. A booking flow that saves travelers three steps at checkout is desirable because it removes friction users complained about.</p>
<p>Desirability is where UX designers are strongest, but be honest with yourself. If an idea only excites the team and not the users, it's not desirable, no matter how clever it is.</p>
</div>
<div id="feasibility">
<h3>Feasibility</h3>
<p>Feasibility asks: can we build this? That covers technology, time, and team skills. A real-time translation feature might be highly desirable, but if your team has no machine learning capability and a three-month deadline, it isn't feasible right now.</p>
<p>You don't need to be an engineer to think about feasibility. <strong class="highlight">A quick conversation with a developer during ideation can save weeks of designing something that will never be built.</strong></p>
</div>
<div id="viability">
<h3>Viability</h3>
<p>Viability asks: does this make sense for the business over time? An idea is viable when it supports how the company earns money, grows, or reduces costs. It's the question designers most often skip, and the one stakeholders care about most.</p>
<p>Viability isn't only about revenue. An internal tool that cuts support tickets in half is viable because it lowers costs, even though it never earns a cent directly.</p>
</div>
<ul>
<span>keywords</span>
<li>#Desirability</li>
<li>#Feasibility</li>
<li>#Viability</li>
</ul>
</section>
<section id="constraints">
<h2>Constraints as creative fuel</h2>
<p class="blockquote">Constraints are not the enemy of creativity. They are the raw material of it.</p>
<p>Designers often experience business constraints, like a limited budget, a legacy system, or a legal requirement, as walls closing in on their ideas. But a blank canvas with no limits usually produces vague, generic ideas. <strong class="highlight">A well-defined constraint forces your brain to search in places it would never look otherwise.</strong></p>
<p>Consider an e-commerce team told they cannot add a single new screen to the checkout flow. That constraint rules out the obvious ideas and pushes the team toward smarter ones: inline validation, smarter defaults, saved payment methods. The constraint didn't kill creativity; it aimed it.</p>
<p>So when a stakeholder hands you a limitation, resist the urge to fight it immediately. Reframe it as a design prompt: "How might we improve conversion without adding a screen?" is a far more productive question than "Why can't we add a screen?"</p>
<ul>
<span>keywords</span>
<li>#Constraints</li>
<li>#CreativeFuel</li>
<li>#Reframing</li>
</ul>
</section>
<section id="stakeholders">
<h2>Involve stakeholders early</h2>
<p>Stakeholders are the people with a stake in the outcome: product managers, engineers, marketing, support, legal, leadership. Designers sometimes keep them out of ideation, fearing they will shoot ideas down. The opposite is true. <strong class="highlight">Ideas that stakeholders help create are ideas stakeholders will fight for later.</strong></p>
<p>Involving them early gives you three things. First, knowledge: a support lead knows which complaints flood the inbox, and an engineer knows which parts of the system are fragile. Second, realistic boundaries: you learn the actual budget and timeline instead of guessing. Third, buy-in: nobody rejects an idea they helped shape.</p>
<p>Waiting until the end to "present" polished ideas is the riskier path. That's when you discover the legal issue, the technical blocker, or the strategic conflict you could have known about on day one.</p>
<ul>
<span>keywords</span>
<li>#Stakeholders</li>
<li>#BuyIn</li>
<li>#Collaboration</li>
</ul>
</section>
<section id="red-flags">
<h2>Red flags to watch for</h2>
<p>Two failure patterns show up again and again when user needs and business needs fall out of balance. Learn to spot both.</p>
<p><strong>Users love it, the business can't sustain it.</strong> These ideas test brilliantly and die slowly. Unlimited free storage, human support on every chat, free returns on everything. Users adore them right up until the company removes them, and removing a loved feature damages trust far more than never offering it.</p>
<p><strong>The business loves it, users don't want it.</strong> These ideas look great in a revenue forecast: forced account creation before checkout, aggressive upsell pop-ups, features built to hit an internal metric rather than solve a user problem. They may lift a number this quarter while quietly eroding the experience that made people show up at all.</p>
<p>None of this means you stop being the user's advocate. It's the opposite: <strong class="highlight">you are most useful as a user advocate when you can argue for the user in the language of the business.</strong> "Users find this annoying" is an opinion. "This pattern <a href="/measure-ux" class="redirect">drives churn</a>, and churn costs us more than the upsell earns" is an argument that wins the room. Respecting business needs doesn't dilute your advocacy; it makes it effective.</p>
<ul>
<span>keywords</span>
<li>#RedFlags</li>
<li>#UserAdvocate</li>
<li>#Sustainability</li>
</ul>
</section>
<section id="takeaways">
<h2>Takeaways</h2>
<p class="blockquote">Great ideas serve the user and the business at the same time. One without the other never ships, or never lasts.</p>
<p>Bring business needs into ideation from the start. Test every idea against desirability, feasibility, and viability. Treat constraints as prompts rather than obstacles, invite stakeholders in early, and keep advocating for users in terms the business understands.</p>
</section>