P3: Beta (complete functionality)
| Milestone | Due date |
|---|---|
| Overview | |
| P1: Design | Monday, October 5, 2026, 11:59 PM |
| P2: Alpha (MVP) | Tuesday, October 13, 2026, 11:59 PM |
| P3: Beta (complete functionality) | Monday, October 19, 2026, 11:59 PM |
| P4: Code complete | Monday, October 26, 2026, 11:59 PM |
| P5: User testing | Monday, November 2, 2026, 11:59 PM |
Due Monday, October 19, 2026, at 11:59 PM.
Overview
Complete the functionality of your app and refine its visual and interaction design. By this milestone, your front end and back end should work together to support all the intended functionality. To showcase this progress, you will also deploy your app to the class deployment platform at a live URL, allowing you to begin to share the app and see it running online.
Visual design study. This assignment includes an exercise in visual design. The sketches you constructed in P1 focused on identifying the high-level user interface elements your app would use, how they would be laid out, and how users would flow between different screens of your app. In contrast, a visual design study will help you establish the “look and feel” of your app—namely, what fonts and colors you use, and how they communicate your app’s purpose and function.
Tasks
Complete your app. Complete any missing functionality by implementing the remaining concepts, reactions, views, formers and front-end components.
You are likely to find you will need to make changes both to the back end and to the front end. If you didn’t complete all your concept implementations, this is the time to do it! As you change your implementation, update the corresponding specifications in your project’s design/ folder.
Make sure to test your front end repeatedly as you develop, ensuring that it works correctly with your evolving back end.
Document any significant changes to your design in your design notebook. Record the issues that arise, the options you consider, and why you choose one over another. For example, did testing reveal that a concept needed to change? Did you change an interaction because the next step wasn’t clear to the user? Did you change the layout, colors, or typography to make important information easier to notice? Explain what the problem was, what you changed, and why. Keep entries brief and write them as you work.
Deploy your app. Deploy your app to 6.1040 Apps, the class platform, at a live URL of your choice: https://<name>.mit-sdg.dev. Follow the guide to deploying your app, starting with "Before you start".
Each of you can have two apps, and only course staff can delete one. Use one for your personal project and keep the other for your team project.
Plan on about half an hour for your first deployment: some time to prepare your code, then 10 to 20 minutes while the platform deploys it. Later deployments take 10 to 20 minutes. Deploy your P2 app early in the week, and redeploy as you add features. Some problems only appear once the app is online, and you will want time to fix them.
Only members of the class can sign in with Commons. If you add sign-in and people outside the class will test your app in P5, they will need another way to sign in, such as a password. The guide's "Letting people sign in" section explains both.
If you get stuck, see the guide's "If something goes wrong" section, and ask on the Commons forum.
Concept tests. Extend the automated tests you wrote in P2 to cover each completed concept. Use Bun’s testing framework. For each concept, include:
A sequence of actions corresponding to its operational principle.
Other scenarios that exercise behavior beyond the operational principle, such as deletions, cancellations, and repeated actions.
Error cases in which an action should reject a request. Check that it reports the expected error and does not make changes that should only occur on success.
Every action should be executed in at least one test. Use assertions to check results in code, rather than relying on manually interpreting printed output.
Test complete user journeys. Run through your user journeys using the interface. Check that the interface updates correctly and that changes are stored. Try erroneous inputs and, where access is restricted, check that another user cannot read or change data they should not have access to. Record what you checked and any unresolved problems in your design notebook.
Visual design study. Look through a diverse range of visual media (including photographs, screenshots, magazines, newsprint, graphic novels, etc.) and assemble two slides of inspiration focusing on typography and color, respectively.
On each slide, collage together examples that you find particularly inspiring, and then use the margins to extract or annotate particular design choices you might be interested in exploring (e.g., specific color palettes and font families, or characteristics that you find interesting such as serifs, tall/short x-heights, etc.).
Here is an example of a slide that focuses on color selection.
Styling and Layout. Turn to the aesthetic aspects of your user interface design. Drawing on your design study, make choices for the layout of your components, as well as the colors and typography they use, to provide a usable, accessible, and pleasant experience for your users.
Think about how you can use these different aspects of style to convey importance (e.g., using colors to indicate successes or errors) or an order of operations (e.g., left or right sidebars, or heading levels to suggest an outline). Annotate your visual design study to explain which choices you used in your interface and why.
Update your user journey and screen recording. Update the journey to reflect the beta, and make an updated narrated screen recording, at most two minutes long.
Deliverables
Your code and specifications.
The URL of your deployed app, running the commit you submit.
Your automated tests and their saved execution output. Include instructions in the README for running the tests, including any database setup.
Your visual design study.
An updated user journey.
An updated screen recording.
Your updated design notebook.
Submitting your work. Keep your code, specifications, tests and saved outputs, visual design study, and updated user journey in your public project repository, linked from its main README. Include a YouTube link to your screen recording. Keep your updated design notebook in your private individual repository, linked from its main README. Commit and push your work in both repositories by the deadline. Submit both repository links and their corresponding commit hashes, together with the video link and your app's URL, through the P3 assignment in Commons.
Rubrics
P3 assesses implementing a concept-based application, testing and validating software, interaction design, visual design, and technical writing.
Advice
Using the sync-engine skill (optional). The sync-engine skill gives your coding agent a structured workflow for design, review, implementation, and validation that may be helpful as you complete your app. llms.txt is a documentation index with working rules; the skill tells the agent how to organize the work.
Follow the skill setup instructions, then explicitly ask your agent:
Read and follow the sync-engine skill at
https://github.com/mit-sdg/sync-engine/blob/main/packages/skill/skills/sync-engine/SKILL.md
and its linked workflow. Use it to help me complete P3 in this repository,
using the assignment requirements and my existing design as context.
Writing tests. Step 5 of the MongoDB setup guide shows how to write tests with Bun, check results with assertions, and set up a separate test database. For concepts that use MongoDB, follow that setup so your tests do not affect your application’s data. Start each test with a clean state and create the data it needs by calling concept actions. Clearing the test database between tests is fine; inserting records directly would bypass the behavior you’re trying to test.
Choosing test cases. Your operational principle gives you a starting point, but it won’t usually exercise every action or every possible outcome. Look through your action specifications for other cases worth checking. What happens if an action is repeated, something is canceled, or two users act on the same item? Choose cases that could expose different issues.
Color palettes. Finding colors that work together can be tricky business. We recommend using a color palette generator like Coolors or Adobe Color.
Typography. You are not restricted to the basic fonts available in the browser. Instead, feel free to browse the large libraries of free fonts available via Google and Adobe — follow the instructions for how to include such fonts in your Vue app. If you Google around, you’ll find lots of recommendations for which fonts are popular currently, and how you might mix fonts together (e.g., a serif font for body text, and a sans serif font for headings, etc).