Session 2

Problem Framing

The Most Skipped Step

Problem framing is the most commonly skipped competency in engineering education.

It is also the one that matters most.

Quick Poll

"Build a robot."

If I handed you this as your whole assignment, what would you need to know before you could start?

What's Missing?

None of these have answers yet:

• Who is it for?
• What do they actually need it to do?
• What can't it cost, weigh, or take longer than?
• How would you know if you'd succeeded?

The 4-Part Framework

• User — a specific person or group, not "people"
• Need — stated as a problem, not a solution
• Constraints — cost, size, materials, time
• Success Criteria — how you'd know it worked

The 4-Part Framework

Worked Example

VAGUE: "Build a robot."

PRECISE: "Design a device that lets a user with limited hand mobility press an Xbox controller trigger independently."

What Does This Sentence Actually Cover?

• User — named: a person with limited hand mobility
• Need — named: press a trigger independently
• Constraints & Success Criteria — onlyimplied so far — still need to be spelled out (cost, size relative to the controller, must not interfere with other buttons, must work one-handed)

Even a good-sounding sentence can still be missing two of the four parts.

Guided Rewrite #1

"Make something to help someone."

Let's fill in all four parts together, as a class.

Guided Rewrite #2

"Design a better backpack."

A second rep, faster this time, before groups work on their own — protects students who needed to see it twice.

Small-Group Practice

Choose 2 of these prompts:

1. "Build a robot."
2. "Create a tool that makes life easier."
3. "Design a better backpack."
4. Or another vague prompt approved by your instructor

Small-Group Practice

For each one:

1. Draft all four parts separately
2. Combine them into a real sentence
3. Trade with another group — stress-test their weakest part
4. Revise before you share out

Share & Critique

• User check — specific person/group, or still vague?
• Need check — actually a need, or a solution in disguise?
• Constraints + Success checks — concrete and checkable?

Common Traps

• Restating the prompt with extra adjectives ("a really useful robot")
• Writing a solution instead of a need ("needs a claw arm")
• Constraints too vague to check ("cheap," "fast")

One More Thing: Start Your Notebook

Engineers document the process, not just the final result.

Today's rewrite is your first entry.

Every Entry Needs

• A date
• Your problem statement
• A sketch of the problem — not a solution yet

Every Entry Needs

Format

Physical notebook or shared digital doc — your instructor will tell you which this class uses.

Either way, every entry follows the same structure, and every entry gets a date. No exceptions.

Next Time

Session 3: Design & Ideation

Time to sketch actual solutions to the problem you just documented.

'F' → Fullscreen

Build

In your group, choose 2 of the vague prompts below. For each one, work through all four steps below — don't jump straight to a final sentence.

Prompts

1. "Build a robot."
2. "Create a tool that makes life easier."
3. "Design a better backpack."
4. Or another vague prompt approved by your instructor

Step 1: Draft Each Part Separately

Before combining anything, write a short phrase for each of the four parts:

• User — who, specifically?
• Need — what problem, stated without naming a solution?
• Constraints — what concrete limits apply (cost, size, materials, time)?
• Success criteria — how would you check, concretely, that it worked?

Step 2: Combine Into a Problem Statement

Merge your four parts into 1–2 full sentences, not a bullet list — you should be able to read it aloud and have it make sense as a real design brief.

Step 3: Peer Stress-Test

Trade your rewritten statements with another group. For each one you receive, find one weak part — a vague user, a disguised solution, an uncheckable constraint, or unclear success criteria — and hand it back with that one critique.

Step 4: Revise

Use your peer group's critique to strengthen your weakest part before the whole-class share-out.

Be ready to share one of your two rewrites with the class and defend each of your four parts.

Step 5: Start Your Design Notebook

Your instructor will tell you whether this class uses aphysical notebook or a shared digital doc. Set it up now, labeled with your name and this class period — every student keeps one, even though today's problem statement came from your group.

Write your first entry with all three required parts:

• Date — today's date
• Problem Statement — the rewrite you just shared or revised, copied into your own notebook
• Sketch — a quick drawing of the situation your problem statement describes — not a solution. Just a picture of the problem itself.

None of this needs to be neat. It needs to be honest and dated.

Checkpoint

Before you share out, check your own rewrite against these four questions — the same ones the class will use to critique it.

If a part is missing or vague, fix it now — you'll get one chance to patch it live if the class catches it during share-out, but it's better to catch it yourself first.

Then check your notebook entry for all three required parts.

This entry is graded on completeness only, not quality — all three parts present is a full score.

Reflection

Answer the following questions before submitting your work.

1. What weak part did the peer group find in your rewrite during the stress-test, and how did you fix it?
2. Which of the four parts — User, Need, Constraints, Success Criteria — do you think is hardest to get right, and why?
3. Why do you think engineers date every entry instead of keeping one big undated file?
4. Do you already have a solution in mind for your problem, even though we haven't started Design yet? Session 3 is where you'll test that instinct — are you willing to consider other ideas before committing to it?

Submit

Submit your group's rewrite, your first notebook entry, and your individual reflection.

Activity Complete