How to Win RFPs Without Selling Your UX Soul

RFPs are sales artifacts, not product briefs. Here’s a practical way to respond that protects design craft, helps sales win, and reduces downstream rework.

If you’ve worked at a small or mid-size design firm, the RFP treadmill will feel familiar: rushed timelines, endless requirement lists, and an expectation to design an entire website before anyone agrees on the problem.



My perspective on this comes from an unusual career path. I started in retail, where storytelling, perception, and confidence drive decisions. Later, I moved into UX and product design, where progress depends on research, validation, and embracing uncertainty.


RFPs force these two worlds to collide. They reward certainty over learning and visuals over validation. The result? Projects that look great on paper but drift the moment real constraints surface, leaving teams exhausted and designers questioning the value of their work. This article is an attempt to bridge those two worlds without burning teams or compromising design integrity.

Quick reality check

Design doesn’t exist to make pretty screens; it exists to reduce the risk of building the wrong thing. That’s why investing in design capability matters. According to McKinsey & Company’s The Business Value of Design study, companies in the top quartile of the McKinsey Design Index saw 32 % higher revenue growth and 56 % higher total returns to shareholders over five years compared with industry peers and this was consistent across multiple industries. 

On the digital maturity side, Boston Consulting Group’s Digital Acceleration Index found that the most digitally mature companies saw valuations ~23 % above pre-crisis levels within six months of the pandemic’s start and outperformed peers across key performance metrics including revenue growth and enterprise value. 



In other words, firms that integrate design and early validation into strategy rather than just shipping screens tend to see measurable financial advantages and resilience in uncertain markets.

(Translation: good discovery + realistic RFPs = less waste + higher returns.)

Why RFPs often demand full designs

1. 1. Visuals are the easiest way to compare vendors
   RFPs are often driven by procurement or IT teams who need clear, comparable evaluation criteria. Screens are tangible and easy to judge side by side, so polished designs become a stand-in for capability even when the problem itself is still evolving.
2. 2. Design maturity varies across organizations
   In many companies, design has traditionally been seen as an execution step rather than a discovery process. Without a shared language for uncertainty and validation, it’s natural to ask for finished-looking outputs early instead of open-ended exploration.
3. 3. Pressure to show progress and win quickly
   RFPs are frequently used to align internal stakeholders, and sales teams operate under tight timelines. In both cases, visuals become the fastest way to signal momentum and value, even if they’re meant to be directional rather than final.

Why this breaks down

Together, these forces push teams to show certainty before learning rewarding completeness over correctness and setting projects up for rework once real constraints emerge.

Principles: Responding to RFPs without killing UX integrity

1. 1. You’re selling confidence, not final pixels.
   Clients are buying the belief that you won’t embarrass them internally and will deliver results.
2. 2. Use their language.
   Replace UX jargon with business outcomes: “reduce rework,” “validate assumptions,” “shorten time to revenue.”
3. 3. Show just enough design—signal thinking, don’t promise delivery.
   One core scenario, mid-fidelity wireframes, and annotated intent beats ten high-fidelity screens.
4. 4. Make assumptions and validation explicit.
   List the assumptions you’re making and exactly what you’ll validate during discovery.

Protect your team’s morale

Propose a short internal policy (email or one-pager) your head of design or delivery can adopt. This pact changes incentives and reduces the narrative “design is slow/inefficient.”

• RFP effort capped at X hours per designer.
• Design deliverables labelled “conceptual.”
• No re-use of RFP deliverables as production artifacts without paid rework.
• Sales must include a standard “discovery” line-item in proposals; if client declines, the team will supply a scoped concept with explicit risk disclosures.
• Leadership will not evaluate designers on win rate.

“Show one scenario well.
Don’t show ten pages you’ll later abandon.”

Closing: a practical, not preachy, ask to clients

IRFPs sit at the intersection of two very real needs: the need to sell confidence and the need to discover the right solution. When we treat them purely as sales documents, design becomes performative. When we treat them purely as product briefs, we ignore the realities of how buying decisions are made.

The work, then, isn’t to eliminate RFPs or resist visuals but to use them more honestly. To show thinking without pretending certainty, to signal capability without overpromising, and to protect teams from doing work that was never meant to be final. When RFPs are handled this way, they stop being a drain on design integrity and start becoming what they should have been all along: the beginning of a better conversation.