Landing Page
Your project needs a front door: the page a recruiter, a future user, or your project partner’s boss lands on and understands in thirty seconds what this is and why it matters. Building one is product communication, a skill now expected of engineers alongside technical ability, and it gives every team member a link that belongs on a resume and in the Career and Individual Retrospective.
This is a team submission. One page, built together, crediting everyone. Individual portfolio pages are encouraged but are not this assignment.
What You Must Produce
Section titled “What You Must Produce”A public URL plus a full-page screenshot (the screenshot is the graded snapshot; the URL proves it is live). Pick the format that fits your project:
- A dedicated landing or product page (GitHub Pages, Vercel, Netlify, itch.io)
- A polished repository README with structure, visuals, and a user-facing description
- For research and R&D projects: a results page, preprint link, or published paper page, or a repository README a stranger can actually run. That means what the work shows, a figure or result table, and a worked example with the exact commands and the output to expect. For a research project the README usually is the front door, because the people who find your work arrive at the repository, and a README nobody can run is the research equivalent of a demo that crashes. Make Your Artifact Reproducible is the activity that gets you there.
Talk to your partner first: they may have an existing page to update rather than replace. Multi-year projects credit past contributors and may build on a previous team’s page.
Required Content (any format)
Section titled “Required Content (any format)”- Description and value proposition: one sentence saying what it is and who it is for; the problem it solves and why that matters; the “so what” that makes it notable. Written for the audience, not the grader.
- Highlights: 3 to 5 features, findings, or capabilities from the audience’s perspective, with at least one real screenshot, figure, or demo clip showing the project in action.
- How to try it: a clear call to action (Download, Play, Try it, View on GitHub, Read the paper) with brief prerequisites or platform notes.
- Credits and contact: all current team members, past contributors on multi-year projects, and a feedback channel (issues, email, or a form).
Rubric (100 points)
Section titled “Rubric (100 points)”| Criterion | Points | Outcome |
|---|---|---|
| Value proposition: one sentence says what it is and for whom, the problem is stated in the user’s terms, and no course vocabulary (capstone, team, partner, sprint, rubric) appears on the page | 30 | SO3 |
| Highlights and access: 3 to 5 audience-perspective highlights, at least one real visual of the project in action, and a working call to action | 35 | SO2 |
| Credits and contact: everyone credited, past contributors acknowledged where applicable, feedback channel present | 15 | SO4 |
| Polish and accessibility: intentional visual hierarchy, alt text, sufficient contrast, descriptive link text, no broken anything | 20 | SO3 |
AI use: AI may write copy and code for the page. Every claim about features, capabilities, and results must be accurate; a landing page that oversells what exists is graded as inaccurate, not ambitious.
Activities That Prepare This
Section titled “Activities That Prepare This”Designing for Accessibility for the polish-and-accessibility criterion, which is 20 of the 100 points here, and The Mom Test for the value proposition. Wire an Accessibility Audit Into CI automates the mechanical half of the accessibility check.
Browse communication and design when these run out.