UX Usability Requirements and Guidelines Working Document - Revision history

Tomjones at 16:18, 27 May 2020

2020-05-27T16:18:58Z

New page

'''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==

[[Category:User Experience]]
[[Category:Notice]]

Mary Hodder: formatting fix

2015-09-25T14:12:50Z

formatting fix

Mary Hodder: Updated Usable-7 Requirements Language per UXC meeting 9/24/2015

2015-09-25T14:11:43Z

Updated Usable-7 Requirements Language per UXC meeting 9/24/2015

← Older revision		Revision as of 14:11, 25 September 2015
Line 14:		Line 14:

	'''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)		'''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.		:• 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.
	:• Platform conventions for words, actions, and situations are consistent across the platform.		:• 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.		o Example: Users should not have to wonder whether different words, situations, or actions mean the same thing across the platform.
Line 64:		Line 64:
	:• 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		:• 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.'''		'''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.		:• 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.

Mary Hodder: updating supplemental to Usable-7 per UXC plenary working meeting

2015-09-24T17:03:48Z

updating supplemental to Usable-7 per UXC plenary working meeting

← Older revision		Revision as of 17:03, 24 September 2015
Line 66:		Line 66:
	'''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.'''		'''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. Website USER do-not-track requests are an example of a USER ~~requirement~~ request. An example of a site that handles responses to Do Not Track (DNT) ~~signals~~ 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.		:• 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.		:• 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 ~~requirement communications~~. Links to information regarding additional use should provide adequate time for users to read the information presented to them.		:• 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 ~~information~~ 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.		:• 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:		:• 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		::• FTC website on Do Not Track: https://www.ftc.gov/news-events/media-resources/protecting-consumer-privacy/do-not-track

Mary Hodder: 09/15/2015 UXC meeting updates to SG

2015-09-17T16:43:06Z

09/15/2015 UXC meeting updates to SG

Mary Hodder: correct extra period

2015-09-08T16:38:50Z

correct extra period

New page

'''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.
:• 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 IDESG compliant sites should provide a mechanism to gather feedback 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: 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. Website USER do-not-track requests are an example of a USER requirement 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 requirement communications. Links to information regarding additional use should provide adequate time for users to read the information presented to them.
:• The entity gathering information 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.

Mary Hodder at 16:50, 25 August 2015

2015-08-25T16:50:20Z

← Older revision		Revision as of 16:50, 25 August 2015
Line 92:		Line 92:

	'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''		'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''
	:• Portability. -- The UXC doesn't feel that standardization of this topic is mature enough at this time to be a requirement.		:• Portability. -- The UXC doesn't feel that standardization of this topic is mature enough at this time for Portability to be an IDESG requirement.

Mary Hodder: added notation about portability

2015-08-25T16:49:13Z

added notation about portability

← Older revision		Revision as of 16:49, 25 August 2015
Line 92:		Line 92:

	'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''		'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''
	:• Portability.		:• Portability. -- The UXC doesn't feel that standardization of this topic is mature enough at this time to be a requirement.

Mary Hodder: changed "must" to "should" in a few supplemental guidance lines

2015-08-25T16:47:50Z

changed "must" to "should" in a few supplemental guidance lines

Mary Hodder: Added INTEROP-7, supplemental guidance for Redress issues, and added suggestion for privacy SG.

2015-08-18T20:26:47Z

Added INTEROP-7, supplemental guidance for Redress issues, and added suggestion for privacy SG.

← Older revision		Revision as of 20:26, 18 August 2015
Line 36:		Line 36:
	::• 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>		::• 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>		::• 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. <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>		::• 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 users the choice to proceed anonymously, pseudonymously or with any chosen / assigned identity where appropriate. <br>
Line 71:		Line 71:
	::• FTC website on Do Not Track: https://www.ftc.gov/news-events/media-resources/protecting-consumer-privacy/do-not-track		::• 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/		::• Do Not Track standard work at the WC3: http://www.w3.org/2011/tracking-protection/

			'''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>

	'''USABLE-BP-A. RECOMMENDED ATTRIBUTE REQUIREMENTS QUERY		'''USABLE-BP-A. RECOMMENDED ATTRIBUTE REQUIREMENTS QUERY

← Older revision		Revision as of 14:12, 25 September 2015
Line 14:		Line 14:

	'''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)		'''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. <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.		:• 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.
	:• Platform conventions for words, actions, and situations are consistent across the platform.		:• 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.		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.		:• 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: 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.		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.		:• 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.		:• 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.		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.		:• 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.		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.		:• 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.		::• If standard definitions are available, they should be used.
	:• The design of the website should eliminate information that is irrelevant or rarely needed.		:• 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.		::• Layout and look/feel/branding, in addition to language, should also eliminate information that is rarely needed.

← Older revision		Revision as of 16:43, 17 September 2015
Line 50:		Line 50:
	:• Entities should review all accessibility standards and apply what they deem feasible to their sites based upon their legal and regulatory environment.		:• 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 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.		:• 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.		:• 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.		:• User Centered Design that accounts for accessibility issues should be used whenever possible.
Line 60:		Line 60:
	'''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.'''		'''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.<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>
	:• 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.		:• 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		:• 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
Line 66:		Line 66:
	'''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.'''		'''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. Website USER do-not-track requests are an example of a USER requirement request.		:• 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 requirement request. An example of a site that handles responses to Do Not Track (DNT) signals 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.		:• 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 requirement communications. Links to information regarding additional use should provide adequate time for users to read the information presented to them.		:• Suggested ways for User Experience mitigation includes using pop-up boxes or email responses to user requirement communications. Links to information regarding additional use should provide adequate time for users to read the information presented to them.

← Older revision		Revision as of 16:47, 25 August 2015
Line 49:		Line 49:
	:• Entities should review all accessibility standards and apply what they deem feasible to their sites based upon their legal and regulatory environment.		:• 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 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 those available to individuals 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.
	:• Users with disabilities should have access to documentation tailored to their needs, as is feasible.		:• 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.		:• User Centered Design that accounts for accessibility issues should be used whenever possible.
	:• Additional industry requirements, should when feasible be reviewed and used. They include but aren't limited to health, finance, universal accessibility, etc.		:• Additional industry requirements, should when feasible be reviewed and used. They include but aren't limited to health, finance, universal accessibility, etc.
	:• Some existing standards and regulations include:		:• Some existing standards and regulations include:
Line 67:		Line 67:
	:• 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.		:• 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 User Experience mitigation includes using pop-up boxes or email responses to user requirement communications. Links to information regarding additional use should provide adequate time for users to read the information presented to them.		:• Suggested ways for User Experience mitigation includes using pop-up boxes or email responses to user requirement communications. Links to information regarding additional use should provide adequate time for users to read the information presented to them.
	:• The entity gathering information should state whether identity information is being used, and the user ~~must~~ be notified.		:• The entity gathering information should state whether identity information is being used, and if so, the user should be notified.
	:• More information about Do Not Track can be found at these links:		:• 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		::• FTC website on Do Not Track: https://www.ftc.gov/news-events/media-resources/protecting-consumer-privacy/do-not-track
Line 88:		Line 88:
	:• 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>		:• 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>		:• 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 ~~must~~ state clearly in an easy to find manner to users whether identity information is being used.		:• Entities should state clearly in an easy to find manner to users, whether identity information is being used.
	:• Special attention ~~must~~ be paid to the unique dynamics and vulnerabilities for users around attribute exchanges, particularly toward transparency of communications.		:• Special attention should be paid to the unique dynamics and vulnerabilities for users around attribute exchanges, particularly toward transparency of communications.

	'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''		'''OTHER ADDITIONS FOR 1.2 REQUIREMENTS'''
	:• Portability.		:• Portability.
	~~:• Redress.~~