How do I turn a vague idea into a clear brief?

A vague idea is not a flaw, it is just an early stage, and every idea starts there. The work is to move it from a feeling you carry around to words another person could read and act on. There is a reliable way to do this: answer a fixed set of questions, and let the act of writing pull the fog into shape.

Step by step

1. Answer who it is for, in real detailWrite down the specific person this is for, not a vague market. Their situation, what they do now, why it frustrates them. Vagueness about the user is the root of most other vagueness, because if you do not know exactly who you are helping, every later question stays fuzzy. Being specific here, even to the point of picturing one real person, sharpens everything that follows.
2. State the problem as they would describe itWrite the problem in the user's own words, the way they would complain about it, not in your solution's language. "I waste an hour every week chasing invoices" is a problem; "they need an automated invoicing dashboard" is a solution in disguise. Keeping the problem in plain, human terms stops you locking into one solution too early and keeps the brief honest about what actually needs solving.
3. Walk through what a user does, step by stepDescribe the journey from the user arriving to getting what they came for, as a short sequence of plain steps. Do not mention screens or technology, just the human actions. This is where vague ideas most often reveal their gaps, because you reach a step and realise you never decided what happens there. Each gap you hit is a decision the idea was quietly hiding from you.
4. Separate the must-haves from the restList everything the idea might include, then sort each item into must-have for the first version or later. Force the split honestly, and resist the temptation to call everything a must-have. A must-have is something without which the core journey simply does not work; everything else is later, however much you want it. This is where a sprawling idea becomes a scoped one, and it is the single most clarifying thing you can do to a vague brief. When you finish, you should have a short must-have list and a longer later list, and the shortness of the first list is a good sign, not a worry, because it means the first build is small enough to actually happen.
5. Write down the open questions instead of hiding themWhen you hit something you have not decided, do not skip it, write it down as an open question. What happens if a user does the wrong thing, where does the data live, who handles support, what happens when two people want the same thing at once. These gaps are not failures of the brief; they are the brief doing its job by surfacing what you still need to think about. A clear brief names its uncertainties rather than papering over them, because an unspoken assumption becomes an expensive surprise once building has started and changing course costs real money.