HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth [email protected] October 5,...

25
HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth [email protected] October 5, 2015

Transcript of HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth [email protected] October 5,...

Page 1: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

HCI598 Milestone 4: Prototyping / Peer Review

Deirdre King [email protected]

October 5, 2015

Page 2: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

The project

• to develop an online tool to enable clergy in Southwestern Pennsylvania to make more effective social service referrals.

• the immediate goal is to acknowledge and support clergy’s role as local “gatekeepers” of information and aid, while enabling the development of a more collaborative knowledge base among clergy

• the longer-term goal is to democratize access to current social services information in communities

Page 3: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Features of the user group

• clergy serving in local churches and other religious

organizations

• wide age range: from mid-20’s to 70’s

• wide range of online online experience: all have basic experience with e-mail; many have used online search tools such as Google; some have used social media sites

• need access to referral information from a variety of locations: in office, at home, on road

Page 4: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Prototyping strategy

• high (but not complete) fidelity – for peer review at this milestone, using a digital

prototype made with Balsamiq, added as an extension to Google Chrome

– not complete fidelity to a “final” system: • not fully polished, single font, “sketched” buttons• “Wizard of Oz” interaction between site pages

• chose digital prototyping over paper both for peer review and subsequent user testing

Page 5: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Why digital rather than paper?

rationale for use in peer review:• At this point, I am seeking input on the perceived usability of

the site, rather than seeking broader conceptual input on site organization or topic.

• Johansson and Arvola (2007) found that digital prototypes worked better for identifying operational issues, while paper was better for supporting conceptual brainstorming.

Page 6: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Why digital rather than paper?

rationale for use in peer review:• A digital prototype enables more direct and pointed review of

the appropriateness of size, color, and persistence of site elements

• Sefelin, Tscheligi and Giller (2003) found that these site elements can be more effectively assessed through a digital prototype, without a loss of other usability information

Page 7: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Why digital rather than paper?

rationale for use in peer review:• A digital prototype supports a cleaner review of linkages and

ease of movement between site elements.

• Virzi, Sokolov and Karis (1996) identified these advantages of a digital prototype, while also finding that they uncovered similar usability issues to those that a paper prototype might uncover.

Page 8: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Why digital rather than paper?

rationale for use in user testing:• Because users will have a wide range of experience in doing

so using online tools and web searching, I want to test usability across that range specifically on an online platform.

• In their review of the literature, Rudd, Stern, and Isensee (1996) found that tests with higher-fidelity (digital) prototypes tend to be more user-driven rather than facilitator-driven, allowing me to assess users’ direct interaction with the site and identify potential areas for greater user support.

Page 9: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Why digital rather than paper?rationale for use in user testing:• Because there is such a wide variety of information that could

be included in listings for social service providers, and a limited amount of screen space, I want to “lock in” some basic information types as a default starting point before soliciting user suggestions.

• As noted above, Johansson and Arvola (2007) found that digital prototypes worked better for identifying operational issues, while paper worked better for supporting conceptual and content brainstorming; I want user interaction with the site to focus on tasks and usability, and to limit discussion of potential new content to debriefing interviews.

Page 10: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Why digital rather than paper?

rationale for use in user testing:• I ultimately want to support availability of this site via

mobile devices, and so need user feedback on the clearest possible digital layout as a basis for responsive web design.

• Walker, Takayama and Landay (2002) found that while testing with paper and digital prototypes found many similar usability issues, digital testing did better at uncovering the severity of usability problems. This will be important in developing the clearest possible design before moving to mobile support.

Page 11: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Walkthrough of digital prototype

https://youtu.be/Awv7TS5p4YE

Page 12: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 1: requirements supported

Users should be able to receive information about referral resources in their local community.

requirements:• The system shall enable users to search for resources by one or

more zip codes.

• The system database shall contain zip code information on both provider location and provider area of service.

Page 13: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 2: requirements supported

Users should be able to receive information about referral resources specific to the aid-seeker’s needs.

requirements:• The system shall enable users to search for resources

by the type of service provided.

• The system shall provide users with detailed information concerning the scope of services a provider offers, as well as any eligibility requirements.

Page 14: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 3: partially supported

Users should be able to receive information that allows them to connect to a broader network of professionals providing social services.

requirements:• The system shall provide users with specific contact information

for appropriate staff members within the providers included in the database. This will vary depending on information available from agencies.

• The system shall provide search results and resource guides that include links to other organizations’ websites.

Page 15: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 4: requirements supported

Users should be able to receive information that informs them about the process of making referrals.

requirements:• The system shall provide access to referral guides that provide

process overviews and referral scenarios for various categories of social services. Supported in referral guides.

Page 16: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 5: requirements supported

Users should be able to receive information that allows them to inform aid-seekers of public resources beyond their local community.

requirements:• The system shall provide access to documents that

describe state- and federal-level programs and resources that are relevant to the area of need. Supported in referral guides.

Page 17: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 6: partially supportedUsers should be able to trust the relevance and reliability of information they access on the system. requirements:• The system will limit access to local provider searches to registered users,

controlling access to this system function through a login system.

• Access to the system as a registered user will require verifiable contact information (e.g. an e-mail address) as well as status as a clergy member.

• Contributions to the database in its initial phase will be accepted only from local clergy members. (since all listings submitted will be verified, this requirement may be unnecessary)

• User-contributed information will require approval from the system manager before being added to the database.

Page 18: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 7: requirement supported

Users should be able to contribute to and improve the database of referral resources.

requirements:• The system will display a persistent link on all site pages,

affording users access to an online form to submit information.

Page 19: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 8: deferred

Users should be able to access referral resources in the locations where they become aware of referral needs.

requirements:The system will support responsive re-sizing of pages displayed, to enable use on mobile devices. (Awaiting results of user testing of prototype to begin formatting for mobile.)

Page 20: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Task 9: requirements supportedUsers should be able to use the site regardless of age or level of experience with online tools

requirements:• The site layout will include a consistent sidebar, header and footer across

all site pages. • The system will support error recovery through clear buttons and links

that enable users to return to the initial search page.

• The system interface will use readable type, minimalist graphics, and buttons that are clearly demarcated as clickable.

• The site footer will include a link to enable users to contact the site manager for further assistance.

Page 21: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Reflections on prototyping

For this project: prototyping has helped to:• identify problems with linkages between site

elements

• reveal implied promises that my initial design did not meet

• reveal unnecessary complexity in my design

Page 22: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Reflections on prototyping

For my ongoing work in HCI: I’d like to develop my prototyping skills in the following ways:

• using paper prototyping as an initial collaborative step in site evaluation and design

• applying and teaching prototyping as a “crossover skill” between ethics, ministry, and helping people to imagine and build better online tools

Page 23: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

Reflections on prototyping

Things I’ve learned in this prototyping milestone:

• the potential effectiveness of paper prototyping, based on the literature – good design has a lower barrier to entry than I thought

• the lack of a “perfect” approach to iterative design

• the many vulnerabilities of a complex website

Page 24: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

ReferencesJohansson, M., & Arvola, M. (2007, September). A case study of how user interface sketches, scenarios and computer prototypes structure stakeholder meetings. In Proceedings of the 21st British HCI Group Annual Conference on People and Computers: HCI... but not as we know it-Volume 1 (pp. 177-184). British Computer Society.

Rudd, J., Stern, K., & Isensee, S. (1996). Low vs. high-fidelity prototyping debate. interactions, 3(1), 76-85.

Sefelin, R., Tscheligi, M., & Giller, V. (2003, April). Paper prototyping-what is it good for?: a comparison of paper-and computer-based low-fidelity prototyping. In CHI'03 extended abstracts on Human factors in computing systems (pp. 778-779). ACM.

Page 25: HCI598 Milestone 4: Prototyping / Peer Review Deirdre King Hainsworth deirdre@iastate.edu October 5, 2015.

ReferencesVirzi, R. A., Sokolov, J. L., & Karis, D. (1996, April). Usability problem identification using both low-and high-fidelity prototypes. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 236-243). ACM.

Walker, M., Takayama, L., & Landay, J. A. (2002, September). High-fidelity or low-fidelity, paper or computer? Choosing attributes when testing web prototypes. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting (Vol. 46, No. 5, pp. 661-665). SAGE Publications.