Project Theme and Criteria

Project Theme

Each group identifies a specific, real collaboration pain point experienced by software engineering teams, academic research, or study teams, and builds a working tool that meaningfully reduces that friction. The tool must support interaction between at least two people. AI may be used where it genuinely adds value; its use must be justified, not assumed.

What This Means in Practice

The theme is deliberately broad. “Collaboration” covers a wide range of friction that teams experience. Projects should be specific. For instance, one that aims to address “poor team communication” is considered too vague — it might not be helpful in building something useful or in evaluating whether it worked. A project that addresses “engineering teams reviewing pull requests asynchronously lose context about why a decision was made, leading to redundant back-and-forth in code review” is specific enough to build toward and to measure. This project should also address real collaboration experience — it should be grounded in problems of collaboration that actually exist. We therefore encourage teams to talk to real people outside your team who have experienced the problem before settling on an idea and starting to think about your design.

Example Problem Areas

Your team should choose a problem you find genuinely interesting and can find real users for. The following lists are examples that may be helpful as inspiration — starting points for brainstorming, not a menu to choose from. The strongest projects address problems your team has direct access to and deeply cares about. A narrower problem you can evaluate properly is always better than a broader problem you cannot.

Software Engineering Team Collaboration

• Knowledge transfer when a team member joins or leaves: onboarding takes weeks because context is undocumented
• Code review bottlenecks: PRs sit unreviewed for days because reviewers lack context about the change's intent
• Meeting-to-action gap: decisions made in standups are not captured in a form that is useful for people who were absent
• Dependency coordination: teams working on interconnected components do not know when upstream changes affect their work
• Incident retrospectives: teams repeat the same post-mortem format without retaining institutional learning across incidents

Academic Research Collaboration

• Literature synthesis across team members: researchers read different papers and struggle to build a shared understanding of the field
• Research handoff between lab generations: graduating students leave behind knowledge that new students cannot easily access
• Experiment documentation: research teams run variations of experiments but do not document decisions in a way that is reproducible

Study Team Collaboration

• Study group coordination: groups preparing for exams cannot easily share and consolidate notes across different members' understanding
• Collaborative writing friction: co-authors working on a shared document lose track of who changed what and why

What the Tool Must Do

• Support interaction between at least two people: a tool only one person uses is not a collaboration tool
• Address a specific, evidenced collaboration pain point: you must be able to describe the problem clearly and show that real people (people outside of your team) experience it
• Be demonstrable: by Week 16, two people must be able to use it together in a live demo
• Be evaluable: you must be able to show evidence that it reduces the collaboration problem, not just that it works technically

What Is Not in Scope

• General productivity tools: a to-do list or calendar app is not a collaboration tool unless it specifically addresses how two or more people coordinate
• Chatbots that answer questions: unless the chatbot specifically reduces a documented collaboration friction between team members
• Tools that solve your own team's workflow: you cannot be your own primary user population; you need external users
• Fully automated systems with no human interaction: the tool must involve at least two people interacting, not a pipeline that runs without human input

Strong vs. Weak Project Directions

On Using AI in Your Tool

AI is not required as part of the tool. Some of the strongest collaboration tools are not AI-powered, but are well-designed interfaces, smart notification systems, or structured workflows. If your tool does not use AI, that is a legitimate engineering choice — you will be asked to briefly explain why AI did not add value for your specific problem.

If your tool does use AI, two questions must be answered before you start building:

• What does the AI decide, and what does the human decide? Where in the interaction does the user retain control?
• How will you evaluate whether the AI component improves the collaboration interaction — not just that it works technically?

AI used as a feature because it is interesting, rather than because it solves a specific part of the collaboration problem, tends to make tools worse rather than better. The course is about engineering judgment — using AI where it genuinely helps is part of that judgment.

Evaluation Expectation

By the final presentation, your team must provide evidence that the tool reduces the collaboration problem — not just that users found it pleasant to use. Evidence means something observable changed: users completed a task faster, asked fewer clarifying questions, made fewer errors, or reported a specific friction being reduced.

“Users said they liked it” is not sufficient evidence on its own. “Users who used the tool during code review asked 40% fewer questions about design intent than in a baseline session without the tool” is evidence. You do not need a large-scale study — two to three well-documented sessions with real users outside your team, with a clear before/after comparison, is sufficient for a semester project.

← Back to Final Project