Overview. The beta release of your final project should feature a working implementation that realizes all the central functionality of your app design (i.e., all core, novel concepts). The frontend should be styled and laid out sufficiently to enable a usable experience, but rough edges are A-OK. You will also begin planning for user testing which will come next week.

Your Tasks

  1. Continue Implementation. Pick up where your alpha release left off. Implement the functionality of your design, apply necessary styling, and deploy it to a publicly accessible URL. As before, you may reuse any starter code we provided (i.e., with A4 and/or A5), or any code you or your team members have written for the individual assignments.

    As you work through the implementation, we recommend formatting and commenting your code appropriately. Although code quality will not be an explicit part of your grade, the code must be easily understandable so that TAs, in grading your project’s functionality, can easily map observed behaviors in the deployed app to the underlying code.

  2. Design Revisions. As you work through your implementation, jot down any changes you make to the design you envisaged as part of P3: Convergent Design. For each change, write down a brief (1–2 sentence) rationale for why the change was necessary. For instance, perhaps the implementation exposed a tension or contradiction between concepts that was not evident during the design process. Or, perhaps you need to scope down in the interests of time. If so, how does this change affect the case you made for your app in P1: Impact Case?

  3. Plan for User Tests. Ahead of next week’s final release, we will ask you to test your deployed app with three different users. Begin planning for that now, following the process we laid out with A6:

    1. Select and Schedule your Participants. Ideally, your participants span a diverse set of your app’s intended audience, but they may be anyone of your choosing—the only limitation is that they cannot be currently taking 6.1040. Each test should last approximately one hour, comprising a period where your participant works through a series of tasks you have set them, and then a portion to debrief them about their experience.

    2. Prepopulate Realistic Data. Richly populate your app with a diverse range of data to give users a vibrant impression of what it would be like to use your app at the peak of its usage and popularity.

    3. Formulate a Task List. Create a list of tasks that cover the key concepts of your app, focusing on the concepts that are particularly unique or important to your design. Each task should typically involve executing a sequence of user interaction actions. You should include at least 5 tasks, from simple one-action tasks to more complex multi-action tasks, that will test how easily the user can cross the gulfs of execution and evaluation discussed in lecture. You should plan for these tasks to take roughly 40 minutes of your hour session.

      Format your task list as a table, where each row corresponds to a different task and with columns for: (1) a short title for each task; (2) a succinct instruction, in words that could be given to the user; and, (3) a brief rationale for including the task, explaining why the task is worth testing, what you hope to learn or uncover about your design when testing this task with a user versus excuting it yourself as part of a cognitive walkthrough. Order the rows in such a way that any application state required by subsequent tasks has been correctly setup by earlier tasks. And, remember, your instructions shouldn’t describe or explain how a user should accomplish the task.

Submission

By the assignment deadline, post your design revisions and user test plan to each team member’s portfolio, and deploy your beta release to a publicly accessible URL.

Then, submit this Google form once for the whole team.

Grading

Note: we will be grading functionality and usability primarily on a check-off basis. If you have implemented the core functionality of your design, and produced a frontend that does not have any glaring usability flaws (i.e., the Satisfactory column of the Functionality and Usability rows of the rubric below), you will receive full credit for these rows of the rubric. We will grade the quality of your implementation as part of next week’s final build.

Component Excellent Satisfactory Poor
Functionality (check-off) - The app supports the core functionality described by the operational principles of the concept designs in light of the design revisions. Some minor actions or other parts are missing. App is largely reactive, but occasionally requires a page refresh. Some key functionality remains missing or is sufficiently incomplete to hinder user testing. App is hardly reactive, requiring several page refreshes.
Usability (check-off) - Visual and interaction design largely provides an intuitive user experience, without any issues that could have been caught through lightweight self-evaluation (e.g., cognitive walkthroughs or heuristic evaluation). Visual or interaction design yields an app that is difficult or frustrating to use in ways that can be anticipated without user testing.
Prepopulated Data The deployed app is richly populated with realistic data that gives a vivid impression of real-world usage. The app is populated with plausible data, but this data is relatively terse or shallow in a way that hinders an impression of realistic use. Deployed app contains several instances of dummy data or placeholder text that makes it look like a prototype or toy.
Task List Task list exhaustively covers the key aspects of the application. Rationales are well-justified, succinctly but compellingly describing how insights might differ from cognitive walkthroughs. Task list covers a broad range of functionality and complexity. Rationales begin to offer some initial justification but could go further in hypothesizing insights that could be gained from having real participants perform the tasks (vs. heuristics/cognitive walkthroughs/etc.). Task list misses important functionality, or spans only a limited a range of complexity. Rationales poorly justify why it is necessary for a user to be performing these tasks.