Review the feedback you got last week from the Heuristic Evaluations of your prototypes. 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.
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, when, 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 can be easily verified: it should be concrete enough for your peers to 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. 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.
Create a home screen with a full set of navigational links, and flesh out two additional major screens. The remaining screens can be placeholders; the goal is to get a navigational skeleton up there that someone can click around and get a good feel of the application's flow. Make sure that if you have a button or icon, it links to something, whether it’s an implemented page or simply a holding page. You will fill in the blanks and flesh out the details later. You're of course welcome to get more done this week.
You can use the HTML, CSS, Bootstrap, and Javascript skills you've learned in lab. You're also welcome to design your screens graphically; we recommend Webflow. Say, for example, your project was this course site. For A5, you might mak the home page, the submission page, and the logistics page. For A5, You could have empty, dummy stub pages for the other things that the nav links to. You'll flesh those out in A6/7. Using your lab skills, share your project through github so that everyone can access it.
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. 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.
Here is an example of a pretty good plan (except that it's missing time estimates). Here is an example of a mediocre plan.
During studio, click here to assess your group's work as a collective unit. During studio, click here to assess your own work and each of your team member's work.
| Category | Nope | Weak | Proficient | Mastery |
|---|---|---|---|---|
| List of Changes 3 points |
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; 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; 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. |
| Development Plan 3 points |
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, and takes into account time for unforeseen issues. |
| Home Screen & Key Screens 3 points |
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. |
| Navigational Skeleton 3 points |
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. |
Outside the Box +1. Up to 5% of 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. | |||