Checkpoint 1 (CP1)
Phase 1 — Discovery · Due Week 6 (async) · 5%
Overview
CP1 establishes your team's shared direction and evaluation thinking before serious building begins. It is a light deliverable by design — the goal is alignment, not exhaustive documentation. A focused, honest CP1 is more valuable than a polished but vague one.
What to Submit
1. Team Charter
Your team's agreed working norms. Include:
- How your team makes decisions when there is disagreement
- Your definition of done for a piece of work
- How your team communicates outside of class (frequency, channel, expectations)
2. Problem Statement with Evidence
A clear description of the collaboration pain point you are addressing. Include:
- What the problem is, and who specifically experiences this problem
- How you know the problem is real — you must have spoken with at least two people outside your team who actually experience this problem. Summarize what they told you.
- Why existing tools or approaches do not adequately solve it
3. Initial Interaction Design Sketch
A description or diagram of what your tool does. Include:
- What the tool does at a high level
- What the inputs and outputs are
- How two people would interact with it together
This does not have to be finalized. Your design could change across the semester.
4. Draft Evaluation Plan
How you will know whether your tool works. Include:
- Success definition: “We will know our tool works if...” — something observable and measurable
- Target users: who you will test with, and how you will access them
- Method: which evaluation approach (structured observation, pre/post survey, or brief interview) and roughly when you plan to conduct the evaluation
- Minimum evidence threshold: what would convince someone skeptical of your idea?
- Human-AI boundary (if your tool uses AI): what does the AI decide, and what does the human decide?
5. Repository Link
Confirm that your GitHub repository is set up with:
- Branch protection on main
- PR template in place (
.github/PULL_REQUEST_TEMPLATE.md) - DECISIONS.md started with at least one entry
- Current code steward recorded in DECISIONS.md
What Makes a Strong CP1
A strong CP1 is specific. “Teams have trouble communicating” is not a problem statement. “Engineering teams reviewing pull requests asynchronously lose context about why a decision was made, leading to redundant back-and-forth in code review” is a problem statement.
A strong CP1 is honest. If you are not sure about something — your target users, your evaluation method, whether your tool idea will work — say so. Uncertainty acknowledged now is easier to address than uncertainty hidden until CP2.
A strong CP1 is grounded in real evidence. The minimum is two conversations with real users. Teams that conduct more conversations at this stage consistently build better tools.
Rubrics
Submission
Submit one PDF or zip file per group to E3 under “CP1.” File name:
GroupXX_CP1.