2010 IU Usability Project (ARCHIVED)

Overview

The Indiana University School of Informatics graduate course, INFO-I543 Usability and Evaluative Methods, is conducting a semester-long project to study the usability of OpenMRS.

Who's Involved?

• Former user (Deleted)
• Michael Downey
• Former user (Deleted)

Objectives

Our student user experience team is conducting for OpenMRS a comprehensive usability evaluation of the OpenMRS web application between September and December 2010. OpenMRS is working on a major redesign for their 2.0 release in 2011, and now is an ideal time for a thorough assessment of the quality of the application.

This evaluation work will consist of a professional, systematic usability inspection (complete mid-October) and a usability testing (complete in December). Our goals are to characterize and highlight the major usability gaps, areas of improvements and recommendations for redesign.

Taking into account the results of the usability inspection, we will plan and execute extensive usability testing (with actual or potential users) of OpenMRS. By the the end of the project, we will deliver a report containing the results of the usability testing, and the integration of these results with the ones from inspection to provide a final comprehensive evaluation.

Usability Inspection - Timeline

Usability Testing - Timeline

User Profiles

• Clinician (doctor)
• Researcher
• Data Entry Clerk
• Registration Clerk

Scenarios

1. Scenario 1: Review specific patient history
   1. User: Dr. Wendell Brown, Clinician-doctor specializing in pediatrics; 34 years old
   2. Biography: Dr. Brown is a volunteer with Doctors Without Borders and works three months each year in Kenya caring for children and adults with HIV/AIDS. He immigrated from Nicaragua as a child and is now a naturalized citizen of the U.S.A. with an American name. He received his medical training from John Hopkins University. He is comfortable using computers to input information, review files, and order tests, treatments, x-rays and prescriptions. OpenMRS is used in the clinics where he sees patients. He uses the software to access patient records and review past treatments, test and x-ray results, existing conditions, and past diagnosis. He often reviews the patient file again after the information has been input by the data entry clerk to add any additional notes and to review what was entered.
   3. Goal: Retrieve patient information to review past examinations and diagnoses as well as the results of tests, x-rays and treatments to provide the best care possible.
   4. Task 1: In seeing a patient, Dr. Brown will access OpenMRS to review any previous visits by the patient. He wants to know past and present diagnosis, past and current medicines, patient medical history, and patient living situation (is clean water available, is electricity available, etc.)
   5. Task 2: Record new patient information including new complaints and concerns, observations, and any diagnosis.
   6. Task 3: Order any needed tests and x-rays through OpenMRS
   7. Task 4: Review patient file via OpenMRS after data entry clerk inputs information.
2. Scenario 2: Generate reports on a group of patients
   1. User: Robert Mullin, researcher, 43
   2. Biography: Robert lives in Chicago, Illinois. He uses the software to track occurrences of various illnesses in discrete geographic areas where OpenMRS is used. He generally views computers as business machines and does not have much interest in using them outside of the workplace.
   3. Goal: Patient demographic data is analyzed and used to track the spread of different diseases in eastern Africa or other broad geographical areas.
   4. Task 1: Obtain the patient data en masse from OpenMRS’ servers.
   5. Task 2: Visualize the data by illness and specific geographical area.
   6. Task 3: Create a report that presents and interprets the OpenMRS data.
3. Scenario 3: Enter data from a completed patient form
   1. User: Damarice Langat, data entry clerk, 28 years old
   2. Biography: Born in the village of Burnt Forest, Kenya. She attended secondary school near Burnt Forest and now works for the USAID-AMPATH Partnership in nearby Eldoret as a data entry clerk. Her primary role is to handle data entry for clinical forms for the HIV/AIDS prevention programme. She became interested in computers in high school but had no formal IT training other than what has been provided to her at AMPATH. She is married with three children, aged 8, 10, and 11. She does not have a computer at home, but occasionally uses one in town to access Facebook and e-mail.
   3. Goal: Patient data provided on a paper form filled by a clinician is entered and stored in the system.
   4. Task 1: Review the paper form. Obtain patient's name and ID number from the paper form. Search for the patient in the system. (If they do not exist, a different scenario for creating that patient will be done.
   5. Task 2: Create a new encounter in the system associated with the patient and provider listed on the paper form. Ensure the location where the encounter happened and the date are recorded in the system.
   6. Task 3: For each item listed on the form, record the concept and its associated value (e.g., weight and 100 kg). Repeat this process for each observation on the form.Note: These three tasks are repeated for each form to be entered.
4. Scenario 4: Register a new patient
   1. User: Gilbert Leonis, registration clerk, 24 years old
   2. Biography: Born just outside Eldoret, Kenya and lived with his family on their farm through secondary school. He got a job with Moi University in Eldoret doing data entry, and was recently seconded to work in the AMPATH building next door, although the University still pays him. His primary responsiblility is to register new patients to the program and re-issue identification cards to current patients. He is still single and has no children, and likes to go out to Signature night club most evenings until the early morning hours.
   3. Goal: A new patient's demographic data is collected, entered in the system, and an identification card issued
   4. Task 1: Meet with the patient and determine their identity.
   5. Task 2: Review current patient records to see if the patient is already registered.
   6. Task 3: If not registered, create a new patient record.
   7. Task 4: Verbally collect demographic information from the patient and enter it into the new patient record.
   8. Task 5: Fill out an ID card with the patient's ID number and name, laminate it and provide to the patient.
      Note: These five tasks are repeated for new patient.

Scenario Evaluations

1. Scenario 1: Review specific patient history
   1. Problem: Current patient status is limited. In this scenario, the clinician requires background information on the patient's living conditions as well as current regimens.
      1. Severity: Additional time is required to ascertain the patient's background. A clinician must go into individual forms to look at responses (in this case, living conditions).
      2. Solution: Consider adding additional items for living conditions to the patient dashboard based on clinician input.
   2. Problem: There is no way for a clinician to add an encounter from the patient dashboard. The encounter management tools are under the administration section of the application, which is not intuitive.
      1. Severity: The clinician may not even be able to record data for a patient, and may resort to writing things down and giving the information for someone else to enter.
      2. Solution: Rework the "Find/Create Patient" section to add encounter management tools. Allow an encounter to be created from the patient dashboard (pre-populating the patient field) or from the initial patient search page.
   3. Problem: OpenMRS has no built-in patient scheduling system per se, unless it were to be created as a concept on a form.
      1. Severity: Scheduling patients can not easily occur within OpenMRS. The most likely alternative is to use a paper system.
      2. Solution: Add a basic scheduling system to OpenMRS, allowing clinicians or others to enter the next appointment date, and allowing that appointment date to be re-scheduled or cancelled.
   4. Problem: Difficult to add non-drug orders.
      1. Severity: A clinician could not find a way to add non-drug orders for patients. The "Regimens" tab only allows adding prescriptions. Clinicians would have to go into Administration and then add a non-drug order for the patient from the order form.
      2. Solution: Rework regimens or add an "Orders" tab on the patient dashboard to allow non-drug orders.
   5. Problem: Observations are not in any logical grouping.
      1. Severity: Critical patient information could be missed by the doctor.
      2. Solution: Categorize the data in logical groups. For example, all test results would be located together, etc.
   6. Problem: Not intuitive to move between patients.
      1. Severity: Requires additional time of doctor to locate patient records (time that could be spent with patient)
      2. Solution: Add a button that allows doctor to close current patient record and access another record.
   7. Problem: No way to annotate patient records.
      1. Severity: Important notes from doctor are not included in patient records.
      2. Solution: Incorporate a "sticky note" function within OpenMRS that allows for doctor notations.
   8. Problem: No comprehensive summary of patient status from patient dashboard.
      1. Severity: Doctor must navigate through multiple pages to obtain an overview of a patient, using time that could be spent treating patients.
      2. Solution: Provide a patient summary option within the patient dashboard that gives a one-page overview of the patient.
2. Scenario 2: Generate reports on a group of patients
   1. Problem: Creating reports from cohort builder errors non-gracefully.
      1. Severity: If specific concepts, e.g., REASON FOR EXITING CARE, are not present when trying to view a report on a cohort, OpenMRS errors with a Java stack trace, and it's impossible to continue working.
      2. Solution: Make error messages non-fatal and display the context of what the user was doing when the error appears.
   2. Problem: No way to immediately visualize report data.
      1. Severity: Even with several indicators in a report, only totals are returned as lists of patients. There are no immediate ways to visualize these totals unless downloading a CSV file and bringing it into Microsoft Excel.
      2. Solution: Use some of the basic graphing technology in OpenMRS to visualize the levels of each indicator in a report.
   3. Problem: No contextual help for reporting processes??? (Generic issue)
      1. Severity: Hands-on training is required to use the system adequately.
      2. Solution: Incorporate an brief step-by-step tutorial within the system for each type of user (doctor, researcher, data entry, etc.)
3. Scenario 3: Enter data from a completed patient form
   1. Problem: Form entry from patient dashboard doesn't seem to work.
      1. Severity: From the patient dashboard, it appears that to enter a form, you simply search for that form's name and then fill out the values. However, the search box doesn't seem to do anything. No error message appears.
      2. Solution: Add an error message on the Form Entry search on the patient dashboard if no forms are found.
   2. Problem: There is no way for a clinician to add an encounter from the patient dashboard. The encounter management tools are under the administration section of the application, which is not intuitive.
      1. Severity: The clinician may not even be able to record data for a patient, and may resort to writing things down and giving the information for someone else to enter.
      2. Solution: Rework the "Find/Create Patient" section to add encounter management tools. Allow an encounter to be created from the patient dashboard (pre-populating the patient field) or from the initial patient search page.
   3. Problem: Error message for invalid concept value entry are not helpful.
      1. Severity: Current error message does not indicate to user what the error is and how to fix it.
      2. Solution: Develop clear and concise error messages that notify user of type of error and correction needed.
4. Scenario 4: Register a new patient
   1. Problem: Can't add some demographic information from create patient form.
      1. Severity: The registration clerk must re-edit the patient using the "Demographic" tab on the patient dashboard after adding them to the system, in order to add some demographic items like Mother's Name, Race, etc.
      2. Solution: Add the items under the "Patient Information" section when editing a patient's demographics on the create patient screen.
   2. Problem: No way to see possible values for some fields. For example, "Civil Status" in patient demographics.
      1. Severity: The person doing data entry may not know all the possibilities available in the system.
      2. Solution: Make some fields like this one into radio buttons instead of requiring the user to search/type the value of something they may or may not know.
   3. Problem: System requires a pre-generated ID number.
      1. Severity: Creating a patient ID number involves a manual operation of consulting an ID number resource either online or via paper record.
      2. Solution: Incorporate auto-ID number generation within the application.
   4. Problem: Spelling errors make for difficult searches.
      1. Severity: A patient's record could exist under multiple spellings of the same name, creating extra work for the doctor and data entry clerks and potentially impacting patient care.
      2. Solution: Expand the search feature to include searches for "sound alike" names.

Heuristic Inspection

Severity rating key used in this inspection:

• Severe: An emergency condition that causes the customer’s system to fail or causes customer data to be lost or destroyed. A showstopper usability bug can also be one that is likely to cause frequent data integrity errors. There is no workaround to these problems.
• High: A serious condition that impairs the operation, or continued operation, of one or more product functions and cannot be easily circumvented or avoided. The software does not prevent the user from making a serious mistake. The usability problem is frequent, persistent, and affects many users.
• Medium: A non-critical, limited problem (no data lost or system failure). It does not hinder operation and can be temporarily circumvented or avoided. The problem causes users moderate confusion or irritation.
• Low: Non-critical problems or general questions about the product. There are minor inconsistencies that cause hesitation or small aesthetic issues.

1. Visibility of system status
   1. High: No visual relationship between patient, encounter, and observations. From the patient dashboard, a user can only see encounter forms and some selected recent observations.
   2. Medium: Items in header menu don't respond to current section, making it difficult to know which section user is in. As a result, the user can not tell which section (patient, administration, dictionary) they are working within.
   3. Medium: Inconsistent link coloring. Some items appear to be links but are not. Users may try to click something that is not a link, or avoid clicking something that is in fact a link, causing them to become confused how to edit a value or make changes to the system. Example: Blue text is used both as link color and highlighted text color. User-action links (log out, profile, help) are yellow.
2. Match between system and the real world
   1. Severe: No intuitive way for a clinician to enter an encounter form when viewing a patient. No error message when searching for a form from the patient dashboard. This can only be accomplished via the system administration section.
   2. High: Difficult to enter patient data while viewing patient information. The system works in only a data-entry or data-viewing mode. There is no way to compare past values while entering new observations, which would allow the user to ensure the entered value is likely accurate and not mistakenly written or abnormal for that particular patient.
   3. High: There is widespread use of programming terminology throughout the web application. Examples: "type 4 (INVALID CHECK DIGIT) if hasCheckDigit is flagged". Users will not understand this language and may abandon what they are doing due to confusion.
   4. High: Two options for editing patient demographics, "Edit this Patient" and "Edit this Patient (Short Form)" exist. The longer form seems to duplicate all the information of the short form, making the short form redundant. Users may choose the short form and not record all information.
   5. Severe: The system requires a correctly-generated patient ID number, but has no option to generate one. Users will not be able to register a new patient if either a list of ID numbers is not available, or they do not know how to generate one.
   6. Medium: The purpose of the checkbox labeled "Include Verbose" when searching (e.g. patient search, concept search) is unclear. When turning it on and off after a set of results appears, nothing seems to happen. A user may become confused about the box.
   7. Medium: In Cohort Builder, there is no way to create a multivariate cohort. (e.g., Combining demographics and person attributes, or programme enrollment with drug orders.) This may cause a user to create multiple simple cohorts instead of one complex group.
   8. Medium: The system provides no scheduling system and no obvious way to record next appointment other than as an encounter's observation, which is not easily reportable and not shown on the patient dashboard. Users will have to maintain an external patient scheduling system.
   9. Medium: There is no way to add orders or regimens that are not drug-based. Users will have to create observations within encounters for such orders which are not able to be seen without viewing individual encounter forms.
3. User control and freedom
   1. High: Sequence of cohort creation and report creation is not clear. A new user will become confused and will likely not understand how to identify cohorts and create reports from them.
   2. Medium: Last encounter and most recent observations (CD4, BMI, Weight, Height, Regimen) are shown on patient dashboard but not linked to that encounter. Users will have to browse through individual encounters to find the most recent encounters with this information.
   3. Low: No easy way to move between patients without going back to the search page. As a result, users have to perform additional tasks to search for users.
   4. Low: Longitudinal reports must be created per patient, no standardized chart/graph is provided for summary data. Users must create charts for each patient when viewing their patient dashboards.
4. Consistency and standards
   1. Medium: UI for cohorts and reporting, patient dashboard, and data entry are not consistent. Users will have to "learn" the layout of each tool with extra effort because the flow through these tools is not the same.
   2. Low: System name (OpenMRS) is not presented consistently (e.g. Openmrs). Some users may be distracted by this inconsistency.
   3. Low: Inconsistent use of the word "patient" and "person" within the application. Some users may be confused if they are dealing with a patient or a system user.
5. Error prevention
   1. High: No soundex-based searching for names. Names must be spelled exactly correct for a match. There is no "advanced search" that looks for other identifiers other than name or ID number. As a result, some users may not find the correct patient in the system and create a duplicate record.
   2. Medium: Validation errors/warnings are often not written in plain language but rather application code. Users may not understand the problem with their form entry, and may not be able to recover from the error by correcting their data entry.
6. Recognition rather than recall
   1. High: When searching for a concept to enter its value, the user must know the concept's name in the dictionary and type at least the first 3 letters correctly before it appears. Otherwise, the results are blank. The user must know the name of the concept they are looking for before entering it.
7. Help users recognize, diagnose, and recover from errors
   1. Severe: Some Java errors show no context of use. When users see error messages with Java stack traces, they will not necessarily know what they were doing when the error occurred, or how to avoid having it happen again.
8. Help and documentation
   1. Severe: No in-application help documentation whatsoever. Without basic help, users will likely become confused about how to perform basic tasks in the system and may not be able to use the system at all.
   2. High: Hover "tool tip" popups to explain data entry fields are implemented inconsistently across forms and sometimes not present, and no icon is present to inform the users more information is available. Users may be uncertain about the meaning of form field titles and enter incorrect data.
9. Visual Clarity
   1. Medium: Concept names are entered in all capital letters, which is more difficult to scan and read. This may be annoying for users that read many lists of concepts during a day.
10. Important Information Belongs Above the Fold
    1. Medium: Some key patient demographic data is hidden behind a tab, causing users to search for such information through tabs and individual encounter data.

Breakdown by Scenario

Scenario A: Patient Registration Clerk

1. Severe: The system requires a correctly-generated patient ID number, but has no option to generate one. Users will not be able to register a new patient if either a list of ID numbers is not available, or they do not know how to generate one.
   1. Category: Match between system and the real world
   2. Recommendation: Allow an option for the instant generation of valid, random, unique patient ID numbers when a new patient is created, but allow the possibility for such numbers to be overridden if necessary.
2. Severe: Some Java errors show no context of use. When users see error messages with Java stack traces, they will not necessarily know what they were doing when the error occurred, or how to avoid having it happen again.
   1. Category: Help users recognize, diagnose, and recover from errors
   2. Recommendation: Evaluate options to handle Java exceptions with a short description of what the system was doing when the error occurred. Minimize stack trace errors to avoid overwhelming users. Provide an opportunity for users to submit a "crash report" about the error, and basic instructions (perhaps with a link) about how to continue working.
3. Severe: No in-application help documentation whatsoever. Without basic help, users will likely become confused about how to perform basic tasks in the system and may not be able to use the system at all.
   1. Category: Help and documentation
   2. Recommendation: Create basic in-application help documentation for common tasks, perhaps starting with the scenarios listed in this work.
4. High: Hover "tool tip" popups to explain data entry fields are implemented inconsistently across forms and sometimes not present, and no icon is present to inform the users more information is available. Users may be uncertain about the meaning of form field titles and enter incorrect data.
   1. Category: Help and documentation
   2. Recommendation: Review all data entry forms in the application, and add both hover-based tool tips that describe each field, and add a small icon for the users to point to for the meaning.
5. High: No soundex-based searching for names. Names must be spelled exactly correct for a match. There is no "advanced search" that looks for other identifiers other than name or ID number. As a result, some users may not find the correct patient in the system and create a duplicate record.
   1. Category: Error prevention
   2. Recommendation: Investigate search methods for foreign names and alternative search algorithms that will return similar sounding names, omitted double letters, missing vowels, etc.
6. High: Two options for editing patient demographics, "Edit this Patient" and "Edit this Patient (Short Form)" exist. The longer form seems to duplicate all the information of the short form, making the short form redundant. Users may choose the short form and not record all information.
   1. Category: Match between system and the real world
   2. Recommendation: Unify the "short form" and regular edit patient form so only one option exists. If advanced options are desired but not required, indicate which fields are required, or "minimize" the extended attributes allowing the user to expand that section if desired before submitting the form.
7. Medium: The purpose of the checkbox labeled "Include Verbose" when searching (e.g. patient search, concept search) is unclear. When turning it on and off after a set of results appears, nothing seems to happen. A user may become confused about the box.
   1. Category: Match between system and the real world
   2. Recommendation:
8. Medium: Items in header menu don't respond to current section, making it difficult to know which section user is in. As a result, the user can not tell which section (patient, administration, dictionary) they are working within.
   1. Category: Visibility of system status
   2. Recommendation: Consider changing the visual status of the header menu to represent what logical section each page belongs to, allowing the user to easily correlate a form or other system page with that section.
9. Medium: Inconsistent link coloring. Some items appear to be links but are not. Users may try to click something that is not a link, or avoid clicking something that is in fact a link, causing them to become confused how to edit a value or make changes to the system. Example: Blue text is used both as link color and highlighted text color. User-action links (log out, profile, help) are yellow.
   1. Category: Visibility of system status
   2. Recommendation: Review stylesheets and other design elements to standardize link color and presentation. Do not use those colors for other design elements to allow links to "stand out" on pages.
10. Low: Inconsistent use of the word "patient" and "person" within the application. Some users may be confused if they are dealing with a patient or a system user.
    1. Category: Consistency and standards
    2. Recommendation: Review instances of such language and when it refers to a patient, change the language.

Scenario B: Data Entry Clerk

1. High: Difficult to enter patient data while viewing patient information. The system works in only a data-entry or data-viewing mode. There is no way to compare past values while entering new observations, which would allow the user to ensure the entered value is likely accurate and not mistakenly written or abnormal for that particular patient.
   1. Category: Match between system and the real world
   2. Recommendation: Allow form entry within the web application, with the most recent form's value on one side of the screen, and the new form on the other side of the screen, allowing the user entering data to see the previous values of the same form, from the last encounter.
2. High: There is widespread use of programming terminology throughout the web application. Examples: "type 4 (INVALID CHECK DIGIT) if hasCheckDigit is flagged". Users will not understand this language and may abandon what they are doing due to confusion.
   1. Category: Match between system and the real world
   2. Recommendation: Review error and warning messages for jargon and reword them using plan language.
3. High: When searching for a concept to enter its value, the user must know the concept's name in the dictionary and type at least the first 3 letters correctly before it appears. Otherwise, the results are blank. The user must know the name of the concept they are looking for before entering it.
   1. Category: Recognition rather than recall
   2. Recommendation: Consider "auto-complete" style UI elements that allow the user to see available choices as he types. Start offering these choices with the first letter rather than after the 3rd letter.
4. Medium: Validation errors/warnings are often not written in plain language but rather application code. Users may not understand the problem with their form entry, and may not be able to recover from the error by correcting their data entry.
   1. Category: Error prevention
   2. Recommendation:
5. Medium: The system provides no scheduling system and no obvious way to record next appointment other than as an encounter's observation, which is not easily reportable and not shown on the patient dashboard. Users will have to maintain an external patient scheduling system.
   1. Category: Match between system and the real world
   2. Recommendation:
6. Low: No easy way to move between patients without going back to the search page. As a result, users have to perform additional tasks to search for users.
   1. Category: User control and freedom
   2. Recommendation:

Scenario C: Researcher

1. High: Sequence of cohort creation and report creation is not clear. A new user will become confused and will likely not understand how to identify cohorts and create reports from them.
   1. Category: User control and freedom
   2. Recommendation: Consider creating a "cohort creation wizard" that guides the user through the process of selecting and saving a cohort, as well as a similar wizard to create basic reports.
2. Medium: In Cohort Builder, there is no way to create a multivariate cohort. (e.g., Combining demographics and person attributes, or programme enrollment with drug orders.) This may cause a user to create multiple simple cohorts instead of one complex group.
   1. Category: Match between system and the real world
   2. Recommendation:
3. Medium: Concept names are entered in all capital letters, which is more difficult to scan and read. This may be annoying for users that read many lists of concepts during a day.
   1. Category: Visual Clarity
   2. Recommendation:
4. Medium: UI for cohorts and reporting, patient dashboard, and data entry are not consistent. Users will have to "learn" the layout of each tool with extra effort because the flow through these tools is not the same.
   1. Category: Consistency and standards
   2. Recommendation:

Scenario D: Clinician Data Entry

1. Severe: No intuitive way for a clinician to enter an encounter form when viewing a patient. No error message when searching for a form from the patient dashboard. This can only be accomplished via the system administration section.
   1. Category: Match between system and the real world
   2. Recommendation: Create a link from the patient dashboard to allow creation of a new encounter. The same forms and pages should be used as those that are already existing from the administration section, to avoid additional confusion of multiple methods to enter forms.
2. High: No visual relationship between patient, encounter, and observations. From the patient dashboard, a user can only see encounter forms and some selected recent observations.
   1. Category: Visibility of system status
   2. Recommendation: Alternate views, such as a column based display could show the relationship between encounters and observations, and the values of those observations. Consider alternative layouts.
3. Medium: There is no way to add orders or regimens that are not drug-based. Users will have to create observations within encounters for such orders which are not able to be seen without viewing individual encounter forms.
   1. Category: Match between system and the real world
   2. Recommendation:
4. Medium: Last encounter and most recent observations (CD4, BMI, Weight, Height, Regimen) are shown on patient dashboard but not linked to that encounter. Users will have to browse through individual encounters to find the most recent encounters with this information.
   1. Category: User control and freedom
   2. Recommendation:
5. Medium: Some key patient demographic data is hidden behind a tab, causing users to search for such information through tabs and individual encounter data.
   1. Category: Important Information Belongs Above the Fold
   2. Recommendation:
6. Low: Longitudinal reports must be created per patient, no standardized chart/graph is provided for summary data. Users must create charts for each patient when viewing their patient dashboards.
   1. Category: User control and freedom
   2. Recommendation:
7. Low: System name (OpenMRS) is not presented consistently (e.g. Openmrs). Some users may be distracted by this inconsistency.
   1. Category: Consistency and standards
   2. Recommendation: Review all instance of application name throughout the application and modify for consistency.

Additional Links

• Key stakeholder background survey
• Survey responses
• ?User interviews from past work

Attachments