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.
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. 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.
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.
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.
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.
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.
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.
|List of Changes
|No changes or completely irrelevant changes.||The student only identified a few changes from the heuristic evaluation feedback and a large amount of feedback is ignored in the prototype without justification; or the changes would introduce some HE violations.||Many of the simpler suggested changes were made, but some of the more complex or difficult issues were not addressed without justification; the changes would not introduce any obvious HE violations.||Made several thoughtful and specific changes based on the heuristic evaluation feedback. Few, if any, HE violations remain.|
|No development plan or development plan without deadlines.||The student's development plan does not address every step of development and does not create clear actionable tasks. The timeline seems haphazard and the deadlines are obviously impossible to follow.||The development plan has several reasonable steps for development, but they are not clearly defined or do not cover all aspects of development. The timeline is well-organized and mostly doable, although a few of the deadlines seem idealistic or unreasonable.||The development plan has many distinct, logical steps that give a clear path for development. The timeline is well-organized, has feasible deadlines, has an owner assigned, and takes into account time for unforeseen issues.|
|Home Screen & Key Screens
|No home screen or additional screens.||Home screen has little content. Only one additional screen fleshed out.||The home screen and two additional screens appear to have most of their content.||Home screen and two additional screens are very thorough.|
|No navigational skeleton.||Navigation does not work.||The major navigations are present.||Navigational skeleton is very thorough and well planned. It gives a real feel for the flow of the application and is clearly thought through.|
|Revisit the Brief
|No paragraph submitted.||Paragraph doesn't clearly explain the user, task, and/or relationship of the project to the brief.||The paragraph is written with insight, and changes to the project were made to reflect these insights if necessary.||The paragraph is a thoughtful reflection of the project’s trajectory so far, and how it has fit into the brief. The project meets the brief's constraints well.|
Outside the Box
+1. Reserved for unusually impressive submissions.
|The changes based on the heuristic evaluation are not only insightful and specific, but show creativity and thought in the changes that are made. These changes do not just change the prototype in the most obvious manner to get rid of the HE violation, but reflect careful design to avoid HE violations in the future.|