A5: Skeleton and a plan Team submission

This assignment evaluates whether we are straying from the high-level vision of our studio brief. Recognize how proper chronological planning helps prioritize tasks and clarify the roles of team members, keeping us focused and preventing “scope creep.” Learn to classify essential vs. non-essential functionality. Balance the low-cost fidelity of digital wireframes/mockups against time constraints to concretize our idea (for this, we recommend using Adobe XD). Develop a feel for a “flowing” interaction using an html skeleton. Lastly, lay the foundation and make a first online deployment.

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

Optional project starter code (same tech stack as labs): https://github.com/DesignAtLarge/ixd-skeleton

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.

    Revisit the Brief
  1. A few detailed sentences identify your point of view, user base, and core interaction. Have they evolved? If so, how and why? Hint: "Anyone" is not a specific user group; "people who want to exercise" is also too vague.
  2. A few detailed sentences summarize how they align with your studio brief & user need. Clearly demonstrate who the user is, a specific usage situation, and the user's motivations for using the interface. Hint: Look back at A3.

    3. Development Plan
  3. Create a column on a spreadsheet listing at least 12 actionable steps per person in your group necessary to complete the entirety of your app development, with future assignments as a rough guide.
  4. In four adjacent columns, assign realistic time estimates, a deadline, an “owner” responsible for completing each task, and identify tasks involving essential vs. non-essential functionality by assigning “high, medium, low” priority. Internally verify the prioritization is accurate, write justifications in a comments column, if needed, and identify potential obstacles or outside constraints, e.g. midterms, in the same column. Include a sum of the expected and actual number of hours for each teammate.

    5. Wireframes (can have color)
  5. A digital (non-functional) wireframe/mockup of your mobile main content screen (no login or splash screens). Leave out minor details and styling
  6. A digital (non-functional) wireframe/mockup of your next highest priority screen (no login or splash screens). Leave out minor details and styling
  7. Presents all potential interactions (text, visuals, buttons, and other widgets) for both your main content screen and second wireframes
  8. Content of both wireframes should be specific and not placeholders (eg. Lorem Ipsum)

    9. Screens (no color)
  9. Grayscale screens in HTML and CSS. The reason to omit color at this stage is to focus on the other visual tools available to you: scale, relationships, spacing, layout, etc. Once you get those right, then you can add color. There is no need to make image assets grayscale. Grayscale refers to CSS.
  10. Create a GitHub repo for filesharing and source control. Deploy your prototype online (e.g., in Heroku). Submit clickable (or easily typed) links to your Github repo and Heroku site; make sure the grader has access.
  11. Based on the wireframe, use the content in the labs to code up a semi-functional main content screen. Include all content/buttons/text boxes/functions sketched out in the main content screen wireframe
  12. Link all interactive functions on the main content screen and second screen to placeholder html pages where applicable
  13. Based on the wireframe, use the content in the labs to code up a semi-functional second screen, linking to the html skeleton where applicable. Include all content/buttons/text boxes/functions sketched out in the second screen wireframe

Please submit a single PDF file with:

  • Revised brief
  • Link to development plan
  • Wireframes
  • Link to screens (GitHub and deployed app)

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.

Development Plan Example: (1)

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

Wireframe Examples: (1) (2) (3)

Skeleton Example: (1)