Project details

Each team of 3–4 builds a working Personal Health Assistant over the term: it pulls in real health data, stores and retrieves it, reasons over it through an LLM/RAG/agent component, and faces its user through an interface a non-technical person could actually use — with safety, privacy, and evaluation designed in rather than bolted on.

The project has three deliverables, and your project grade accumulates across them:

• Part 1 — Project idea one-pager (Week 4 · Oct 2) · graded with the Week 4 lab
• Part 2 — Proposal presentation (Week 9 · Nov 6) · 15%
• Part 3 — Final demo (Week 14 · Dec 11) · 30% implementation + 20% demo + 15% writeup

Between the parts, the weekly labs carry the project forward — a project-direction discussion in Week 6, the Week 8 design studio that produces your proposal artifacts, and an integration checkpoint with a mock demo in Week 13 — so no part starts from a blank page.

Week 4 is team formation: speed pitches, teams of 3–4 forming around shared interest and complementary backgrounds, and a feasibility check on candidate ideas. Leave the room with a paragraph; turn it into a page.

The one-pager is a simple write-up of the idea your team has settled on. One page, five things, a few sentences each:

• Team. Names, and who brings what (CS, health, design).
• User and question. One specific person and the question they ask — “a shift worker who wants to know why their sleep is falling apart,” not “people interested in health.”
• Data. Which sources you will use and where they come from: your own Fitbit data, synthetic records, a public dataset. Data you cannot touch yet does not count.
• Core interaction. What the user does with the assistant, as one concrete flow.
• Demo moment. The thirty seconds at the showcase that will make someone walk over to your station.

The one-pager is not a contract — the idea will shift as you learn what your data can support. It is a commitment to a direction, and the raw material for Part 2.

Submit it with your Week 4 take-home lab by Wednesday, Oct 7, 11:59 PM ET.

The proposal is where your project stops being an idea. By proposal day your team should know what your assistant does and for whom, and be actively working out how. This part is worth 15% of the course grade.

Bring something concrete

A slide of bullet points is not enough to present. Every team shows at least one tangible design artifact:

• a rough prototype, however small,
• a hand-drawn interface,
• a system or architecture sketch,
• or another concrete design artifact: a storyboard, an annotated user flow, a wireframe.

Reviewers can only give feedback as specific as what you show them — a team that presents a sketched screen hears “that confidence label will be misread”; a team that presents a concept hears “sounds interesting.” You will leave the Week 8 design studio with a storyboard, a core user flow, and a low-fidelity prototype: bring them, updated with everything you have decided since. And present live questions, not settled answers — feedback is most useful on the calls you have not yet made.

The presentation

Each team presents for 5 minutes, followed by 3 minutes of structured peer feedback; presentation order is announced in advance.

1. Problem statement and target user (1 min)
2. Data sources and access plan (1 min)
3. Technical architecture and interface concept (1.5 min)
4. Evaluation plan and timeline (1 min)

Show your artifact when you reach architecture and interface, and end with the one or two questions you most want feedback on. Anything interactive goes into the slides as screenshots or a short recording — you will not debug a live demo in a 5-minute slot. During the feedback round, listen and take notes rather than defending; instructors and TAs use the same protocol and hand you written cards.

The written draft is the Week 9 lab notebook — the five-part structure taught in class (problem, data plan, technical approach, evaluation, timeline & risks), finalized with the feedback from your presentation.

Have your slides ready by class time on Friday, Nov 6; submit the written draft by Wednesday, Nov 11, 11:59 PM ET.

The term ends with a poster-and-demo showcase: each team gives a one-minute lightning pitch, then the room breaks into rotating poster and demo stations. We plan to invite guests from industry, academia, and health AI practice. You will have rehearsed all of it at the Week 13 integration checkpoint and mock demo.

The lightning pitch has one goal: make people walk to your station. One minute covers the problem, the user, and the single most compelling thing your assistant does. Rehearse it out loud — a minute is shorter than it reads.

The demo is where a health AI system earns or loses trust, so demo honestly: show what the system actually does, label what is real data versus mocked, and claim no clinical authority the system does not have. Live demos fail at showcases; a team with a recorded fallback loses thirty seconds, a team without one loses the demo.

Checklist:

• A working system behind the demo (implementation, 30%)
• A live demo, with a recorded fallback (demo, 20%)
• A poster or visual summary, including your architecture diagram
• A short technical writeup (15%): what you built and how it works, your safety and privacy stance, what you measured against the criteria from your proposal, what you learned and would build next — plus who did what, and each member’s individual reflection (what I tried, what failed, what I learned, how I used AI). Due Wednesday, Dec 16, 11:59 PM ET (tentative), so you can write about what happened at the showcase.

The demo and the implementation behind it are graded separately: a slick walkthrough over hardcoded data will not carry a missing system, and a rough-edged demo of a genuinely working pipeline scores better than it feels.

Across all three parts, the same judgment applies.

We are looking for:

• A system that runs end-to-end on real or realistic health data
• Answers grounded in that data, with the source visible to the user
• Honest uncertainty: an assistant that knows when to say “I don’t know” and when to escalate to a human
• An interface a non-technical person could actually use
• Safety and privacy treated as design constraints, not disclaimers

We would also love to see:

• A novel interaction, retrieval, or agent design
• Evaluation with real users (classmates count)
• Graceful degradation when a model, API, or data source fails

Make sure you do not have:

• A happy-path demo with no fallback
• Overclaiming: diagnosis language or clinical authority the system does not have
• Unsafe outputs in scenarios where refusal or escalation was the right call
• A polished interface over hardcoded data
• A writeup that inflates results the demo cannot back up