An interview flow that turns one project into a case study. Pick your starting point, then work through ten short steps in one chat. Each step has a prompt you can copy or open straight in your assistant.
Opens your own ChatGPT or Claude with the prompt filled in. You may need to be signed in.
1
Step 1 of 10
Step 1: Gather what you haveLet it interview you
Share what exists so it works from facts, not memory.
Prompt
I'm turning one of my own projects into a portfolio case study. Rules for this whole chat: ask before assuming, never invent numbers, names or results. Use placeholders like [METRIC?], and keep my wording plain.
Here's what I have for the project [PROJECT NAME]: [LINKS / FILES / SCREENSHOTS: brief, Figma, PRD, decks, launch post, metrics dashboard].
Read them and give me back:
1. A one-paragraph summary of the project in plain words.
2. A list of facts you found (dates, team, my role, outcomes) with where each came from.
3. Gaps and conflicts you need me to answer.
Don't write the case study yet.
No files? Let it interview you, one question at a time.
Prompt
I'm turning one of my own projects into a portfolio case study. Rules for this whole chat: ask before assuming, never invent numbers, names or results. Use placeholders like [METRIC?], and keep my wording plain.
I don't have materials for [PROJECT NAME], so interview me from memory. Ask one question at a time: what it was, when, who was on the team, my role, what shipped, and what happened after. Wait for each answer. When we're done, list the facts you collected and mark anything I was unsure about as [CHECK]. Don't write the case study yet.
No screenshots or numbers yet? Say so. Don’t let it invent visuals or results; use placeholders.
2
Step 2 of 10
Step 2: Context and role
Readers need to know what this was and what you actually did.
Prompt
Using what we have so far, draft a short context section: the product, the company or team, the timeframe, and my role. Separate what I owned from what I contributed to. Ask me if the split is unclear. Keep it under 80 words.
3
Step 3 of 10
Step 3: Problem
The case study only works if the problem is clear and real.
Prompt
Help me state the problem. Ask me who had it, how we knew (research, data, support tickets, a hunch), and what happened if we didn't fix it. Then give me 3 one-sentence problem statements to choose from. Don't invent evidence; mark missing proof as [EVIDENCE?].
4
Step 4 of 10
Step 4: Constraints
Constraints explain why the solution looks the way it does.
Prompt
Ask me about the constraints: time, team size, tech, legal, brand, existing users, dependencies. Then list them as short bullets and note which ones shaped the final design most.
5
Step 5 of 10
Step 5: Key decisions and why
This is the core: the choices you made and the reasoning.
Prompt
Interview me about the 3–5 most important design decisions. For each one ask: what were the options, what did we pick, why, and what did we give up. Then write each decision as: Decision / Options / Why / Trade-off. Keep my reasoning; don't add reasons I didn't give.
6
Step 6 of 10
Step 6: Proof and metrics
Numbers persuade, but invented numbers end careers. Placeholders are fine.
Prompt
List every claim of impact in our draft so far. For each, ask me for the real number and its source. If I don't have one, replace it with a placeholder like [METRIC? e.g. activation %] or a qualitative signal I can back up (quotes, adoption, a shipped date). Never invent or estimate numbers for me.
7
Step 7 of 10
Step 7: Visuals checklist
Plan the images before you hunt for them.
Prompt
Based on the story so far, give me a visuals checklist: for each section, the one image that would prove the point best (before/after, flow, key screen, detail, system diagram). Mark which I said I already have and which I need to make or blur for confidentiality. No stock images or mockups pretending to be real work.
8
Step 8 of 10
Step 8: Outcome and learning
End with what happened and what you would do differently.
Prompt
Ask me what happened after launch and what I learned. Then draft a short outcome section (facts only, placeholders where needed) and 2–3 honest learnings, including one thing I'd do differently.
9
Step 9 of 10
Step 9: Assemble the page draft
Now stitch it into one page you can paste into your site.
Prompt
Assemble everything into a case study draft with these sections: Title, One-line summary, Context and role, Problem, Constraints, Key decisions, Proof, Outcome and learning. Add [IMAGE: …] markers where the visuals go. Keep it scannable: short paragraphs, under 600 words. Keep every placeholder visible.
10
Step 10 of 10
Step 10: Fact-check pass
Fluent copy hides mistakes. Check every claim before publishing.
Prompt
Fact-check the draft against what I told you and the materials I shared. Give me a table: section | exact sentence | issue (not from me, overstated role, invented number, unclear) | suggested fix. Then list every placeholder still open. Don't change the draft until I approve.
No steps match “”.
Copies the prompt with a link to this page. Paste it into your chat with Grok Bot.
1
Step 1 of 10
Step 1: Gather what you haveLet it interview you
Share what exists so it works from facts, not memory.
Prompt
I'm turning one of my own projects into a portfolio case study. Rules for this whole chat: ask before assuming, never invent numbers, names or results. Use placeholders like [METRIC?], and keep my wording plain.
Here's what I have for the project [PROJECT NAME]: [LINKS / FILES / SCREENSHOTS: brief, Figma, PRD, decks, launch post, metrics dashboard].
Read them and give me back:
1. A one-paragraph summary of the project in plain words.
2. A list of facts you found (dates, team, my role, outcomes) with where each came from.
3. Gaps and conflicts you need me to answer.
Don't write the case study yet.
No files? Let it interview you, one question at a time.
Prompt
I'm turning one of my own projects into a portfolio case study. Rules for this whole chat: ask before assuming, never invent numbers, names or results. Use placeholders like [METRIC?], and keep my wording plain.
I don't have materials for [PROJECT NAME], so interview me from memory. Ask one question at a time: what it was, when, who was on the team, my role, what shipped, and what happened after. Wait for each answer. When we're done, list the facts you collected and mark anything I was unsure about as [CHECK]. Don't write the case study yet.
No screenshots or numbers yet? Say so. Don’t let it invent visuals or results; use placeholders.
2
Step 2 of 10
Step 2: Context and role
Readers need to know what this was and what you actually did.
Prompt
Using what we have so far, draft a short context section: the product, the company or team, the timeframe, and my role. Separate what I owned from what I contributed to. Ask me if the split is unclear. Keep it under 80 words.
3
Step 3 of 10
Step 3: Problem
The case study only works if the problem is clear and real.
Prompt
Help me state the problem. Ask me who had it, how we knew (research, data, support tickets, a hunch), and what happened if we didn't fix it. Then give me 3 one-sentence problem statements to choose from. Don't invent evidence; mark missing proof as [EVIDENCE?].
4
Step 4 of 10
Step 4: Constraints
Constraints explain why the solution looks the way it does.
Prompt
Ask me about the constraints: time, team size, tech, legal, brand, existing users, dependencies. Then list them as short bullets and note which ones shaped the final design most.
5
Step 5 of 10
Step 5: Key decisions and why
This is the core: the choices you made and the reasoning.
Prompt
Interview me about the 3–5 most important design decisions. For each one ask: what were the options, what did we pick, why, and what did we give up. Then write each decision as: Decision / Options / Why / Trade-off. Keep my reasoning; don't add reasons I didn't give.
6
Step 6 of 10
Step 6: Proof and metrics
Numbers persuade, but invented numbers end careers. Placeholders are fine.
Prompt
List every claim of impact in our draft so far. For each, ask me for the real number and its source. If I don't have one, replace it with a placeholder like [METRIC? e.g. activation %] or a qualitative signal I can back up (quotes, adoption, a shipped date). Never invent or estimate numbers for me.
7
Step 7 of 10
Step 7: Visuals checklist
Plan the images before you hunt for them.
Prompt
Based on the story so far, give me a visuals checklist: for each section, the one image that would prove the point best (before/after, flow, key screen, detail, system diagram). Mark which I said I already have and which I need to make or blur for confidentiality. No stock images or mockups pretending to be real work.
8
Step 8 of 10
Step 8: Outcome and learning
End with what happened and what you would do differently.
Prompt
Ask me what happened after launch and what I learned. Then draft a short outcome section (facts only, placeholders where needed) and 2–3 honest learnings, including one thing I'd do differently.
9
Step 9 of 10
Step 9: Assemble the page draft
Now stitch it into one page you can paste into your site.
Prompt
Assemble everything into a case study draft with these sections: Title, One-line summary, Context and role, Problem, Constraints, Key decisions, Proof, Outcome and learning. Add [IMAGE: …] markers where the visuals go. Keep it scannable: short paragraphs, under 600 words. Keep every placeholder visible.
10
Step 10 of 10
Step 10: Fact-check pass
Fluent copy hides mistakes. Check every claim before publishing.
Prompt
Fact-check the draft against what I told you and the materials I shared. Give me a table: section | exact sentence | issue (not from me, overstated role, invented number, unclear) | suggested fix. Then list every placeholder still open. Don't change the draft until I approve.
No steps match “”.
Before you publish
Every number has a source, or is still a visible placeholder.
Your role is stated as it was: owned vs contributed.
Confidential screens are blurred or replaced with your own diagrams.
Send a connection request with a short note about what you’re working on.
