Assignment 5: Skeleton and a plan


Step 1: Revisit Heuristic Evaluations

Review and write a list of HE violations from the feedback you got last week. Distill the HE results into a list of concrete changes you want to make to your prototype. Use what worked, and improve what didn't. If you haven't already, make a decision about the prototype you are going with. This could be one of the two you tested or a combination of them. Again, take the time you need. This is what you will be working on for the rest of the course, so make sure you will feel invested in it. Your team may decide to pivot your prototype idea and go in a different direction. Review your studio brief. As you revise your ideas and designs, make sure your project serves a task for a user, and connects to the studio brief.

Step 2: Make a Development Plan

Create a development plan for building your interactive prototype. Provide a detailed and comprehensive plan for the next three weeks (A5-A7: interaction design), and briefly summarize goals for the final three weeks (A8-A10: polish, back end, and testing). By the end of A7, you'll have a prototype that is interaction-design complete and ready for testing. For A7, back-end functionality isn't required. (Though you're of course welcome to include it.) In the final three weeks, you'll implement any needed back-end functionality. Remember, when functionality is peripheral to your application, you may Wizard of Oz it; see the FAQ for guidance.

To be organized and ready for programming, write down all the different components of your prototype. For each component, clearly state what needs to get done, by whom, 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 actually do and assess if it has been completed. "Set up results page" is too vague. "Display train times on results page" is better. Compose your plan in a spreadsheet; we recommend Google spreadsheets because they're easy to share. The exact structure/layout of the plan is up to you; here is a template to get you started. Use File>Make a copy... to copy over the formatting. See the Student Examples section for more. Space out deadlines--don't have everything due Thursday night every week!

Your plan should also list one or two outside constraints. These could include other course projects/exams, work, travel, job interviews, a hot date... whatever's most important for you to account for in the next few weeks. As things evolve, you're welcome to change/update your plan at any time. Each week, you'll submit a PDF snapshot of your plan. Your next week's progress will be measured by whether you completed the goals you set for yourself -- or revised them to something equally or more awesome.

Step 4: Revisit the Brief

Write a paragraph summarizing how your team has used the tools you’ve learned so far to meet your studio’s brief, how well your project fits the brief, and why. Summarize the user and task that you are designing for.

In Studio

When you arrive to studio this week, your studio leader will have your design loaded on a mobile device, plugged into the shared display. You'll use this to present your in-progress design work, then you'll discuss your development plan with your studio.

Looking Ahead

We know that many of you have midterms or major projects this week, so this week's assignment is lighter than the next two. Despite this, we strongly encourage you to use this time to start working on the functionality of your prototype. It is in your own best interests to get started on the functionality as soon as possible.

Some teams may also be pivoting the direction of their projects, and the coding will only get harder later. Now is the opportunity to implement any major changes or reinvisionings to the direction of your projects. Remember you can also spend time needfinding, storyboarding, and paper prototyping, revisiting the previous assignments for inspiration and guidance. There is an extra credit assignment titled "Revisit Inspiration" to motivate this.

Student Examples

Here are some examples of development plans: (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.

Stay tuned for an example of a complete home screen, key screens, and navigational skeleton.

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.

Your Team's Submitted PDF should comprise

  • A list of HE violations
  • A list of changes your team has made and will make to your prototype. (List of Changes)
  • A snapshot of your development plan. We recommend making a Google spreadsheet and saving it as a pdf; this gives you a snapshot for comparison. Do not submit a link. (Development Plan)
  • URL of your prototype. (Home Screen & Key Screens, Navigational Skeleton)
  • A paragraph summarizing the user, task, and how your project meets the studio brief. (Brief Revisit Summary)
Submit your formatted pdf here

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.