Quick access to the sections of this document:
This term you will undertake a group project (typically, 4 people) to evaluate some computing-related task/problem, to develop interface design alternatives for the task/problem, to implement a prototype of your design, and to evaluate your design. This project should provide you with hands-on experience with the tasks that interface designers face every day. Ideally, the topic of the project will be a problem that matters to some "real-life" people.
Theme: In order to provide some unity and shared understanding across the project teams, there will be an overall theme for the projects. See the Home Page for more on the theme for this semester. Think broadly about the theme. This is your problem space for the semester-long team project.
Each project group will be graded as a team, that is, each person receives the same grade. I will poll team members, however, to make sure that all members are contributing. Lack of participation may precipitate an individual reduction of grade. Within the team, you must negotiate on how much and what each person will contribute. Think carefully about your team members: Where do people live and what hours do they work? Where will you meet? What skills do the different individuals bring to the group (computing, programming, design, evaluation, statistics, etc.)? I would strongly encourage you to form a heterogeneous team full of individuals with varying skills.
Each part of the project will include a deliverable report. This report will be submitted in an electronic format (PDF). Portions of the report will be submitted at each stage of the project (D1, D2, etc.). You will only submit the relevant portion of the document at each phase. For example, for D3, you will not need to re-submit D1 or D2. At the end of the semester, however, the complete report, including all the sections, will be handed in. This should feel like a complete, unified report, and not a bunch of disjointed pieces. Make sure it flows together. The format of the reports for the individual parts is ultimately up to your team, but there will be templates for the sections, to help your team know what to expect, and what is expected. In any case, it should be professionally prepared, concise yet expressive, grammatically sound, illustrative of your efforts and process, and easy to view and understand. A good design effort can easily be hampered by a poor communication of what was done.
Due date: See class schedule
This first part of the project is relatively simple. On the WIKI page for the class, you must provide your TEAM NAME, list
the members of your team, and identify the problem area that you will be
working on. At this stage, focus on (1) USERS who are (2) trying to accomplish some TASK. Or users who have identified some problem that they could use some help with.
For example, "single parents who are trying to do grocery shopping". This stage should be more detailed than "people shopping", but not as detailed as "single female parents between ages 25-35 living in urban cities with 2-4 children under the age of 7 who are trying to shop for groceries while also managing a budget."
You will soon have to zoom in and get more detailed, but for now, seek a middle level of detail in the user group and the problem space. A note about the team name: make it generic, or at least not about the topic, since you may very well change topics, but not teams.
Team Contract. In addition to identifying the (multiply-diverse) members of your team (via the WIKI), you need to determine how your team will function. A Team Contract document will help you establish when/where/how you will meet, what roles and responsibilities each team member will have (for each project; roles may differ across projects), expectations for participation, tools you will use, decision-making and dispute-resolving process, etc. Your team contract document can take any form, and you will decide (as a team) what to include...but it must list your team name and team members (copy from the WIKI if you want), along with any other team contract content. Suggested content is discussed in class, in the lecture on Team Science. You must upload a copy of your team contract (via a Canvas assignment) by the deadline for D0. See class schedule.
Due date: See class schedule
The key goal of this first substantive part of the project is to
deeply understand that problem space that you are addressing, its set of
pertinent users, and the issues and constraints that are involved in
the problem. If the task has an existing system/interface, you should
perform an interpretive evaluation of that system to help you learn
more about it. Most important is to identify important characteristics
of the problem that will influence your subsequent design.
In class and in the readings you will learn about different techniques for acquiring this kind of information. Feel free to utilize the techniques that you feel are most appropriate to the particular task you are examining. Your report and deliverable for this part should deeply examine the problem of study. Who are the potential users? What tasks do they seek to perform? What functionality should the system provide? Basically, you are setting up a set of constraints for your subsequent design. What criteria should be used to judge if your design is a success or not?
More specifically, you should develop the following items in this
part, and you should communicate them through your report:
The last item in the list above is critical. Don't just describe the target users, tasks, environment, etc. You must also tell us how these attributes should/will influence your design. What hypotheses have you entertained? What data or evidence have you gathered to assess those hypotheses? And what conclusions or inferences do you draw from all of that work? We will be very careful to look for this information in your report. We will also be very careful to look for evidence that your eventual design (2+ months from now!) has consideration of the evidence you have collected. Evidence-based design, remember...?
Due date: See class schedule
The key goal of Part 2 of the project is to use the knowledge gained
in Part 1, as well as that from class, to develop a set of design
alternatives for your problem. This is the stage of "informed brainstorming". These multiple design alternatives
should explore the potantial design space for the problem.
In this part of the project you will develop mock-ups, storyboards, and sketches of your interface designs. That is, you should provide pencil-and-paper or electronic images of the interface at various stages; you do not need to build a working prototype. Your design sketches should be sufficiently detailed for a potential user to provide useful feedback about the design, however. Along with your design mock-ups, you should provide a brief narrative walk-through of how the system will work. Perhaps most importantly, you should also include your justifications for why design decisions were made, and what you consider to be the relative strengths and weaknesses of your different designs.
The design process you follow here is important. Don't do the following: The group splits up and everyone creates one design, then these are all your alternatives to be turned in. This is not how a good, creative design process should work. It should be more like a brainstorming session with all team members present. You should seek to create some fundamentally different design ideas, concepts all over the potential design space for the problem you have chosen. The key is to push the boundaries of the space of design possibilities.
Your project report should include all the explanatory material mentioned above as well as all the design sketches, drafts, storyboards, etc., that you generated. If some of your sketches are on paper, either scan or photograph the material and convert it to an appropriate electronic format. Make sure that your report adequately reflects the design process that your group undertook. The key in this part of the project is to come up with many different design ideas, not just a small set of wiggles from some basic design. You should plan on turning in at least three different designs.
For Fall 2019, there will be a POSTER SESSION at the end of Part 2, near midterm. We will utilize one full class day for the poster session. Each group will post some of their design ideas on a poster in class (or in a larger room elsewhere on campus). Everyone will then circulate and interact with the designers. The idea here is that each group can use this opportunity to get feedback about their design ideas as they narrow their design space and head into Part 3 of the project.
Note: There will ALSO be a one-day poster session at the end of the semester (see below, and see the schedule).
Due date: See class schedule
In part 3 of the project, your group will implement a detailed
prototype of your interface.
You can use any prototyping tools that you would like to assist this process
(including software, web tools, app prototyping kits, electronic components, clay, paper, plastic, etc.). You should
be able to get much of the interface functionality working, but
clearly you will not be able to implement all back-end application
functionality.
Additionally, you must provide a set of initial usability specifications for your system and a complete plan for an evaluation of it. To develop usability specifications, consider the objectives of your design. For example, if you are working on a calendar manager, you might specify time limits in which you expect a user to be able to schedule or modify an appointment, or a maximum number of errors that you expect to occur. Basically, you should list a set of criteria by which your interface can be evaluated.
For the evaluation plan, answer questions like, What kinds of benchmark tasks would you have users perform to help evaluate the interface? What kind of subjective questionnaire would you deploy to have a user critique the interface? this is intended to be the evaluation plan for a full, proper, formal evaluation. Note that you will not have time to complete the full evaluation; that's not the focus on this class. However, in D4, you WILL conduct an evaluation of your team's project--it will simply be a "discount" evaluation, leveraging the other students in the class.
Note that developing a complete evaluation plan is also a good way to figure out how much of the interface you need to develop. You should be able to build and connect enough of the application functionality to be able to conduct an initial usability evaluation with the benchmark tasks as you are proposing here.
Your write-up for this part should include a description of your system prototype. You can include screen grabs to help explain it and text to describe how a user would interact with it. Discuss the implementation challenges you faced. Were there aspects that you wanted to build but were unable to do so? The key component to include in your project report is a justification of why you settled on the design that you chose. What's special about this particular design with respect your problem?
The report for this part also must include the usability specifications that you established and a description of the evaluation that you are planning. Saying it again: The evaluation plan you lay out in D3 is what you *would* do (and why and how). What you actually complete in D4 will be much more constrained.
After this part is complete, each group will demo their system in a Poster Session.
Due date: See class schedule
In the final part of the project, your group will conduct an
evaluation of the prototype developed in Part 3. This will not involve the full evaluation that you laid out in D3. Rather, it will involve a "discount" evaluation using other class members.
You may still be able to leverage the evaluation materials (questionnaires, benchmark tasks, etc.) that you developed in D3, but this will be a reduced evaluation effort.
Your write-up for this part should include the following components:
The key to this part of the project is not to simply describe your evaluation methodology but to rise above that and describe what you learned from it. Remember, no designer ever gets a system "just right." We will reward teams who honestly and carefully assess their design and who clearly provide a plan for its iterative improvement.
Near the end of D2 and D4
The design and prototype effort will culminate in a poster session (1 day; 3 hours long) in which each group
presents their system to the class, and to visitors (e.g., HCI faculty and students). Each group
will be expected to have a poster, a system demo (if possible and appropriate), and be prepared to give a polished 3-minute "elevator pitch" summary and
walk-through of their design and prototype (that is NOT a lot of time!). It is important that you
do a good job communicating all your efforts for the semester, and interact with the poster viewers, engaging them and answering questions. You
want to make sure that your objectives in the project are discussed,
your system is clearly presented, and that your design process is
communicated. Practice your presentation! This is very useful for the real world, in which it is often the "elevator pitch" that catches someone's attention, and interest in your project.
There will be a second poster session on the last day of classes. Note that there may also be people from the various Georgia Tech venture labs and incubators--the people that can recognize a commercially viable idea and help shepherd it to market! Nearly every year there is at least one project team that ends up taking their project out into the market, in one way or another. So be prepared to pitch! And be ready to answer questions about potential markets and users and even business models. This can be very exciting!
To help provide your team with an additional source of advice and feedback on your project, as you proceed through the stages you will have access to Project Advice Panels. These panels will be composed of 2-3 second year MS-HCI students (and possibly other experts). You will meet with a panel about 2 times during the semester. Your team will be responsible for finding a one-hour timeslot to meet during that week, when the majority of your team members, and all of the panel members can attend. Identify one of your team members to be the panel liaison, who will interact with the liaison from each panel. Note that each time you have a panel meeting, it may be with a different panel.
Every time you meet with a panel, you will have already been working on that phase of the project for a week, so you will go into the meeting prepared with ideas and plans for what you will be doing in the rest of that phase of the project. You will quickly bring the panel up to speed on your users, their needs/challenges, and how you have been/will be proceeding. Then you will have the rest of the hour to interact with the panelists, ask questions, get suggestions, advice, etc. You must spend one hour (not substantially more or less) with the panel, in each of the three sessions. Reminder: the panelists will typically change each time, so you are not being mentored throughout the project by a set panel. This also means that you will need to quickly bring each new panel up to speed, describe what you have done so far, and then get into the discussion about the next phase(s) of the project as quickly as possible.
The exact composition of the panels will be determined by the second years, as part of their participation in the MS-HCI Seminar class. Panel assignments may include some combination of random and strategic distribution. All second year students will participate, though their involvement will only be a total of 1-3 one-hour panel meetings. Panelist may not actually contribute to your project. That is, they cannot program or design, or serve as participants. They can only provide suggestions or advice or thoughts or feedback, during that one-hour session.