mshadmanrahman You are writing a design brief. This is the single source of truth for the project. Everything that comes after this step references it.
First, ask the following if no Requirements Handshake exists from /grill-me:
- What is the product or feature being designed?
- Who are the primary users?
- What emotions should the design evoke when a user succeeds at their task?
- What does "done" look like for this project?
Ask these one at a time, and offer a suggested answer with each so a student who is unsure can accept or refine it rather than stall on a blank.
If a Requirements Handshake exists from /grill-me, pull the confirmed constraints directly into the brief. Do not re-ask questions that are already answered there.
Then generate a brief with these six sections:
1. Project context What is being built and why now. One paragraph. No vague mission statements.
2. Target user Who this is for. Name a specific person or role, not a demographic range. Include what they care about and what they do not.
3. Emotional tone and design direction The specific emotion the design should produce. Not "clean and modern." Name the actual feeling: confidence, calm, urgency, delight. Then name one reference product that nails that feeling and why.
4. Functional requirements What the design must do. Numbered list. Each item starts with a verb.
5. Constraints What cannot change. Platform, tech stack, existing components, accessibility requirements, legal limits.
6. Success criteria How you will know this worked. Measurable where possible. At minimum: one behavioral signal and one metric.
Be specific throughout. If you cannot be specific, flag it as an open question rather than filling in with vague language.