Website

Design and implement a website for your topic and evaluation documents. Recall that a website is a domain of HCI and your site will be evaluated accordingly. The website does not need to be elaborate, but it should serve the purpose of the users of your website. Users of your website are me (the instructor) the undergraduate students and the scientists. We use the web site to track the evaluations of the group applications. Undergraduate students will provide design documents for you to evaluate. When I or the scientists review your evaluations, we will want to refer to the undergraduate design documents, so your website should have links to their documents on a per evaluation basis. Undergraduate students are also users of your web site. They will refer to your web site to find your evaluation of their design, which they need to refine their design. Consequently your evaluation documents must be posted timely and kept current. All documents should be linked in your website in a format readable by all web browsers. Initially, the website will include a home page with your name, topic name and contact information. The initial website will also contain the interaction design supporting documents, (described below).  The documents are to be posted online by the due date.  The documents do not have to be a single file, but they should be recognized as a group and easily navigated in the website.

You may use most any tool or templates that you’d like to make your website. It should be a static website, meaning made up of html, jpg and pdf documents. There should not be a database backend. Consequently, something like WordPress would NOT be appropriate. The website should not have redirection, meaning in a .htaccess file. I have two goals for the website:

1. A central location to store your design documents that I can zip and save for posterity.
2. A media for sharing your documents with your client and team.

I do not expect anything elaborate in these websites in terms of styling or design. Your design for the website should pay attention to ease of access and finding documents.

Design Supporting Documents

The goals of this assignment are to assure that your undergraduate group clearly understands the stakeholders, their goals and the tasks to achieve these goals. The document should contain:

1. Stakeholder Analysis
   1. Onion model of stakeholder
   2. Description of each stakeholder
   3. Stakeholders’ goal-influence table
2. Personas for the primary stakeholder (primary and secondary users)
   1. Two primary users
   2. Two secondary user
3. Simplified Hierarchical Task Analysis
4. Your notes from the interview with the scientist

You will attend your group’s interviews with the scientist and keep your own notes. You can ask questions during the interview but let the undergraduate group conduct the interview.

Stakeholder Analysis

Onion Model for Stakeholders

Read Understanding Projects Sociology by Modeling Stakeholders for a brief description of the onion model of stakeholders. The onion model only need delineate four levels: system, primary, secondary, and tertiary stakeholders. Primary stakeholders are eventual end users of your system. Secondary stakeholders directly support the primary users or use the results of the application. Tertiary stakeholders are from the greater society and have influence on the project or are affected by the project. Developers of the projects are example of tertiary stakeholders, but developers have different roles.

Stakeholders’ Goal-Influence Table

The Stakeholders’ Goal-Influence Table clarifies the role of each stakeholder by delineating their goal and potential influence on the project. Stakeholder goal represent what the stakeholder hopes to get out of the project (which can be a personal goal). Stakeholder influences are contributions or constraints that the stakeholder makes to or on the project.  Stakeholders may have more than one goal or influence. Generally, stakeholder goals have corresponding influence associated with them and visa-versa.  Stakeholder goals and influences can be represented in a table. Each row represents a stakeholder, and three columns represent: the stakeholder’s generic name (role in the onion diagram), stakeholder’s goals and any associated influences. The association of goals with influences may not always be obvious, but try to find them.

Personas

Personas help to make the potential application users come to life by describing a hypothetical user in detail. The designers can use the personas to test the application on paper by imagining how a specific user would perform. Your document should include four personas: two for both primary and two for secondary users. I suggest that one persona be designed to represent user that will have nominal interactions with the application and the other that will introduce errors using the application.

Persona Documentation

Documenting the person should include:

1. Name, a hypothetical name that you make up.
2. List of important attribute, for example age and residence
3. Description, a verbal description which should include the persona’s
   1. Goals
   2. Behavior
   3. Relationship to other people

Simplified Hierarchical Task Analysis

A complete hierarchical task analysis (HTA) diagrams the different uses of the application in a tree, where the higher level are more associated with goal, intermediate levels represent the tasks to achieve these goals, and the lower levels represent actions to perform the tasks. Links in the tree associate tasks with goals, and actions with tasks. A complete HTA can consume lots of time and paper. I suggest making a simplified HTA which dispenses with links and uses intended tabs to represent the hierarchy.  The intent of the simplified HTA is to represent the views of the application by the different indentation levels. A single indentation level may represent more than one view. Try to represent all the views. In other words, the simplified HTA still represents all the uses of the applications but does not attempt to diagram the actions. You may need to use several indentation tables for application goals that have little in common. I suggest using a top-down approach to develop the simplified HTA. First list all the major goals or tasks of the application, then indent and list the sub-tasks to achieve the corresponding goal or task. Try to name the tasks and sub-tasks with words that might be used in the application view.

Document Outline and Format

Post your assignment document on your website. Do not email them to me. I will view your website after the assignment due in order review your assignments. The document will contain tables and bullet lists, but they should be supported by full sentence description. The document is not an outline or a note. I will evaluate the correctness of the document and also how well it communicates. An example outline:

1. Cover page identifying the document, you, and the undergraduate group
2. A very short description of the undergraduate system (one paragraph)
3. Stakeholder Onion diagram
4. Stakeholders’ short descriptions (one or two sentences for each stakeholder)
5. Stakeholder Goal Influence Table
6. Summary of the Stakeholder Goal Influence Table (several paragraphs describing the important goals and influences)
7. Personas
8. Simplified HTA
9. Summary of the simplified HTA, perhaps describing the application views.
10. Appendix: Your notes from the interview with the scientist

Email Me and Your Team

Email me (pastel at mtu.edu) when your website is up-to-date, so that I may view them. The subject line of the email should be

cs5760 Evaluation Assignment 1

Your email should NOT attach the documents. Rather, I will read them on your website.

Also email your team that you have posted the assignment to the website.