You've got the skills. You've got the workflow. Now it's time to build something real. But first—what exactly are you building? A good project spec answers that question clearly.
📋 What's a Project Spec?
A project spec is a simple document that describes:
- What you're building
- Why you're building it
- Who it's for
- What success looks like
It doesn't need to be long or formal. A few paragraphs is often enough.
Project Spec Template
A fill-in-the-blank template for defining your project
📄 Preview PDF
📝 A Simple Template
🎯 Why This Matters
Writing a spec forces you to make decisions before you're in the middle of building. It prevents:
- Scope creep ("Oh, and it should also do X, Y, Z...")
- Unclear success ("Is this done? I don't know...")
- Wasted work ("Wait, we didn't need that feature?")
- Direction changes ("Actually, let's do something different")
✨ Your ID Superpower
As an instructional designer, you've written specs before—they're called design documents, learning objectives, or project briefs. Same skill, new context. You're defining outcomes before creating content.
💡 Example: Reading Companion App
Here's what a spec might look like for a simple reading tracker:
📚 More Example Specs
Different projects, same template. Here are three more to inspire you:
Problem: I lose track of time when building e-learning modules and end up spending too long on individual activities.
Solution: A simple timer that tracks how long I spend on each task and shows me where my time goes.
Core Features: Start/stop timer, name the task, see today's time breakdown
Out of Scope: Multi-day tracking, export to Excel, team features
Success: Can see I spent 90 minutes on quiz questions this morning
Problem: Review comments come via email, Slack, meetings—I need one place to track all feedback.
Solution: A tracker where I can log feedback items, assign them to course sections, and mark them as addressed.
Core Features: Add feedback with source/date, tag by course section, mark as done
Out of Scope: Email integration, notifications, version history
Success: Can see all open feedback for Module 3, know what's been addressed
Problem: Planning branching scenarios on paper gets messy. I need a visual tool.
Solution: A simple tool to map out decision points and consequences in branching scenarios.
Core Features: Add decision points, create branches, view visual map
Out of Scope: Export to Storyline, collaboration features, complex logic
Success: Can map a 3-decision scenario and see all possible paths
⚡ Pro Tip: The Smaller, The Better
Notice how each example solves ONE specific problem. That's the sweet spot for your first project. If your spec is trying to solve 5 problems, it's probably too big.
✏️ Write Your Own Spec
Now it's your turn. Use this guided activity to write your first project spec:
🎯 Your Project Spec
Think about something that frustrates you in your work. What takes too long? What's tedious? What could be easier?
Write 2-3 sentences describing the problem.
In the simplest terms, what are you building? Don't overthink it.
Describe your solution in 1-2 sentences.
What does this thing actually DO? What are the essential features that make it useful?
List 3-5 features. If you have more than 5, you're probably trying to do too much.
This is just as important as what you ARE building. What features sound cool but aren't essential for version 1?
List 2-3 things you're explicitly leaving out of the MVP.
What's a concrete test you can do to prove this is useful?
Write 2-3 success criteria: "I can [do thing] and see [result]"
Keep it simple. For most web-based ID tools: HTML/CSS/JavaScript is fine.
Note any specific requirements or constraints.
Open a text editor and create a file called
PROJECT-SPEC.md. Copy your answers into the template format. Congratulations—you have a spec!
✅ Success Check
You'll know your spec is good when: someone else could read it and understand exactly what you're building and why—without you explaining it to them.
🔄 Getting Claude's Help
Claude can help you write a spec. Try:
Claude will interview you, then help organize your answers into a clear spec.
💡 Start Small
Your first project spec should describe something you can build in a few sessions. Ambitious is fine for later—right now, aim for something achievable.
📚 Resources & Further Reading
- Shaping (Basecamp) How to define work before starting to build
- How to Plan an MVP (Y Combinator) Deciding what to build first
💭 Pause & Reflect
Before moving on, take a moment to consider:
- Do you have a clear spec for your project? Could you explain it in one sentence?
- Have you been ruthless about "Out of Scope"? Are you trying to do too much?
- What's making you excited about building this?
🎯 Spec Skills Unlocked
You know how to define a project clearly. Next: breaking it into buildable phases.
Topic 4.1 Complete • Up Next: 4.2 – Breaking Into Phases