UX Usability Requirements and Guidelines Working Document: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
(updated #7, #3,)
No edit summary
 
(46 intermediate revisions by one other user not shown)
Line 1: Line 1:
'''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.'''
'''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.'''


'''1) HL Requirement: Information presented to users should be in plain language, which is clear and easy to understand.''' (Category: Usable language)
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.
:-Error messages should be expressed in plain language--no codes and indicate clearly the problem and constructively suggest a solution. (Jim)
:-Platform conventions for words, actions and situations are consistent across the platform. (Jim)
:-The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. (Jim)
::-One example is "privacy enhancing technology", way too geeky, research show that "privacy protection" is better understood by real users. (Tom)
:-Organizations shall utilize identity solutions that are simple to understand, intuitive, easy to use, and enabled by technology that requires minimal user training. (Jim)
:Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 
(Jim: applicable principles)
:-Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. (Jim: applicable principles)
:-Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. (Jim)
:-Visibility of system status (Noreen: heuristics)
::-Noreen says: possibly more appropriate under HL2, since it is more about the systems and process than about language and instruction -An indicator of the current trust state
::-Example: persistent icon or login link state that serves as a counter part to the RPs state indicator (eg the lock icon in the location bar) -::Example use: text next to the Log Out link displaying current state (anonymous, pseudonym, verified ID) Idea: Look at theNounProject.com for icons that are relatively universal
:-Use Control and Freedom (Noreen: heuristic) Noreen says: possibly more appropriate under HL2, since it is more about the systems and process than about language and instruction. -Initial state is anonymous -Plain language alerts when conditions change -All providers will be accessible and localized in English, Spanish and any other language expected to be encountered by a significant number of users. -Example: a process that requires a verified identity versus a switch to a less secure state where user would be prompted to change their status as they leave a secure state.
:-Consistency and Standards (Noreen: heuristic) -Link to standards documentation so user understands specifically how each state of anonymity is defined, what the potential actions and outcomes are and the definitions of terms used.
::-Example: If there are competing Trustmark standards, the terms, situations and actions should be disambiguated. -Define unique or ambiguous terms in the instructions before each action.
:-Aesthetic and Minimalist Design (Noreen: heuristic)
::-Dialogues should not contain information which is irrelevant or rarely needed.
::-Noreen: This heuristic also includes layout and look/feel/branding, so isn't necessarily about language.
:-Clear explanations should aim to mitigate cognitive overload for individuals.


'''2) HL Requirement: All choices, pathways, and solutions should be available and clearly identifiable by the user.''' (Category: Clarity of pathways, options, solutions)
'''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)


:-Organizations shall operate in a manner that allows individuals to easily switch service providers if the organization becomes insolvent, incapable of adhering to policies, or revises their terms of service. (Jim)
:• Consult the UXC Resources page located here for examples of non-normative UX practices: https://www.idecosystem.org/wiki/UXC_resources
::-This is too abstract. Let's say something more concrete, eg If an Identity or attribute provider fails to perform to user's expectations, the user will have an easy option to switch providers or policies. (Tom)
:• Consult the UXC Dictionary page located here for examples of UXC definitions of terms in these requirements and supplemental guidelines: https://www.idecosystem.org/wiki/UXC_Dictionary       
::-Noreen says: I prefer the first statement. Users should be able to switch providers for any reason, whether or not they feel the provider fails.
:The term "user-centric" design is a key tenet and requirement of the IDESG founding document: the National Strategy for Trusted Identities in Cyberspace (NSTIC) dated April 15, 2011. This term is further described in the Appendix A and is a common term in the User Experience domain.</br>
:When choosing an identity provider at an RP site, the available options are clearly presented so that a user can make an informed decision. (Ellen)
::-Need to clarify that this requirement is about the initial choice - specifically the problem is that a user going to a site anonymously cannot be known to be a returning or a new user so the information displayed, like that on the IDESG main page itself needs to work well for both cases. What this means is that whatever is displayed by the RP needs to function for both returning and new users, that means the additional choices cannot down a returning user. One possible solution is a way for a user to ask for more general help if they need it, rather than to demand that the RP site clearly present options on the RP site itself.
::- When a new user visits an RP site that requires identity, the user will have the option to request information about the need for more identity and the types of identity providers or frameworks that are acceptable
:Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. 
(Jim)
::-This is the recognition vs recall heuristic noted below. (Noreen)
:Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. (Jim: applicable principles)
::-While I agree with the thought - IMHO it is more important to make a positive statement rather than a negative statement - also dialog boxes do not fit with small form factor, like smart phones - eg The information needed by the user to understand any choice needs to be clearly visible in a single, visible window. (Tom)
::-Agree should be worded positively: Only relevant and needed information should be presented. Also "dialog" doesn't have to mean "dialog box" it would be any part of the conversation happening between user and system. (Noreen)
:-Users often choose system functions by mistake and will need a clearly marked ""emergency exit"" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. (Jim: applicable principles)
::-More the point of IDESG - The user should be able to terminate an identified interchange at any time removing any identifiers and attributes that were supplied as a part of the interchange and revert to an anonymous state. (Tom)
::-this is the Help users recognize, diagnose, and recover from errors Heuristic (Noreen: heuristic)
:-Clear pathways exist for users to procure desired services. (Ellen)
::-The user can find the path to the identity service that they desire, such as: privacy options, identity caching, etc.
:-User Control and Freedom (Noreen: heuristic) -Ability to initiate a change in anonymity, back out of a process, at any time
::-Example: as above, a button or link that lets you log out or switch identities
:-Error Prevention (Noreen: heuristic) -Use error messages, confirmation actions -Perform usability tests to eliminate any error prone actions -
::-Example: "The following procedure requires a verified ID" "Are you sure you want to continue?"
:-Recognition vs. Recall (Noreen: heuristic) -Jim touches on this. I can see situations where the process may hold details in memory during a session that could be revealed, as in "I see you like the color Blue," but I am not sure what a general case would be for this. Perhaps simply repeating what the system has learned about the user that could help with the next step? Using consistent icons, color coding. A link to My Account, maybe?
:-Flexibility and efficiency of use (Noreen: heuristic) -This heuristic calls for Accelerators that help expert users speed up the interaction and allows the users to tailor frequent actions. A trusted process may be better slowed down, but registered (non-anonymous) users may prefer to skip past certain steps.
::-Allow frequent users to save preferences.
::-Allow users to skip non-essential steps or data inputs.
::-Map inputs to local law, if a datapoint is illegal to ask for in a user's country, don't make it required for that user.
:-Help users recognize, diagnose, and recover from errors (Noreen: heuristic)
::-As above, clear confirmation messages and restating inputs before completing the next action.  
::-Allow user to delete session information and start over.
:Help and Documentation (Noreen: heuristic)
::-Link to help text explaining what the states mean.
::-Examples: Definition of the Trustmark is presented sufficiently well so that user can make an informed consent decision. Help documentation page for the entire process. Link to help for each input item requested. Help button next to any control that initiates an action, etc.
:-The objective is that users can securely know the identity of the web sites and the status of the current interaction - need to be reoriented to what the user sees and understands. (Tom)
:-Since browsers all currently display an indicia of security provided by EV-certificates, we would like to use EV-certificates for user validation of the service provider’s web site. (Tom)


'''3) HL Requirement: The system shall make reasonable accommodations to be accessible to as many users as is feasible and should be universally accessible.(ARR)''' (Category: Accessibility for all)
'''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


:-All relying parties and identity providers, when feasible, provide access to and use of information and data that is comparable to the use and access by those who are individuals without disabilities. (Ellen)
'''3) HL Requirement, USABLE-3: Information presented to USERS [[UXC_Dictionary#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)
::-All IDESG compliant sites will provide all feasible functionality to any user with a compatible internet connected device as that available to fully functional individuals.
:•  Instructions for use of the system should be visible or easily retrievable whenever appropriate.  <br>                                                                                              :•  Help and documentation information should be easy to search, focused on the users' task, listing concrete steps to be carried out, and be concise.
::-Service providers provide access, when feasible, to all users that is comparable to access by individuals without disabilities.
:•  Platform conventions for words, actions, and situations are consistent across the platform.
:-Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. (Jim: applicable principles)
        o Example: Users should not have to wonder whether different words, situations, or actions mean the same thing across the platform.
:-All indicia of trust or security (for example a Trustmark) must be clickable which will take you to a EV certified web side for that trust mark which will specifically report on whether the referring web site is verified. Now it is possible to spoof the referring web site, to the verifying site must be quite plane as to which site is protected. (Tom)
:•  The system should speak the users' language, following real-world conventions and making information appear in a natural and logical order.
::-Noreen suggests: This might be an appropriate place to include Ann's ethics and capabilities issue, since Accessibility is a human rights issue. It could state that the system should make reasonable accommodations to be accessible and sensitive to the rights and capabilities of as many users as is feasible. Could then show examples of user choices that might be affected by capability issues and a link to Ann's citations.
        o Example: Systems should use words or phrases and graphics or icons familiar to the user rather than system-oriented terms.
::-"The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency."
        o Example: although "privacy enhancing technology" is widely in use in industry, research suggests that "privacy protection" is more readily understood and used 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, understandable and concise definitions.
::• If standard definitions are available, they should be used.
:•  The design of the website should eliminate information that is irrelevant or rarely needed.
::• Layout and look/feel/branding, in addition to language, should also eliminate information that is rarely needed.


'''4) HL Requirement: The system should have a way to collect user feedback that shall be privacy enhancing(ARR), while conforming with the other high level requirements.''' (Category: Response to user feedback)
'''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)


:-All entities may only gather feedback from users on site usability that shall be privacy enhancing. adjust the site design in response. (ARR)(Ellen)
:• Systems should provide clear and easy to use pathways to help users recognize, diagnose, and recover from user-made errors.  <br> 
:-The system should always keep users informed about what is going on, through appropriate privacy enhancing feedback within reasonable time. (ARR) (Jim: applicable principles)
::• 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. <br>                                                                                               
::• 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. <br>
::• 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 and present a pathway for redress. <br>
::• 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. <br>                             
:• Entity's systems should allow users the choice to proceed anonymously, pseudonymously or with any chosen / assigned identity where appropriate. <br>
:• Entity's systems should allow the user choice and clear options for changing the status of their identity. For example: switching to anonymous browsing.<br>
:• Information users need to make decisions should be readily available and transparent to the user.<br>
: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.<br>                                                               
:• 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.<br>                                                                                                                                                                                                                              :• Clear pathways should exist for users to procure desired services. <br>
::• The user should be presented with pathways to the identity service they desire, such as: privacy options, identity caching, etc. <br>     
:• 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)'''. See Portability requirement.<br>
                                             


'''5) HL Requirement: The system should provide opportunity for redress: an easy way for users to report errors, complaints, etc while preserving user privacy.(ARR)'''
'''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)


:-Noreen: I am still having some trouble understanding the difference between feedback in 4 and 5. They both seem to show instances in which users are contacting the providers directly to provide critical feedback, for example via an email, survey, or contact us form. User feedback could also be understood to mean any input or action (e.g., click a link, create a profile, agree to terms, etc) by the user while using the system and the data collected on those actions. If it were expanded then some of the heuristics I noted under HL 2 might actually fit here. I don't want to muddy it up too much thought so perhaps some clarification is all that is needed.
:• Entities should review all accessibility standards and apply what they deem feasible to their sites based upon their legal and regulatory environment.
:-tomj: I would like to see this restructured to giving the user access to data that is held about them and have the ability to request changes or deletions to the data. Data in this case includes both data about the user and transactional data about interchanges with the user.
:• 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.
:-Ellen: Privacy already has a requirement re: redress. Is this one distinct enough? Privacy's requirement says: "Organizations shall provide effective redress mechanisms for, and advocacy on behalf of, individuals who believe their rights under these requirements have been violated." with guidance: "Organizations shall provide individuals the source of any verification or information that leads to an eligibility decision. If individuals seek redress, they must be provided with a mechanism to dispute or change erroneous information at the source of the information."
:• All IDESG compliant sites should provide all feasible functionality to any user with a compatible internet connected device as those available to individuals without disabilities on various devices or note that some functionality may be missing.
:-tomj: I had no idea what this high level requirements was even addressing until this discussion. UX requirements need to address UX, not some abstract concepts that cannot be used in the evaluation of a provider web site. Let's stick to what we do - talk about the UX itself.<br>
:• Users with disabilities should have access to documentation tailored to their needs, as is feasible.                                           
:• User Centered Design that accounts for accessibility issues should be used whenever possible.                                                                                                               
:• The specific requirements applicable to particular vertical industries  (health, finance,  etc.) should also be reviewed and applied when relevant.
:•  Some existing standards and regulations include:
::•  Section 508 contains information about accessibility. https://www.section508.gov/
::•  For example, see ISO 9241 (2010) "Human-centred design processes for interactive systems" and ISO/IEC 40500 (2012) Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.0


'''6) HL Requirement: Where interactions with users exist or are expected, and user requirements standards exist, users should have structured opportunities to document and express their requirements before interacting with Service Providers in online transactions. The user should receive a response to their requirement from the provider early on in the interaction. (eg. Do Not Track, link?) '''
'''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.'''
::This requirement is in alignment with the NSTIC Guiding Principle #32 "Organizations shall utilize identity solutions that are simple to understand, intuitive, easy-to-use, and enabled by technology that requires minimal user training. Speaking in the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. These expressed user conventions, making information appear in a natural and logical order."
 
<br>
:• All members [NOTE: check term for requirement’s users to make consistent] should provide a mechanism to gather feedback at regular intervals from users on site usability, adjusting the site design in response when appropriate.<br>
'''7) HL Requirement: User shall(should) see persistent methods for choosing and communicating their unique requirements (state, claim and promote) about their attributes and how they are used. Users should see good-faith responses from an organization about how these requirements will be treated, before agreeing to share their attributes.''' (Category: Clarity of pathways, options, solutions; Usable Language)
:• Users should be provided equitable choices where possible around the mechanisms they can use to express their feedback to entities. Parameters, risks and benefits for those choices should be clear to the user.
:: This requirement is in alignment with the NSTIC Guiding Principles and FIPPS: "NSTIC requires that service providers abide by the Fair Information Practice Principles (FIPPs) to ensure that people will be able to trust that their personal data are handled fairly, that they are informed about how their data will be used, have meaningful choices, and that checks and balances are in place to hold providers accountable for following a standard set of best practices."
:• 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: HL Requirement, USABLE-7: Wherever public open STANDARDS or legal requirements exist for collecting user requirements requests, entities conducting digital identity management functions MUST offer structured opportunities for USERS to document and express their interface and accessibility requirements these requests, early in their interactions with those functions. Entities MUST provide a response to those user requirement communications requests 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. Website USER do-not-track requests are an example of a USER request. An example of a site that handles responses to Do Not Track (DNT) requests in this manner is Medium.com which sends a single popup to new users, whether or not they are registered, about how they will handle the DNT request.
:• 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 User Experience mitigation includes using pop-up boxes or email responses to user requests. Links to information regarding additional use should provide adequate time for users to read the information presented to them.                                                                       
:• The entity gathering requests should state whether identity information is being used, and if so, the user should be notified. Please note that the IDESG Privacy Requirements apply to these interactions and the data they generate.
:• More information about Do Not Track can be found at these links:
::• FTC website on Do Not Track:  https://www.ftc.gov/news-events/media-resources/protecting-consumer-privacy/do-not-track
::• Do Not Track standard work at the WC3: http://www.w3.org/2011/tracking-protection/
 
'''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. <br>                                                               
:• Suggested ways for User Experience 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. <br>                                                       
:• Entities should state clearly in an easy to find manner to users, whether identity information is being used.                   
:• Special attention should be paid to the unique dynamics and vulnerabilities for users around attribute exchanges, particularly toward transparency of communications.
:• See the related USER-requirements-gathering processes described in USABLE-7.
 
'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''
:• Portability. -- The UXC doesn't feel that standardization of this topic is mature enough at this time for Portability to be an IDESG requirement.
 
:• The term "account portability" means the ability for a USER to move to a different service provider to provide registration, credentialing and authentication services, and to authorize the transfer of account information and attributes from an original service provider to a new, chosen provider.  Portable identity data should include the following types of information: registration information, credentials, attributes, preferences, and associated accounts.
:• Portability of data should include simple, easy to understand ways for USERS to receive their data in a structured format that allows the USER to reuse the data with a new provider, or simply read it within standard, commonly used programs.
'''Is this from a different section?'''
 
'''7) HL Requirement, INTEROP-9: Entities MUST provide effective mechanisms for redress of complaints or problems arising from identity transactions or the failure of the entity to comply with the IDESG Baseline Requirements. These mechanisms MUST be easy for USERS to find and access.'''
 
:• All IDESG members should provide a mechanism for redress and include the ability to correct or otherwise address any issues an USERS may have.
:• Pathways for redress should be clear and available to the user throughout the process.
:• Redress mechanism should be considered must-see-this-first information in a first encounter and then provided as appropriate to the USER in a consistent manner thereafter.
:• Consult USABLE-4 supplemental guidance for additional consideration that applies to Redress.
:• Consult the UXC Resources page located here for examples: https://www.idecosystem.org/wiki/UXC_resources 
 
Suggested addition in italics for Privacy's supplemental:<br>
EFFECTIVE in this requirements means use of the redress mechanism will result in a timely ''correction of errors,'' resolution of the dispute or complaint and the process shall not be overly burdensome or complex.<br>
==References==
 
[[Category:User Experience]]
[[Category:Notice]]

Latest revision as of 16:18, 27 May 2020

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 Dictionary page located here for examples of UXC definitions of terms in these requirements and supplemental guidelines: https://www.idecosystem.org/wiki/UXC_Dictionary
• The term "user-centric" design is a key tenet and requirement of the IDESG founding document: the National Strategy for Trusted Identities in Cyberspace (NSTIC) dated April 15, 2011. This term is further described in the Appendix A and is a common term in the User Experience domain.

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 UXC_Dictionary#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, listing 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 or phrases and graphics or icons familiar to the user rather than system-oriented terms.
       o Example: although "privacy enhancing technology" is widely in use in industry, research suggests that "privacy protection" is more readily understood and used 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, understandable and concise definitions.
• If standard definitions are available, they should be used.
• The design of the website should eliminate information that is irrelevant or rarely needed.
• Layout and look/feel/branding, in addition to language, should also eliminate information that is rarely needed.

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)

• 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 and present a pathway for redress.
• 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 where appropriate.
• 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 they desire, such as: privacy options, identity caching, etc.
• 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). See Portability requirement.


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 should provide all feasible functionality to any user with a compatible internet connected device as those available to individuals without disabilities on various devices or note that some functionality may be missing.
• Users with disabilities should have access to documentation tailored to their needs, as is feasible.
• User Centered Design that accounts for accessibility issues should be used whenever possible.
• The specific requirements applicable to particular vertical industries (health, finance, etc.) should also be reviewed and applied when relevant.
• Some existing standards and regulations include:
• Section 508 contains information about accessibility. https://www.section508.gov/
• For example, see ISO 9241 (2010) "Human-centred design processes for interactive systems" and ISO/IEC 40500 (2012) Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.0

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 members [NOTE: check term for requirement’s users to make consistent] should provide a mechanism to gather feedback at regular intervals from users on site usability, adjusting the site design in response when appropriate.
• Users should be provided equitable choices where possible around the mechanisms they can use to express their feedback to entities. Parameters, risks and benefits for those choices should be clear to the user.
• 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: HL Requirement, USABLE-7: Wherever public open STANDARDS or legal requirements exist for collecting user requirements requests, entities conducting digital identity management functions MUST offer structured opportunities for USERS to document and express their interface and accessibility requirements these requests, early in their interactions with those functions. Entities MUST provide a response to those user requirement communications requests 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. Website USER do-not-track requests are an example of a USER request. An example of a site that handles responses to Do Not Track (DNT) requests in this manner is Medium.com which sends a single popup to new users, whether or not they are registered, about how they will handle the DNT request.
• 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 User Experience mitigation includes using pop-up boxes or email responses to user requests. Links to information regarding additional use should provide adequate time for users to read the information presented to them.
• The entity gathering requests should state whether identity information is being used, and if so, the user should be notified. Please note that the IDESG Privacy Requirements apply to these interactions and the data they generate.
• More information about Do Not Track can be found at these links:
• FTC website on Do Not Track: https://www.ftc.gov/news-events/media-resources/protecting-consumer-privacy/do-not-track
• Do Not Track standard work at the WC3: http://www.w3.org/2011/tracking-protection/

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 User Experience 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.
• Entities should state clearly in an easy to find manner to users, whether identity information is being used.
• Special attention should be paid to the unique dynamics and vulnerabilities for users around attribute exchanges, particularly toward transparency of communications.
• See the related USER-requirements-gathering processes described in USABLE-7.

OTHER ADDITIONS FOR 1.2 REQUIREMENTS

• Portability. -- The UXC doesn't feel that standardization of this topic is mature enough at this time for Portability to be an IDESG requirement.
• The term "account portability" means the ability for a USER to move to a different service provider to provide registration, credentialing and authentication services, and to authorize the transfer of account information and attributes from an original service provider to a new, chosen provider. Portable identity data should include the following types of information: registration information, credentials, attributes, preferences, and associated accounts.
• Portability of data should include simple, easy to understand ways for USERS to receive their data in a structured format that allows the USER to reuse the data with a new provider, or simply read it within standard, commonly used programs.

Is this from a different section?

7) HL Requirement, INTEROP-9: Entities MUST provide effective mechanisms for redress of complaints or problems arising from identity transactions or the failure of the entity to comply with the IDESG Baseline Requirements. These mechanisms MUST be easy for USERS to find and access.

• All IDESG members should provide a mechanism for redress and include the ability to correct or otherwise address any issues an USERS may have.
• Pathways for redress should be clear and available to the user throughout the process.
• Redress mechanism should be considered must-see-this-first information in a first encounter and then provided as appropriate to the USER in a consistent manner thereafter.
• Consult USABLE-4 supplemental guidance for additional consideration that applies to Redress.
• Consult the UXC Resources page located here for examples: https://www.idecosystem.org/wiki/UXC_resources

Suggested addition in italics for Privacy's supplemental:
EFFECTIVE in this requirements means use of the redress mechanism will result in a timely correction of errors, resolution of the dispute or complaint and the process shall not be overly burdensome or complex.

References