The brief lands in your inbox. Two paragraphs. “Redesign the portal. Make it modern. Launch in Q3.”
You could start wireframing tomorrow. That is exactly the problem.
The brief tells you what someone wants built. It almost never tells you what problem they are trying to solve, how they will judge whether you solved it, or what they already decided the answer should be. Stakeholder interviews exist to close that gap before it gets expensive.
What stakeholder interviews actually are
They are structured, one-on-one conversations with the people who own the outcome of a project. The product owner, the marketing lead, the person whose budget pays for the work, the executive who will call it a success or a failure.
Not a survey. Not a kickoff where everyone nods at a slide deck. A real conversation, usually 30 to 60 minutes, built around three kinds of questions: what does success look like, what is getting in the way, and what do you already believe the answer is.
A typical interview moves through a dozen topics, and each one earns its place:
- Business context. Why does this project exist, and why now? The answer tells you what is actually at stake.
- Challenges and problems. What is broken or risky today? This is where the real requirements hide.
- Audiences. Who is this for, and who is it definitely not for? Vague audiences produce vague designs.
- Products and services. What are you actually offering, in plain language? If stakeholders cannot describe it simply, users will not understand it at all.
- Brand. How should this feel? Not colors and logos. Tone, trust, personality.
- Content. What has to be said, and who writes and owns it? Content is where most redesigns quietly die.
- Features. What does everyone assume will be included? This surfaces the pet features early, while you can still question them.
- Analytics and KPIs. How will you measure success? If nobody can name a number, the project has no finish line.
- Current state. What exists today, and what is wrong with it? You need the history to avoid repeating it.
- Future state. If this works perfectly, what changes? The answer becomes your design target.
- Publishing process. Who approves, who publishes, how often? A beautiful design that nobody can ship is a sketch, not a solution.
Notice what this list really is. A map of everything a two-paragraph brief leaves out.
Why you cannot skip them
Here is the misunderstanding most teams operate under: the ask is the requirement. It is not. The ask is a compressed, lossy version of what the business wants, filtered through one person’s understanding of what digital experiences can do.
Stakeholders are usually focused on outcomes, and rightly so. “Increase signups.” “Reduce support calls.” But outcomes are not designs. And when stakeholders do picture a solution, it is limited by what they have seen before. That is not a criticism. It is just how expertise works. Your job is to get underneath the pictured solution to the problem it was meant to solve.
Skip the interviews and you design from assumptions. Every assumption is a bet, and you will not know which bets lost until after launch, when fixing them costs ten times more. I have watched teams ship exactly what was asked for, on time, and still fail, because what was asked for was never quite the thing the business needed.
Interviews change the math. They surface the success metrics nobody wrote down. They reveal the constraints, like a legal review process or a CMS nobody mentioned, that would have killed your best ideas in week six. They let you distill the three things you cannot design without: a clear framing of the problem, a real set of requirements, and measures of success you can point to later and say, “This is what we agreed good looks like.”
Stakeholders tell you what the business needs. They do not tell you what users need. That is a different conversation, with different people. You need both. Stakeholder interviews keep you aligned with the business. User research keeps you honest about reality.
So the rule is simple. Before you design anything, find out what success looks like, in the stakeholders’ own words, and get them to agree on it in writing. Everything after that gets easier. The requirements write themselves, the debates get shorter, and the finish line stops moving.
Here is the question I would leave you with: could everyone on your team describe success for your current project in one sentence, without checking with each other? If not, you have your first interview scheduled.
And if you are kicking one of these off and want a second pair of eyes on your question list, reach out. I run stakeholder interviews at the start of every engagement, and I am happy to talk through yours.