Session 1: Welcome to Digital Manufacturing
Unit 2 — Manufacturing Foundations, Week 1
Unit 2
Digital Manufacturing
For the Next 8 Weeks
You're not just students in a shop class.
You're an engineering team, hired to design and build something real for a client.
The Arc
| Weeks | Phase |
|---|---|
| 1–4 | Manufacturing Foundations |
| 5–8 | The Arcade Cabinet Project |
Manufacturing Foundations (Weeks 1–4)
- Working with a real client's brief
- Materials & manufacturing processes
- CAD, leveled up
- CAM — programming a CNC machine
- A small practice build, start to finish
Then: The Real Project
Weeks 5–8, you'll get an actual client brief and build a genuinely unique arcade cabinet from it — CNC-cut panels, real electronics, your own design.
Everything these first 4 weeks teach you gets spent for real there.
Today: Working With a Client
Before any CAD, CAM, or materials — the skill this whole unit starts with.
Session 2 Gave You a Clean Prompt
"Build a robot." Vague, but written for a classroom.
Real Clients Don't Write for Engineers
They describe what they want in their own words — not yours. Translating that is a real, separate skill.
Same 4-Part Framework
The framework from Session 2 doesn't change. What changes is how much digging it takes to fill it in.
Practice Client Ask
"The bus stop by the park doesn't have anywhere to sit, and people are stuck waiting in the rain."
What's Actually In This Sentence?
Read it again. Notice what it doesn't tell you.
What's Actually In This Sentence?
- User — "people," but which people? Daily commuters? Elderly riders? Parents with strollers?
- Need — "somewhere to sit" and "stuck in the rain" name two problems, but is the real need comfort, safety, or something else?
- Constraints — not mentioned at all. City budget? Sidewalk space? Can't block foot traffic?
- Success Criteria — not stated. Fewer complaints? Higher ridership? A survey?
When It's Not Written Down
You don't guess. You ask.
A Bad Clarifying Question
"What do you want?"
Too broad — makes the client do your job for you.
A Good Clarifying Question
"Is this mainly for everyday commuters, or is accessibility for elderly or disabled riders the bigger concern?"
Specific enough that a non-technical person can actually answer it.
Two Things to Remember
A vague ask isn't a bad ask.
It's normal — real clients aren't engineers. Translating it is your job, not a flaw in their brief.
Two Things to Remember
Don't design before you've finished asking.
Jumping to a solution before Constraints and Success Criteria are pinned down is the same mistake Session 1 warned about — skipping Design and going straight to Build.
Next Time
Session 2: Materials for Subtractive Manufacturing
Before you can design anything for a client, you need to know what you're actually building it out of.
'F' → Fullscreen
Build
The practice client ask below is unrelated to the real Week 5 project on purpose — today is about practicing the skill, not pre-solving the actual brief you'll get later.
Step 1: Read and Draft (Individually)
Practice client ask:
"The bus stop by the park doesn't have anywhere to sit, and people are stuck waiting in the rain."
Draft your own read of all four parts. For each one, mark whether it's explicit (actually stated), implied (a reasonable guess), or missing entirely.
- User — who, specifically?
- Need — what problem, not what solution?
- Constraints — budget, space, timeline, anything else?
- Success Criteria — how would you actually measure it?
Step 2: Compare With a Partner
Trade drafts. Where did you interpret the ask differently? Any disagreement here is exactly the kind of ambiguity a clarifying question would resolve — it's not a sign either of you read it wrong.
Step 3: Write 3 Clarifying Questions
Write 3 questions you'd actually ask this client before starting design work. Each one should be specific enough that a non-technical person could answer it — not "what do you want?"
Step 4: Role-Play (With Your Partner)
One of you plays the client — answer only in plain, non-technical language, improvising reasonable answers. The other asks their 3 clarifying questions live, then revises their 4-part breakdown based on the answers. Switch roles if time allows.
Checkpoint
Before you move on, check your work against these two questions.
- Did you separate stated fact from assumption?
- Your draft should clearly mark what the client actually said versus what you filled in yourself.
- Are your clarifying questions actually answerable?
- A non-technical client should be able to answer each one without needing to think like an engineer first.
Reflection
Answer the following questions before submitting your work.
- Which of the four parts was hardest to pin down from this vague, non-technical ask, compared to Session 2's cleaner classroom prompts?
- Was there a moment you started imagining a solution before you'd finished clarifying the actual need? What caught it, if anything?
- In Week 5, you'll receive an actual client brief for the arcade project. What's one thing you'll do differently this time, now that you've practiced?
Submit
Submit your initial draft, your 3 clarifying questions, your revised breakdown from the role-play, and your reflection.