Design presentation is a separate skill from design, and it matters enormously. The best design that isn't communicated effectively doesn't get implemented. Mediocre design that's presented with clarity and conviction gets built. This is unjust, but it's the reality. Learn to present.
The Narrative Arc
Design presentations should tell a story: here's the problem (make it feel real), here's what we found out about it (make it specific), here's what we tried (show your thinking), here's what we're recommending (make the recommendation clear), here's how we'll know if it works (show you think about outcomes).
Most design presentations start with the solution. This is wrong. Starting with the solution removes the context that makes the solution make sense. Start with the problem, and let the solution feel inevitable by the time you show it.
Speaking to Different Stakeholders
Executives care about business outcomes and strategic fit. Engineers care about feasibility and technical debt. PMs care about user outcomes and delivery schedule. The same design needs different framing for each audience. "This will reduce support tickets by an estimated 20%" lands differently with an executive than "this reduces the state complexity in the checkout flow."
Handling Criticism
When feedback is hostile, the worst response is to defend the design. The best response is to seek the underlying concern. "Tell me more about that" produces more useful information than "but we tested it with users." The underlying concern might be valid even if the specific criticism isn't.