UX Usability Requirements and Guidelines Working Document

Overall mission of UXC requirements: Human users shall be able to understand the need for any personal information and be enabled to supply it with the least disruption to their work flow at the service provider site.

NOTE: the Requirements in bold reflect what was revised and turned into the FMO in June, 2015 for the combined requirements across all groups and committees. Below each requirement there is supplemental information and links about each HLReq. In addition, we have created a UXC Dictionary page.

1) HL Requirement, USABLE-1: Entities conducting digital identity management functions MUST apply user-centric design, and industry-accepted appropriate usability guidelines and practices, to the communications, interfaces, policies, data transactions, and end-to-end processes they offer, and remediate significant defects identified by their usability assessment. (Category: Usable language)

- Consult the UXC Resources page located here for examples of non-normative UX practices: https://www.idecosystem.org/wiki/UXC_resources

- Consult the UXC Resources page located here for examples of UXC definitions of terms in these requirements and supplemental guidelines: https://www.idecosystem.org/wiki/UXC_Dictionary

- [ARR]The term "user-centric" design comes from the IDESG founding document the National Strategy for Trusted Identities in Cyberspace April 15, 2011. This term to be further described below exists in a common semantic domain with largely similar meanings in cyberspace that are central to the design of establishing trusted identities in cyberspace. This is the chief area of concern of the IDESG.

For defintions of user, user-centric and others look here: [[NSTIC Strategy]:https://www.idecosystem.org/wiki/File:Full_NSTIC_Strategy_Document_-_04152012_ARR_Annotated_for_user_centric.pdf]

Terms in the Common Semantic Domain found in the NSTIC Strategy include:

• user
• user centric
• user centered
• user-centered
• human-centered
• human centered
• end-user
• end user
• individual user
• user-friendly

Sample usage from NSTIC:

• "The realization of this vision is the user-centric “Identity Ecosystem” described in this Strategy."P8

• "Furthermore, the online environment today is not user-centric. Individuals tend to have little ability to manage their own personal information once it is released to service providers, and they often must calculate the tradeoffs among security, privacy, and gaining access to a service they desire." Page 12

• "It also reflects the user-centric nature of the Identity Ecosystem, which provides greater transparency, privacy protection, flexibility,and choice to the individual." Page 21

• "New privacy protections will shift the current model of application-specific collection of identity information to a distributed, user-centric model that supports an individual’s capability to manage an array of cyber identities and to manage and assert personal attributes without having to provide identifying data." Page 29

• "Lack of secure, convenient, user-friendly options for authentication and identification;" Page15
• "New privacy protections will shift the current model of application-specific collection of identity information to a distributed, user-centric model that supports an individual’s capability to manage an array of cyber identities and to manage and assert personal attributes without having to provide identifying data." Page 35

• Limit the retention of data to the time necessary for providing and administering the services to the individual end-user for which the data was collected, except as otherwise required by law; • Provide concise, meaningful, timely, and easy-to-understand notice to end-users on how providers collect, use, disseminate, and maintain personal information;" Page 36

The common semantic domain is roughly referred to hereas:https://en.wikipedia.org/wiki/User-centered_design

UCD models and approaches

For example, the user-centered design process can help software designers to fulfill the goal of a product engineered for their users. User requirements are considered right from the beginning and included into the whole product cycle. These requirements are noted and refined through investigative methods including: ethnographic study, contextual inquiry, prototype testing, usability testing and other methods. Generative methods may also be used including: card sorting, affinity diagramming and participatory design sessions. In addition, user requirements can be inferred by careful analysis of usable products similar to the product being designed.

• Cooperative design: involving designers and users on an equal footing. This is the Scandinavian tradition of design of IT artifacts and it has been evolving since 1970.<ref>Greenbaum&Kyng (eds): Design At Work - Cooperative design of Computer Systems, Lawrence Erlbaum 1991</ref>
• Participatory design (PD), a North American term for the same concept, inspired by Cooperative Design, focusing on the participation of users. Since 1990, there has been a bi-annual Participatory Design Conference.<ref>Schuler&Namioka: Participatory Design, Lawrence Erlbaum 1993 and chapter 11 in Helander’s Handbook of HCI, Elsevier 1997</ref>
• Contextual design, “customer-centered design” in the actual context, including some ideas from Participatory design<ref>Beyer&Holtzblatt, Contextual Design, Kaufmann 1998</ref>

All these approaches follow the ISO standard Human-centred design for interactive systems (ISO 9241-210, 2010).

The ISO standard describes 6 key principles that will ensure a design is user centered:

1. The design is based upon an explicit understanding of users, tasks and environments.
2. Users are involved throughout design and development.
3. The design is driven and refined by user-centered evaluation.
4. The process is iterative.
5. The design addresses the whole user experience.
6. The design team includes multidisciplinary skills and perspectives.
   

To Compare the Definitions in this domain look here [[User-centric:] https://www.idecosystem.org/idesgwiki/images/0/0e/User-centric_design_-_Yahoo_Search_Results.pdf]]

2) HL Requirement, USABLE-2: Entities MUST assess the usability of the communications, interfaces, policies, data transactions, and end-to-end processes they conduct in digital identity management functions.

- Consult the UXC Guidelines and Metrics page: https://www.idecosystem.org/wiki/User_Experience_Guidelines_Metrics

3) HL Requirement, USABLE-3: Information presented to USERS in digital identity management functions MUST be in plain language that is clear and easy for a general audience or the transaction's identified target audience to understand. (Category: Clarity of pathways, options, solutions)

• Instructions for use of the system should be visible or easily retrievable whenever appropriate.  :• Help and documentation information should be easy to search, focused on the users' task, list concrete steps to be carried out, and be concise.

• Platform conventions for words, actions, and situations are consistent across the platform.

       o Example: Users should not have to wonder whether different words, situations, or actions mean the same thing across the platform.

• The system should speak the users' language, following real-world conventions and making information appear in a natural and logical order.

       o Example: Systems should use words, phrases, or concepts familiar to the user rather than system-oriented terms.
               • One example is "privacy enhancing technology" - research show that "privacy protection" is better understood by real users.                            :• Error messages should be expressed in plain language, without codes, clearly indicating the problem and constructively suggesting a solution.

• The user’s identity status on a system should be clear to the user.

       o Example: It should be clear to the user whether their identity is anonymous, pseudonymous or verified.

• Any change in identity status should be presented in clear language to the user.

       o Example: If a process requires a user to switch to a verified identity from a more anonymous state, the user should be clearly prompted to change their identity status.

• Descriptions of states of identity (verified, anonymous, pseudonymous) should be linked to clear, easy to read and understand, and concise definitions.

       o If standard definitions are available, they should be used.

• The design of the website should eliminate information that is irrelevant or rarely needed.

       o This also includes layout and look/feel/branding, in addition to language.

4) HL Requirement, USABLE-4: All choices, pathways, interfaces, and offerings provided to USERS in digital identity management functions MUST be clearly identifiable by the USER. (Category: Accessibility for all)

• Organizations should operate in a manner that allows individuals to easily switch service providers if the organization fails to meet user expectations, becomes insolvent, is incapable of adhering to policies, or revises their terms of service. (V2)

• Systems should provide clear and easy to use pathways to help users recognize, diagnose, and recover from user-made errors.

• The information needed by the user to understand any choice should be clearly visible in a single, visible window. Dialogues should not contain information that is irrelevant or rarely needed.

• To mitigate the risk of errors, systems should allow the user the option to cancel, skip or decline, before they commit to a pathway action as well as provide a confirmation notice after they commit.

• If an entity decides an action is required, and a user chooses to skip or decline this action, the Entity's system should state clearly to the user if the transaction will not be completed.

• If a user accepts, skips or declines an option, the Entity's system should state clearly to the user the transaction was or was not completed.

• Entity's systems should allow users the choice to proceed anonymously, pseudonymously or with any chosen / assigned identity.

• Entity's systems should allow the user choice and clear options for changing the status of their identity. For example: switching to anonymous browsing.

• Information users need to make decisions should be readily available and transparent to the user.

• The identity of the Entity and Entity's systems with which the user is interacting should be clearly visible and understandable to users at all times. This includes third parties and changes between Entities and users during sessions.

• When a new user chooses an identity provider, the available options should be clearly presented so that a user can make an informed decision. When a new user visits a Relying Party site, the user should be presented with information about the request for identity proofing, verification or attributes and the types of identity providers or frameworks that are acceptable.
 :• Clear pathways should exist for users to procure desired services.

• The user should be presented with pathways to the identity service that they desire, such as: privacy options, identity caching, etc.

5) HL Requirement, USABLE-5: All digital identity management functions MUST make reasonable accommodations to be accessible to as many USERS as is feasible, and MUST comply with all applicable laws and regulations on accessibility. (Category: Response to user feedback)

• Entities should review all accessibility standards and apply what they deem feasible to their sites based upon their legal and regulatory environment.

• All Entities, when feasible, should provide equivalent access to and use of information and systems to users with disabilities that is comparable to the use and access by those who are users without disabilities.

• All IDESG compliant sites must provide all feasible functionality to any user with a compatible internet connected device as that available to individuals without disabilities.

• Users with disabilities should have access to documentation tailored to their needs, as is feasible.

• User Centered Design that accounts for accessibility issues must be used whenever possible.

• Additional industry requirements, should when feasible be reviewed and used. They include but aren't limited to (health, finance, etc ??, Nielsen? Universal accessibility?)

• ? Link to existing standards, regulations ex: ISO, Sect 508, etc.

6) HL Requirement, USABLE-6: All communications, interfaces, policies, data transactions, and end-to-end processes provided in digital identity management functions MUST offer a mechanism to easily collect USERS' feedback on usability.

• All IDESG compliant sites should provide a mechanism to gather feedback from users on site usability, adjusting the site design in response when appropriate.

• Additional information on collecting user feedback can be found in our UXC Guidelines and Metrics page: https://www.idecosystem.org/wiki/User_Experience_Guidelines_Metrics

7) HL Requirement, USABLE-7: Wherever public open STANDARDS or legal requirements exist for collecting user requirements, entities conducting digital identity management functions MUST offer structured opportunities for USERS to document and express their interface and accessibility requirements, early in their interactions with those functions. Entities MUST provide a response to those user requirement communications on a reasonably timely basis.

• Any entity "collecting personal data," whether they are first or third parties, would mean that the entity is interacting with users directly and therefore should provide a response to user requests early on in the interaction or collection.  :• As a general principle, consent choices or other similar must-see-this-first information should be exchanged in a first encounter, and then honored in and presented in a consistent manner thereafter.

• Suggested ways for UX mitigation include pop-up boxes or email responses to requests. Links to information regarding additional use and provide adequate time for users to read the information presented to them.

- QUESTIONS: • IDESG needs to define what constitutes an interaction and what 3rd party tracking is. Also, the entity gathering information would need to state whether identity information is being used, and whether the user should be notified.

- Do Not Track, link?)

USABLE-BP-A. RECOMMENDED ATTRIBUTE REQUIREMENTS QUERY Entities conducting digital identity management functions SHOULD offer persistent opportunities for USERS to document and communicate their unique requirements about their attributes and how they are used. Entities SHOULD provide good-faith responses to those communications about requirements, before the USER is asked to agree to share their attributes.

• As a general principle, consent choices or other similar must-see-this-first information should be exchanged in a first encounter, and then honored in and presented in a consistent manner thereafter.

• Suggested ways for UX mitigation include pop-up boxes or email responses to requests. Links to information for additional use and adequate time to read should be included in the process for end users.

• QUESTIONS: IDESG needs to define what constitutes an interaction and what 3rd party eavesdropping is. Also, IDESG would need to state whether identity information is being used, whether the user should be notified.

• Attention paid to the unique dynamics around attribute exchanges.

OTHER QUESTIONS, ADDITIONS FOR 1.2 REQUIREMENTS

• Questions: Implied consent? Anticipating effects? What does transparency mean in the context of User Experience?

• The user should be informed that the IDEF is designed for portability.

• Redress?