A7: Ready for testing Team submission

In this assignment, we prepare for user testing by finalizing the development of our app functionality. We continue to apply design heuristics to create an intuitive interaction. We apply templates to streamline our code. We debug. We fit the mobile form factor, but we refrain from focusing on aesthetics so that user testing doesn't nullify any work we have done. We expand the functionality of our app, if possible. We assess our progress by updating our development plan. We address bias and consistency in conducting our user testing by composing a user testing plan. We decide on design choices that are best suited for user testing.

The following rubric items are independently assessed. In general, evaluation works such that if the student/team meets, for instance, 9 out of 10 rubric items, then they have earned a grade of 90%. The assignment will not be graded unless it is submitted on a single, well-formatted, and easily readable PDF.

Evaluation Rubric

Note: if you are a rare group of 2: pursue a dev plan that meets the rubric with a reasonable workload. If you are unable, you may propose an accommodation to this on Piazza; include a link to your dev plan.

    User Testing Plan
  1. 2-3 sentences describe the concrete task(s) that participants should attempt. A concrete task describes a specific goal (book the first flight after your exams from San Diego to Salt Lake City), but not the steps to accomplish it. (For example, "navigate to X on the application" is an interface instruction, not a task.) Task(s) will likely refine your task from A6.
  2. Protocol describes the steps an experimenter will take. This method section is sufficient for another student to read and follow: gain informed consent using this form; exact words facilitator will say (to ensure consistency); 1-2 sentences why task & instructions do not inappropriately bias users.
  3. Three key design questions you hope to illuminate. For each of the three, include a few words about why you chose that question, and how eval gathers information to answer it. (Hint: see lecture 7.) Choose tasks (and debrief questions) to reflect these learning goals.

    4. Complete functionality
  4. 2-3 detailed sentences assess how. If you used a different programming approach than in the labs, explain how you meet rubric items that assess code and functionality
  5. Readiness for users testing: 2-3 detailed sentences justify number of unique workflows or user tasks that your app supports
  6. Include Facebook (or other) login that staff can use.
  7. Read data from JSON. We will search for require...json in your code (or mongodb if using MongoDB). Submission lists file path of your JSON file (or equivalent).
  8. Uses handlebars templates (e.g., #each loops); we will search for "{{" in your code. No obvious duplicated code chunks (e.g., copying and pasting nav).
  9. Utilize routes and jQuery selectors to asynchronously update your app's screens where appropriate. We will search for "$." and ".html" or ".append" in your code
  10. Prototype writes JSON data; we will search your Github for ".put" or ".push". (As our focus is design, you are not required or expected to use a database that persists across runs of node.)
  11. In studio: first-time users can go from screen to screen and know what functions they can perform
  12. Layout (in Chrome responsive mode) appropriate for mobile form factor on a contemporary smartphone.
  13. Layout (size, widget choice, visual design) reflects task structure & POV.

    14. Development Plan
  14. A clickable or easily typed link, or a readable, properly oriented, and complete snapshot of your dev plan. Make sure the grader has access by the deadline. All tasks are actionable, prioritized, assigned an owner, and given a time estimate. In your comments column, identify tasks that were newly added. Includes a sum of the number of hours for each teammate. Outliers should be justified

    15. Deployment and Code
  15. Clickable (or easily typed) link to your app of the form “a7-projectname.herokuapp.com”, and to your project repository on GitHub. Make sure the grader has access by the deadline. If your app is changed before grading is completed, you will earn no credit for the assignment.
  16. Add username ixd@ucsd.edu to your Heroku app as collaborator (Under “Access” tab in app settings).

Examples

Here are some examples from prior years. Note assignments change from year to year, so use these examples as a reference, see where they succeed/breakdown, and make sure your final submissions adhere to the rubric for this year.

User Testing Plans: (1) (2)

Apps: (1)

App Demos (not required for this assignment): (1) (2)

Development plans: (1) (2) (3) (4)

Here is a cool video of the dynamic nature of implementation plans throughout the project.

Here are some examples of feedback that has previously been given on this assignment.