CMSC 434 - Phase #1 - Spring 2017
Task/User-Centered Design and Prototyping

Overview:
This is the general description - there are multiple specific pre-made project options: [ A, B, C, D ], one semi-custom option on a location-aware app where you propose a way to shape it, and one totally custom project option from which you will choose as well as a set of hardware rules.

If you select one of the custom options, you should contact me to discuss it by February 2nd.

In Phase 1.1 you will form your teams around a project option (either one of the posted options or a team-created one that will need to be approved) and submit an initial "pitch-back" or "pitch" where each team will describe (in two pages or less) their project as they see it, including its overall audience and overall goals, all presented in the team's own words. For the goals, you should be able to describe at least three primary goals, and potentially more (and/or some secondary goals). You will need to express why your team feels the application is needed (ie: what need or hole in the market would it fill). You will need to be able to provide a list of types of users of your system. Rather than "My photograph friend Sam." we want to see things like "An avid freelance photojournalist who wishes there was a way to add more credibility to his photography."

This sub-phase will be due by class time on February 7th

As the Phase 1.1 submission are being reviewed, you will begin work on Phase 1.2 where you continue to think about your project option, potentially updating the pitch, but most importantly investigating your users and their needs more, and writing up 5 to 7 full task scenarios (we will discuss what these are in class) that you envision represent some of the situations in which people will use your system. You will be expected to speak with some example potential users and/or stakeholders of your system during this sub-phase. This phase of the project is a hands-on exercise on project ideation and task-centered design and prototyping, which is the first step in an iterative user-centered system design. Fundamentally, this means that you begin your design around a concept by getting to know the intended users, their tasks, and the working context of their actions. Only then do you consider what the actual system's design should look like, basing the design on real people, real tasks, and real needs. User centered system design is not an academic process where some cookbook formula can be applied. There are research-based and practice-based techniques that you will apply, but it will be important not to approach things with a "checklist" mentality. It is also not typically an "intuitive" process where a programmer will sit in their office and imagine who the user will be and what their tasks might be. Rather, it is a hands-on process that requires you to go out and identify actual potential users, talk with them about what tasks they are trying to do or wish they could accomplish, and understand the entire context of their work. You then base your designs on this information. As you are working through this design process you will work to identify potential usability problems by continually evaluating your design and by crafting new designs. This is called iterative design.

This sub-phase will be due by class time on February 14th.

With this more complete view of your project, phase 1.3 will have each team work and create a set of paper prototypes reflecting several rapid iterations on their ideas, the team's brainstorming on how to support the users, as well as ideas from some of the example potential users you show these prototypes. In this sub-phase, you will begin your iterative design of your system, continuing to talk with people and showing them your low fidelity prototypes. Your task scenarios might need to be updated as you learn more during these iterations. You will be continuing from this design in phase 2, so it is important to do this phase well. The project option descriptions attempt to discuss things in a realistic, full-application manner. When we get to phase 2 we will discuss things such as what parts of the back-end can and should be simplified or even which tasks or interactive elements might be too complex to implement in the next phase. However, for this phase we want to focus on what the software should look like in an ideal current world.

The outcomes of this user and task-centered prototyping phase is a design portfolio containing:
    * an updated list (if needed) describing the expected users of the system and their work contexts
    * an list (if needed) of actual, representative tasks that people are expected to do
    * a prioritized list of system requirements
    * a low fidelity prototype
    * a brief (one to two page) discussion of the user feedback about your prototype

This sub-phase low-fidelity prototype bundle will be due by class time on February 28th.

Important Mindset Note
We are not looking to design simple HTML pages in this course or to limit ourselves to what easily fits inside a browser. For this reason, the default rule for your project is that your UI may not be browser-based unless at the end of Phase 1 you can explain why/how all of the desired tasks and the visual prototype make the most sense within a browser in the form of a formal request to use a browser as your client for phase 2 (but please be prepared for the possibility that this request could be denied). Basically, you should undertake your entire phase 1 assuming that you will not be using a browser when you build this application in phase 2.

Grading Note
Grading will be based upon things such as the sophistication and maturity of the work, the elegance of the designs and how they reflect real users and tasks, the logic of the written presentations, and the completeness of the work. The elements of this phase will be worth 9 of the 40 percentage points that the team project makes of the semester grade.