Study Guide: Alex for Designers
Your reference for using Alex in UX/UI, product design, and design operations. Ready-to-run prompts for research synthesis, documentation, critique, and collaboration.
What This Guide Is Not
This is not a habit formation guide (see Self-Study Guide for that). This is a design toolkit — the specific ways Alex can accelerate your design process, and the prompts that work.
Core Principle for Designers
Design is about solving problems for humans through intentional decisions. Alex can’t design for you — it doesn’t see what you see, and it can’t feel what users feel. But it can accelerate the parts of design that aren’t visual: research synthesis, documentation, critique preparation, and stakeholder communication.
The key pattern: describe what you’re seeing. Alex can’t see your mockups, so you need to articulate your design decisions in words. This constraint actually helps — articulating forces clarity.
The Seven Use Cases
1. Research Synthesis
When to use: After user research. Turning interviews, tests, and observations into insights.
Prompt pattern:
Help me synthesize this research:
Research type: [interviews / usability tests / surveys / observation]
Participants: [who, how many, what segment]
Research questions: [what we were trying to learn]
Raw findings:
[paste key observations, quotes, or notes]
Help me:
1. Identify the top themes across participants
2. Distinguish behaviors from stated preferences
3. Surface pain points and unmet needs
4. Find patterns I might be missing
5. Prioritize by severity and frequency
Follow-up prompts:
What questions should I have asked but didn't?
Create user need statements based on this research.
What assumptions should we validate before designing?
2. Design Documentation
When to use: Specs, annotations, handoff docs, design system documentation.
Prompt pattern:
Help me document this design:
What it is: [screen, flow, component, system]
Description: [describe what you've designed]
Design decisions: [key choices you made and why]
Audience: [who needs to understand this — engineers, stakeholders]
Level of detail: [high-level / detailed spec]
Create documentation that:
1. Explains what this does and why
2. Describes behavior and states
3. Calls out edge cases
4. Specifies accessibility requirements
5. Notes what's not covered / out of scope
Follow-up prompts:
Add interaction specifications for [specific element].
Write the acceptance criteria an engineer would need.
Document the responsive behavior.
3. Design Critique Preparation
When to use: Preparing to present work for feedback. Structuring a critique.
Prompt pattern:
Help me prepare for a design critique:
What I'm presenting: [describe the design]
Design goals: [what this should accomplish]
Key decisions: [choices I made]
What I'm confident about: [the parts that feel right]
What I'm uncertain about: [where I want feedback]
Audience: [who's in the critique]
Help me:
1. Frame the design problem clearly
2. Structure my presentation
3. Articulate my decisions and rationale
4. Formulate specific questions for feedback
5. Anticipate pushback and prepare responses
Follow-up prompts:
Someone will say "Why didn't you do [alternative]?" Prepare my response.
What blind spots might I have?
How do I respond if the feedback contradicts the user research?
4. UX Writing and Content
When to use: Interface copy, error messages, empty states, onboarding.
Prompt pattern:
Help me write UX copy:
Context: [where this appears in the product]
User situation: [what's the user doing/feeling]
Goal: [what this copy needs to accomplish]
Constraints: [character limits, tone guidelines, platform]
Current copy: [what exists now, if anything]
Write variations that:
1. Are clear and scannable
2. Guide the user to action
3. Match our voice: [describe brand voice]
4. Handle edge cases gracefully
5. Are accessible to diverse users
Follow-up prompts:
Write 5 variations of the primary button text.
Write error messages for [specific failure modes].
Create the empty state copy for [feature].
5. Stakeholder Communication
When to use: Presenting to non-designers. Explaining decisions to PMs, engineers, executives.
Prompt pattern:
Help me explain this design decision:
Decision: [what you chose]
Why: [your reasoning]
Audience: [who you're explaining to]
Their concerns: [what they care about]
Data: [any research or evidence]
Create an explanation that:
1. Leads with user/business impact, not design rationale
2. Uses concrete examples, not abstract principles
3. Acknowledges tradeoffs honestly
4. Connects to their priorities
5. Invites collaboration, not approval
Follow-up prompts:
An engineer says this is too complex. How do I respond?
A stakeholder wants [feature] added. Help me explain why not.
How do I present this to someone who "knows what they like when they see it"?
6. Design System Work
When to use: Component documentation, pattern libraries, governance, adoption.
Prompt pattern:
Help me document this design system component:
Component: [name and purpose]
Variants: [different versions/states]
Usage: [when to use it]
Anatomy: [its parts]
Behavior: [interactions, states]
Create documentation that includes:
1. When to use (and when not to use)
2. Variants with clear use cases
3. Accessibility requirements
4. Implementation notes for engineers
5. Examples of correct usage
Follow-up prompts:
Add do/don't examples.
What edge cases need specific guidance?
How does this component relate to [other component]?
7. Portfolio and Case Studies
When to use: Documenting work for your portfolio, job searching, sharing learnings.
Prompt pattern:
Help me write a case study:
Project: [what you worked on]
Role: [what you did]
Challenge: [the problem]
Process: [your approach]
Outcome: [results, impact]
Learnings: [what you'd do differently]
Structure a case study that:
1. Hooks the reader with the challenge
2. Shows my thinking, not just the outcome
3. Demonstrates collaboration
4. Is honest about constraints and tradeoffs
5. Includes measurable impact where possible
Follow-up prompts:
Make the beginning more compelling.
I can't show the final product. How do I still tell the story?
What questions will a hiring manager have after reading this?
Practice Progression
Week 1: Synthesize a recent research study using the prompts.
Week 2: Prepare for a design critique using the framework.
Week 3: Document a component or flow for handoff.
Week 4: Write or improve a portfolio case study.
What Great Looks Like
After consistent use, you should notice:
- Faster, clearer documentation
- Better-prepared critiques with more useful feedback
- Stronger stakeholder communication
- More effective research synthesis
The goal isn’t for Alex to design — it’s for Alex to accelerate everything around the design.
Working with Visual Tools
Alex can’t see images, but you can work around this:
- Describe your design decisions in words
- Use Alex to structure your thinking before you sketch
- Paste component descriptions for documentation
- Describe the problem, then design the solution visually
The constraint of articulating forces clarity.