The Road Not Taken

A design recommendation and the reason it gets rejected are often answering two different questions. The recommendation is built around what's right for the user or the product. The rejection is usually about something the pitch never addressed: a budget it doesn't fit, a preference already set before the conversation started, a deadline it doesn't protect, or a decision the stakeholder won't be able to defend later if someone above them asks about it.

The research that grounds the recommendation is also where that gap gets closed, before the pitch is ever built: the budget mentioned in passing, the deadline called fixed, the preference someone lets slip. Building the answer to each into the recommendation itself, before it's presented, is part of what discovery is for.

Even then, rejection happens. The trap is taking the path of least resistance: accepting it and quietly building whatever was asked for, the safest literal reading of the original brief, the version that needs no further research and invites no further debate.

The more difficult (but better) response is walking through the alternatives that exist, with pros and cons weighed against the project goals and the actual timeline. It doesn't require redoing the discovery work, only linking back to what's already known. Done this way, there's no room for a half-built answer to pass unnoticed. The client sees exactly what's being delivered, when, and how it differs in function and expected results from the recommendation.