AI Skill Report Card
Generating Design Challenge Prompts
Quick Start14 / 15
Generate a design challenge by combining three elements: category, brief (the task), and client (the context/constraint).
Category: Products & UX
Brief: Design a mixed-reality tool for a genetics lab
Client: [optional โ e.g., "a nonprofit research consortium" or leave locked/open]
Self-critique prompt: When done, write a short critique of your own solution โ what works, what's weak, what you'd explore next.
Output format:
๐ฏ CHALLENGE: [Brief] + [Client/context]
๐ Category: [category]
๐ Constraints (optional lock): [brief locked / client locked / both open]
โ
Self-critique: [2-3 reflection questions tailored to the brief]
Recommendationโพ
Add an explicit 'bad example' showing a poorly constructed challenge (e.g., both brief and client overly narrow) to contrast with best practices
Workflow14 / 15
- Pick or receive a category. Default categories: Branding, Marketing, Products & UX, Digital Products, Physical Products, Experimental, or "All" (random/unpredictable).
- Generate a brief โ an open-ended action statement. Use verbs like Design, Create, Reimagine, Craft, Build. Keep it abstract enough to allow creative interpretation but specific enough to be actionable (name a medium, tool, or format).
- Generate a client/context โ an organization, industry, or situation that grounds the brief in a realistic constraint (e.g., "a genetics lab," "a remote-first nonprofit," "a 100-year-old bakery").
- Apply lock options if requested. A user may want to lock the brief (keep it, reroll only the client) or lock the client (keep it, reroll only the brief) โ mirrors "Lock Brief" / "Lock Client" functionality.
- Add a self-critique or reflection step. Every challenge should end with a prompt encouraging the designer to evaluate their own output against the brief's intent, usability, and creativity.
- Scale as needed:
- For hiring: add evaluation criteria (clarity of thinking, craft, communication, constraint handling) and optional time-box (e.g., 60โ90 minutes).
- For practice/portfolio reps: keep it loose, encourage multiple rapid iterations.
- For classrooms: align to a learning objective (e.g., NGSS standard) and add instructor/student guide notes.
Progress:
- Category selected
- Brief generated (or locked)
- Client generated (or locked)
- Self-critique questions attached
- Context-specific additions applied (hiring rubric / time-box / learning objective)
Recommendationโพ
Include a full list of default categories with brief descriptions, rather than just naming them once in the workflow
Examples17 / 20
Example 1 (general practice): Input: Category = Products & UX, no locks Output:
๐ฏ CHALLENGE: Design a mixed-reality tool for a genetics lab
๐ Category: Products & UX
โ
Self-critique:
1. Does this solve a real workflow problem for a geneticist, or just look futuristic?
2. What's the weakest assumption in your design โ what would you test first with a real user?
3. If you had 3 more days, what would you change?
Example 2 (hiring use case, locked client): Input: Category = Branding, Client locked = "a 100-year-old family bakery going digital" Output:
๐ฏ CHALLENGE: Rebrand the identity of a 100-year-old family bakery going digital
๐ Category: Branding
โฑ Time-box: 90 minutes
๐ Evaluation criteria: problem framing, concept clarity, visual craft, rationale communication
โ
Self-critique:
1. What tension did you resolve between "heritage" and "digital-first"?
2. Where did you make a tradeoff, and why?
Example 3 (classroom/NGSS-aligned): Input: Category = Experimental, audience = high school STEM Output:
๐ฏ CHALLENGE: Build a physical prototype that visualizes invisible air quality data for your classroom
๐ Category: Experimental
๐ Learning objective: Engineering design process, data visualization, systems thinking
โ
Self-critique: What data did you choose to show, and what did you leave out? Why?
Recommendationโพ
Provide a concrete rubric template (scoring scale) for hiring use cases instead of just naming evaluation dimensions
Best Practices
- Keep briefs verb-first and open-ended โ avoid over-specifying the solution; the constraint should come from the client/context, not the brief itself.
- Pair an abstract brief with a concrete client (or vice versa) โ never make both abstract or both hyper-specific; the contrast is what creates generative tension.
- Always include a self-critique step โ the reflection is as important as the generation.
- For hiring contexts, be explicit about what's being evaluated (not just "good design" โ name the dimensions: framing, craft, systems thinking, communication).
- Default to unpredictability unless the user asks to lock a variable โ randomness is a feature, not a bug.
Common Pitfalls
- Don't generate briefs that already imply the solution (e.g., "Design a logo" is weaker than "Craft the personality of an organization").
- Don't pair two highly constrained elements (brief + client both narrow) โ it kills creative latitude.
- Don't skip the self-critique โ a challenge without reflection is just a task, not a growth exercise.
- Don't make hiring challenges open-ended without a rubric โ candidates need to know what "good" looks like even in ambiguity.