A4: A skeleton and a plan - due Thursday, 10/27, 11:59pm

Assignment

[The workload for the rest of the assignments will ramp up significantly since you will need to start writing code and working toward creating a fully-functional web application. Please plan accordingly and get up to speed on web programming by working through the code labs.]

Step 1: Make a Development Plan

Using a Google spreadsheet, create a development plan for building your interactive app prototype. Provide a detailed plan for the next three assignments (A4, A5, and A6), and briefly summarize goals for the remaining assignments. By the end of A6, you will have a prototype that is interaction-design complete and ready for testing.

Your development plan should show a detailed and comprehensive task list for the next three weeks (A4, A5, A6) and briefly summarize goals for the last three weeks (A7, A8). For each, clearly state what needs to get done, what deadline, and how long you estimate it will take.

Make two task groups: 1) a conservative set that gives you a basic, design-complete application for testing; and 2) a stretch goal that you hope to accomplish. Write your component tasks so they are actionable and can be easily verified. They should be concrete enough for your peers to assess if they have been completed. "Set up results page" is too vague. "Display train times on results page" is better. In addition to basic and necessary tasks, also set stretch goals that you hope to accomplish and outside constraints that could slow your progress (i.e. out of town one weekend, busy with midterms during week 6, job interviews, etc). The exact structure/layout of the plan is up to you; do whatever will be the most clear to readers (such as your TA who will be grading your assignment).

Again, try to make your tasks as specific as possible, and avoid vagueness at all costs. The value of having specific tasks is that they will help remind your team of what exactly needs to be done each week. Tasks such as "Code up a profile page" are not good. Instead, try to write something more specific such as "Display user's username, email, and profile picture on the profile page".

See the Student Examples section for example development plan templates that you can adapt for your own.

Step 2: Wireframes

With your team, create TWO low-fidelity digital wireframes: 1.) the first page of your app, and 2.) an additional page. A low-fidelity wireframe provides the main details about the layout of a screen in your app and the rough information it holds, but leaves out smaller details and styling. You may use PowerPoint, Keynote, or Google Slides to create your wireframe (or use more advanced wireframe/mockup creation software if you like).

In your wireframe, the first page of your app should NOT be a login screen. Assume that the user has already logged in. What does the first page that contains substantial content look like? That is the "home page" you should be designing. It should include suggestions that you found valuable from heuristic evaluators on your paper prototypes (A3).

The second page in your wireframe should illustrate a major screen, displaying the core functionality. The purpose of that screen to give us an idea of how you expect users to interact with it.

For now, you do not need to worry about aesthetics for either screen. These are important to help you organize your app and decide how you would like to implement it in code.

Step 4: Code up Two Screens of Your App

After creating the full skeleton of your app (Step 3), you will create the home page (the first page you created a wireframe for) in HTML/CSS/JavaScript code. Then, you will flesh out one more major screen (the other one you created a wireframe for) by adding in all the details of that screen. Add the content and set up the functionality that will be required on those pages. For example, if the functionality includes an upvote button, you should create the button, though the upvoting functionality does not need to work yet (though you're always encouraged to get extra work done early if you want). Remember, when functionality is peripheral to your web application, you may Wizard of Oz it. See the FAQ for guidance.

Refer back to your labs for HTML, CSS, Bootstrap, and JavaScript help. Lab 1 is also helpful for understanding how to keep good source control habits with your team on GitHub. We recommend that you create a public GitHub repository for your code right now, since in later assignments, you will be required to have a public repository for your TA to grade your code.

Step 5: Revisit the Studio Brief

Write 3-4 sentences summarizing how well your project fits your studio's brief, why, and the specific users you are designing for.

Student Examples

Here are some examples of development plans. If you want, use File -> Make a copy... to copy over the formatting for each spreadsheet to form the basis for your own plan.

  • (1) is very stylized, dynamic, and mostly thorough,
  • (2) is fairly thorough, colorful, but is missing time estimates and has only one stretch goal listed,
  • (3) is a mediocre plan that's mostly thorough, where most tasks are broken down into less than 1 hour chunks,
  • (4) is very thorough, with time estimates and time costs, but some tasks could be more actionable,
  • (5) is a great video of the dynamic nature of implementation plans throughout the project.

What’s this for? A UX agency perspective

The prototype is a very powerful tool, but it can also be a nightmare to implement and demonstrate to a client. Often they will approach it like they would a finished product, and expect every link, every tool and every function to work. If it did....we may as well just build the final product, and it can be hard to find the balance.

Always remember; a prototype is a mock up, it’s to test a solution. Prototypes can be incredibly comprehensive, or very basic - it depends on what you want to test. However, make sure it is clear - using comment bubbles, instructions or tool tips - what functionality you are trying to test.

DON’T tell a user how your application is supposed to work, of course....a good prototype will be intuitive. We have experienced "spot-the-click" with some users, who will simply move their mouse around until the pointer turns to the tell tell finger appego, a working link! Users will often work their way along a navigation bar in a prototype, clicking each button from one end to the other.

Make sure that your application isn’t going to throw an error because you forgot to implement a holding page - make it feel real, even if it’s not! If you have an online store where only one product works for testing purposes, make sure that is clear to your user.

-- Mike Davison, UX Project Manager

Team Submission

For this assignment, ONE person will submit the assignment for their team, listing every team member's name and student ID number (PID) in the assignment submission.

Your write-up will contain the following in one single PDF:

  • A snapshot of your development plan. We recommend making a Google spreadsheet and saving it as a PDF; this gives you a snapshot for easy comparison. Look up tools for joining multiple PDFs into a single one for your submission. Do not send us a link to your live Google spreadsheet, since it will change over time.(Development Plan)
  • An image or working web link to the two wireframes you made (Wireframes)
  • URL of your webpage prototype. Since the key links should create a "full skeleton", your TA should be able to easily find the two fleshed-out pages (home page + one other screen) by testing the key links. Note: the URL must work at least until your assignment is graded. If it doesn't work, you'll receive no credit. Very important: the contents of this URL should not change in the upcoming week while your TA is grading this assignment, or else that is a violation of the academic honesty policy; test your new changes at a different URL. (Skeleton Webpage & 2 Coded-up Screens)
  • A paragraph summarizing the user, task, and how your project meets the studio brief. (Revisit the Studio Brief)

Submit your single formatted PDF in Gradescope.

Evaluation Criteria & Grading Rubric

The rubric below contains criteria that are worth one point each and will be graded independently and in a binary fashion.

  1. Development plan is included in the submitted PDF itself (rather than a link), is easy for your TA to read and understand, lists specific tasks (no credit for tasks that are too vague), who on the team is responsible for each task, and estimated/actual time for the coming weeks.
  2. Wireframes convey the task or goal of the page. Another person can look at the wireframe and understand what function the page will serve.
  3. Wireframes focus on displaying the critical functions of the page rather than styling.
  4. Wireframe #1 includes all the buttons/text boxes/functions necessary to perform its main action on the page, without actually having to be fully functional.
  5. Wireframe #2 includes all the buttons/text boxes/functions necessary to perform its main action on the page, without actually having to be fully functional.
  6. Key links in webpage prototype do not have any dead ends or disconnected parts.
  7. Screen #1 is easily discoverable by following key links (i.e., not deeply hidden in too many layers of links), and is complete in a way that clearly shows users what can be done on that screen.
  8. Screen #1 includes all features or buttons needed to perform all tasks that can be done on that screen.
  9. Screen #2 is easily discoverable by following key links (i.e., not deeply hidden in too many layers of links), and is complete in a way that clearly shows users what can be done on that screen.
  10. Screen #2 includes all features or buttons needed to perform all tasks that can be done on that screen.
  11. "Revisit the studio brief" paragraph clearly connects the project to the studio brief.
  12. "Revisit the studio brief" paragraph has a clear audience of users that the project is designed for.

This course was originally created by Scott Klemmer. This version is modified and taught by Philip Guo. It incorporates revisions by Michael Bernstein, Philip Guo, and many TAs. Instructors: you are welcome to use these materials for your own class, and dozens of courses around the world do. We share all course materials through a CC-BY license. Please let Scott know if you use them, and also any suggestions you have. We thank the UCSD CogSci department for providing our studio space.