In this assignment, you will write formal design documents, upload and link them to your team website.
Each team member should read the lecture below before beginning this assignment.
Interaction Design Documents:
These are the design documents that must be posted on your team website. Note that many of these documents should be a collaborative effort between the CS and HU students on your team, while others are the primary responsibility of either the CS or HU students. For the app itself, CS and HU students should collaborate on interface design. HU students will also be responsible for suggesting design and creating content for the reference/help material which will be incorporated into the app (such as an in-app tutorial). This content should be taken into account when designing the app interface.
The design documents include:
- Both App Design Summaries
- Brief overview of the system, including the device and any other device used by the system.
- Descriptions of important stakeholders, including users.
- Four user personas (See lecture notes)
- Descriptions of the environment that users will be in while using the device and performing tasks
- Scanned or transcribed notes from the interviews with the scientist and among yourselves
- At least 2 scenarios describing the nominal use of the application, drawing on your personas (See lecture notes and below)
- At least 1 scenario describing user making an error using the app and the app behavior.
- Simplified hierarchical task interaction design (See lecture notes and below)
- A description of your database schema
These documents do not include sketches of the interface’s visual design; your interface’s visual design will be presented during the cognitive walkthrough.
After your website is reviewed in class, graduate students will give you links to their stakeholder analysis documents. You are to link the graduates’ stakeholder analysis to your website. The links should be clear and well organized, so that users of your website can easily recognize them. Make sure that all design documents have a title and date. You should also review the graduate students’ user-task-goal analysis documents and compare them to the nominal interaction diagram and scenario documents. If there is substantial disagreement, your team should discuss them with the graduate students. A good user interface cannot be designed without a thorough understanding of the users, their goals and the tasks to be performed with the interface.
Stakeholders and Users
List and describe the stakeholders. You should name their role and level in the onion model. Some specific stakeholders you may want to also give proper names, for example the scientists for your project. You should also identify the different users of app and classify them as primary or secondary. Briefly describe the user characteristics that you think are important for the design, for example are they novice or expert users.
Usability expert Carol Barnum (Usability Testing Essentials: Ready, Set…Test! Morgan Kaufman, 2010) defines personas as “fictional representations of people that are created from real data about your users” (94). Remember that although personas require creativity, the information presented should be relevant to the product or document that you are creating and should help designers “understand user motivation, fears, concerns, and goals as they relate to your product” (97).
Nominal Use Scenario
The nominal use scenario is a verbal description of a nominal (error free) sequence of events using the system. It should describe how the major stakeholders (primary and secondary stakeholders) interact with the system or the application. The description should be several paragraphs, one paragraph for each stakeholder interacting with the system. It should read like a story.
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 associated with goals, 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; this will represent the views. Then indent and list the actions to achieve the corresponding goal or task; this will represent UI elements in the view. Try to name the tasks and sub-tasks with words that might be used in the application view.
All Citizen Science projects collect data for scientist to use. In order for the scientist to have access to the data, your app should upload the data to a website.
Grails and GORM create the database table from the Grails project domain classes. The domain class is a collection of typed class members. The domain class represents the table in the database or a row of the table. The class members name represents the column names in the table.
A database schema is the design of tables composing your database. I expect that your schema design to evolve during development, but you should begin the design now. An appropriate design format is list of domain classes with an intended list of class member names (column names in the table) with type and description. The format is:
Domain : <name> – <description>
- var1 – <type>, <description>
- var2, – <type >, <description>
Schema Specification Example
Suppose you are designing the “Army App” data base that soldiers use to read missions and report incidents that can have photos or recordings (read lecture notes). Your schema design might be:
List of Domain Classes:
- Mission – list of mission names with dates
- Incident – list of incidents
- Incident_photo – associates photos with missions
- Incident_recording – associates recordings missions
Domain Class: Mission – list of missions
- name – String, mission name
- date – Date, date of mission
Domain Class: Incident – list of incidents
- mission – Mission, foreign key into missions table
- date – Date, date of incident
- Time – long, time of incident
- latitude – double, latitude coordinate of incident
- longitude – double, longitude coordinate of incident
- type – String, incident type = (civil, suspicious, littering, theft, …)
Domain Class: Incident_photo
- incident – Incident, foreign key into incident table
- date – Date, date of photo
- time – long, time of incident
- latitude – double, latitude coordinate of photo
- longitude – double, longitude coordinate of photo
- file_uri – String, URI (path with name) to the photo file
- incident – Incident, foreign key into incident table
- date – Date, date of recording
- time – long, time of incident
- latitude – double, latitude coordinate of recording
- longitude – double, longitude coordinate of recording
- flie_uri – String, URI (complete path) to the recording file
Submit on Canvas and Due Date
Submit the the URL of team website in canvas when you have finished implementing your website.
The Interaction Design Documents will be evaluated on timeliness and completeness. Specifically:
- Can I find and access the documents?
- Are all the required document completed?
- Are the document easy to read, written in full sentences, using proper grammar and well organized? Note your design documents can use some bullet or numbered list, but the design document should not be one continuous list.
- Are the all the stakeholders and user types listed and explained?
- Are the personas portrayed appropriate for the app and are they convincing representative individual?
- Are the scenarios complete and convincing as an actual user experience?
- Is the Simplified Hierarchical Task Analysis complete and understandable.
- Is the database schema complete, correct, and show the correct association between tables?
Prepare for Next Assignment
In your next assignments you will prepare for your Cognitive Walkthrough and give feedback on other projects. Prepare for the assignments by reading: