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

Dilbert Strip from 1994-09-30

Phase 1.1 due before 11:59pm on February 6th
Phase 1.2 due before 11:59pm on February 13th
Phase 1.3 due before 11:59pm on February 27th


Overview:
This is the general description - there are four specific pre-made project options to make things a bit more manageable, but within each there is much room for each team to shape it in this phase.

There is also a set of hardware rules.

The pre-made options are a kiosk for the Iribe Center and a "Kitchen Kompanion" app centered on a home's refrigerator and other kitchen concerns. and an integrated Health-themed Mobile App and a tablet advising app for Computer Science majors.

Teams are expected to have 4 students and have to pick one of these options. More details about the options can be discussed in class.



The overall purpose of this phase is to give you experience at:
    * articulating a proposal for a project
    * communicating with potential users about their needs
    * exploring related technologies and conventions but not limiting yourself to them
    * constructing and conveying good task descriptions
    * constructing and conveying good sample user personas
    * using the task descriptions to decide upon system requirements,
    * brainstorming low fidelity prototypes based upon the above, and
    * evaluating the ideas and prototypes with potential users


In Phase 1.1 you will form your teams around a project option and submit an initial "pitch-back" 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 that are somewhat generic yet provide example details. Rather than "My photography 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."

You should also make a tentative decision on the development platform and then work on Homework #2 individually using that platform.

This sub-phase will be due before 11:59pm on February 6th


As the Phase 1.1 submissions 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, building 2 to 3 example user personas and writing up 4 to 6 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. A PDF containing these personas and task scenarios will be the deliverable in this sub-phase.

You will be expected to speak with some example potential users and/or stakeholders of your system during this sub-phase. In your write-up, indicate the type of people you spoke with (for example "a junior who is a female CS major who lives in a quad apt with a single refrigerator") and whether they inspired any of your scenarios or personas. Also, indicate why you chose it as an important scenario example. At least 2 of the full task scenarios that you include must be inspired by example potential users and/or stakeholders.

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. Additionally, the underlying infrastructure of software is often shaped by the design of the user interface and experience, which is why we undertake this design work the way that we do in this course. Lewis and Rieman wrote of HCI, "It just won't work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter." 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 before 11:59pm on February 13th


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. While these paper prototypes do not need to be perfect, they do need to demonstrate thought and care and an eye towards realistic elements. 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.

You should have at least three screens prototyped. These need to demonstrate three distinct, representative features that your final product will have. At least one, though preferably more, need to show thinking about non-trivial interactions the user will have with your final prototype (ie: think data entry).

Each team will need to virtually meet with their TA "senior manager" during the week of TBA to discuss their progress and post any artifacts that have been created in their team channel on Slack. During these meetings, the TA may offer ideas and suggestions based on what you show them. They might point out an important element that they feel is required for the current stage. With the exam being in the same week, this semester we will offer you the opportunity to upload your low-fidelity artifacts as they exist by February 22nd to your team channel on Slack if you would like any quick feedback on where your team is so far. However, this optional feedback opportunity is not to detail everything that should be done, since discovering this is part of your work, and different teams might choose to focus on different approaches or audiences depending on the option. If in great doubt, arrange to meet with me with some well-developed questions, and I'll be happy to provide my input.

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
    * a 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
    * a list of primary features and of secondary features that you imagine the final product would have.
    * a preliminary style guide (color palette, typography, iconography, buttons, pop-ups, etc) - this is something that will evolve as you move forward in the phase, but having one at this point should help you start on a thoughtful path

You can see an example of how you could express your style guide here, but please note that the actual style choices it shows are BAD one. Your style guide should show good style choices.

When we ask for a prioritized list of system requirements above, we primarily mean a list of things that people will be able to accomplish/do/experience via what you are designing (not things like screen resolutions).

Your PDF will contain photos of the low fidelity prototype(s) the team created (you will keep the actual paper prototypes to potentially show others, probably by pointing a webcam at them during a videochat).

You will also need to submit a public "who did what" one page summary of who in the group did what in this phase.

This sub-phase low-fidelity prototype bundle will be due before 11:59pm on February 27th


Important Mindset Notes
As your team works through this phase, please keep in mind that this semester-long project is more than "just a coding project." You are starting from an idea with goals and a context and are designing and expanding from there. In this phase you will delve into the larger context and things such as understanding and expanding on your specific posted option, identifying the likely categories of target users of the end product and getting to understand more about their needs and abilities and contexts, constraints presented by the posted option's details, and shaping your design ideas based on these understandings.

As part of your design thinking, you will likely need to consider things like user distance to screen, needs such as supporting users who do not have 20/20 vision, many aspects of the diversity of your users, as well as both visual and tactile interactions with all options using touchscreens.

In this phase, be sure to keep the platform of your option solid in your mind (smartphone app or lobby kiosk on a large touchscreen) and do not allow your eventual Phase 2 development platform to skew your overall design here. For example, even if your team has decided to use HTML/CSS/Javascript to have your Phase 2 prototype "live" in a Chrome browser, you are not designing a webpage/site (that would involve very different metaphors, constraints, etc). You would do best to undertake your entire Phase 1 without assuming that you will be using a browser when you implement the interactive prototype in Phase 2 (even if in the end that's what you use) to avoid thinking about things as they might appear or behave if done as a website.

As you work on your design, please keep in mind that you cannot "farm" elements out to existing services. As some examples, shopping lists in the Kitchen Kompanion cannot be handled by an external resource such as Amazon shopping, the Iribe Kiosk and CS Advising app cannot embed any CS or external campus resources as interactive features, and the Health app cannot redirect the user to existing sites for videos or health information.

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 6 of the 40 percentage points that the team project makes of the semester grade.















Web Accessibility