|
Expected work for the HCI projectYou have to cover all the stages of the development process seen in the lectures. Keep in mind that we do not ask you to implement a complete and fully functional system (you don't have enough time for this). A functional core, for example, is not required: you use simulated data to experiment with your HCI. Even for the HCI part, you don't have to cover the totality of the application. Instead, you select a sub-part of the application, but you do a complete work (analysis, design, prototyping, evaluation) on this sub-part. In order to choose the sub-part of the application, you need to imagine, right from the beginning, the user study that will allow the evaluation of the most interesting aspects of your application. Analysis stageObjectivesAt the end of the analysis stage, you return the "Requirements Document (RD)", which is used in the evaluation of the project. The analysis stage allows you to present your view of the problem. This stage is fundamental because all subsequent stages rely on the analysis. A flaw in the analysis may have consequences on the final prototype of the system. The field studyIn order to analyze the problem, you must dig the information thanks to a field study. During this study, you observe potential users of your system in order to deeply understand the target public (age, expertise, specifics) and their work environment (noisy? mobile? wearing gloves?). The study must include a detailed observation of the activity: what are the tasks that are performed (functional requirements) and how can these tasks be qualified in term of frequency, risk, or required expertise (non functional requirements). If the observed activity involves pre-existing interactive systems, you must carefully observe how these systems are used to identify their strengths and limits. During the field study, you talk with potential users and other people who are relevant to the project. They inform you about the services that would make your system highly beneficial. This is not about submitting prototypes of the system and asking for a validation: at this stage, you don't have a prototype because you are not sure about the scope of the system and its required attributes. Be open to new ideas that go beyond your initial view of the problem. Write down problem scenarios, which will lead to solutions that you did not think about. Prepare questionnaires to focus the discussion and to avoid forgetting to ask specific questions that you have, but let the participants express their ideas on the problem. It is what they say that will bring the true benefits of your system. Content of the Requirements Document (RD)The field study allows you to harvest the information on which you found the analysis that you report in the RD. The RD has a maximum of 5 pages, not counting the appendice (A4 page format, 12 point font). You must include in appendices of the RD all forms of archives of this field study: verbatim accounts of interviews, observation reports, audio and video recordings (as links). You will refer to these appendices in the body of the RD, which present your analysis of this field study. Your analysis must include:
Finally, the RD must include commitments that you will evaluate at the end of the project. These must be accurately defined. Committing to a "usable" system is not enough: make measurable commitments such as the scope of offered functions, task accomplishment time, or tolerable error rates. Design stageAt the end of the design stage, you return the "External Specifications Document (ESD)", which is used in the evaluation of the project. The ESD has a maximum of 5 pages (A4, 12 point font). You must design a Human-Computer Interaction (HCI) that covers the needs identified in the analysis stage. This design work results in a specification of the aspect and the behavior of the interactive system. The specification does not describe the internal structure of the system, hence the external in the name. Depending on the scope of the system, you may have to restrict your initial goals and focus the remainder of the project on a specific part of the HCI. In this case, you should focus on critical parts of the HCI (e.g. frequent tasks, original solution), and justify your choice. The project being a school project, you must also justify your design choices from a human-centered point of view. BEWARE not to be confused by your roles. Do not limit your design because you will be the ones who prototype it. It is better to design a good HCI and only prototype a small part of it rather than being trapped in a simplistic design of limited value, only because it is easier to implement. You can follow the following structure as the outcome of this stage: I-Methodology = Your approach to propose the design and make decisions. i.e. the model, the criteria you used etc. II-Main design decisions = Global decisions that have driven your design a.For getting the right design = high-level global decisions Eg vocal UIs to be hand-free b.For getting the design right = low-level decisions Eg validate-cancel in each window III- External specifications a.Descriptions = The screens + navigation between the screens b.Justifications = Explain for example by considering the task and domain models and the ergonomic criteria IV-Interaction scenarios a.Example 1 b.Example n = The UI in action. You consider scenarios putting the persons in action, and you describe how they are supposed to do and the reactions the system has accordingly. V- Self-assessment = The strengths and limitations of your design. Eg you know that consistency is not perfect at this place but it was the best trade-off. Prototyping stageIn the prototyping stage, you give tangible form to your design. If you have to focus again the scope of the project, favor the most interesting part from a HCI point of view and justify your choice. The time available for the project being very limited, you can use any means available to avoid a lengthy software development approach: you can use prototyping software, presentation software (such as "PowerPoint"), paper prototypes, video montages, etc. However, the prototype must be high fidelity enough to allow an interesting and credible evaluation of your HCI. Evaluation stageYou evaluate the quality of your HCI through user experiments on your prototype. You present your prototype and evaluations during your project defense. The quality of an HCI is its value from a user point of view: is it useful, and usable in user's context? You evaluate this through user experiments. You define an experimental protocol, recruit participants, and have them manipulate your prototype. Participants must be representative of the target audience of your system. They must not be members of the project and, preferably, not member of the course as this may bias their behavior. In general, at least 10 participants are required to get meaningful observations. The experiments should focus particularly on evaluating if your design satisfies the commitments that you wrote at the end of the requirement document (see above |