Turn a need into a testable brief

A capstone is a final project where you put your practiced skills together. Build an original React and TypeScript app for a community or learning task you understand. You may adapt the reference idea, but choose and explain your own content, interactions and layout. Think of a science project: the example can guide you, but you must make the decisions and show the evidence. Use sample data. If you tested only a made-up scenario yourself, describe it honestly rather than claiming real user research.

A brief is a short plan. Say who the app is for, what they need to do, what makes it difficult now and the smallest useful improvement. Keep the first version small enough to finish, test, and hand over. Accounts, payments, messaging, and AI features are not required for this frontend project.

A learner wants to find a short practice resource and return to it later. A Community Resource Finder offers a searchable list, category filters, saved resources, and a detail view. It uses twelve records. A record might be: R001, "Keyboard Navigation Practice", category "digital", duration 15 minutes, and an original description.

An acceptance criterion is an expected behavior another person can check. For example: "Given the category is digital and the search is keyboard, the result list shows matching resources and a visible count. Clearing the filters restores the full list." Another reads: "A user can save a resource using the keyboard, reload, and find it in Saved."

"Looks modern" is not a functional acceptance criterion. Define what the person can do and how you will check it.

1. Explore two possible needs, then choose one.
2. Write a test user scenario or accurately record any permitted real feedback.
3. Draft a one-page brief with purpose, audience, three to five features, exclusions, and delivery constraints.
4. Write at least eight acceptance criteria.
5. Include the main task, no results, invalid or unavailable data, keyboard use, and saved-state behavior if relevant.
6. Sketch two approaches, then compare how useful they are and how much work they need.
7. Review scope and create an initial backlog, a list of tasks still to do.

If you already have a project, revisit its requirements rather than counting unrelated prior work as this stage.

A request proposes adding a login and shared recommendations. Explain why that changes the data and security requirements. For this frontend version, a defensible decision is to keep local, non-sensitive saved items and record shared accounts as a future feature rather than pretending local storage is secure multi-user storage.

Save brief-v01, acceptance-criteria, scope-decisions, and backlog in the repository. Your first review checkpoint is a coherent task with testable boundaries. These documents will guide implementation and the final demonstration.