UX Usability Requirements and Guidelines Working Document

From IDESG Wiki
Revision as of 15:15, 9 June 2015 by Mary Hodder (talk | contribs) (updated requirements to reflect UXC requirements turned into FMO June 1, 2015 and latest guidelines below each req)
Jump to navigation Jump to search

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.

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: https://www.idecosystem.org/wiki/UXC_resources
- TO add other references??



-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, 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.

- ??

3) HL Requirement, USABLE-3: Information presented to USERS in digital identity management functions MUST be in plain language that is clear and easy for a general audience or the transaction's identified target audience to understand. (Category: Clarity of pathways, options, solutions) • Instructions for use of the system should be visible or easily retrievable whenever appropriate. • Help and documentation information should be easy to search, focused on the users' task, list concrete steps to be carried out, and be concise. • Platform conventions for words, actions, and situations are consistent across the platform. 

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

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

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

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

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

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

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

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

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

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

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

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

• Organizations shall 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. • 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 needs to 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 provide users with a confirmation option before they commit to a pathway action. • If feasible, the choice to proceed anonymously, pseudonymously, or with a verified identity should be presented to the user. • Users should be able to make decisions with minimal user training. • If it is feasible for the business objectives of the system, the user should clearly be presented options for changing the status of their identity. For example: switch to anonymous browsing. • The identity of the system needs to be clearly visible and understandable to users at all times. ---------- 

• When a new end-user chooses an identity provider, the available options are clearly presented tso that an end user can make an informed decision.  When a new user visits an RP site that requires identity,  the end 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.                                                                                                                                                                                                                                  • Clear pathways exist for users to procure desired services. 
       o The user can find the path to the identity service that they desire, such as: privacy options, identity caching, etc.                                                          • IDESG needs to define what constitutes a pathway.

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)

• All relying parties and identity providers, when feasible, should provide equivalent access to and use of information and systems to individuals with disabilities that is comparable to the use and access by those who are individuals without disabilities.
• 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.
• Users with disabilities should have access to documentation tailored to their needs, as is feasible.
• User Centered Design shall be used whenever possible.
• Additional industry requirements, should when feasible be reviewed and used. They include but aren't limited to (health, finance, etc ??, Nielsen? Universal accessibility?)

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 members should provide a mechanism to gather feedback from users on site usability, adjusting the site design in response when appropriate.

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.

• "Collecting personal data" would mean that a provider or entity was interacting with users directly. • As a general principle, consent choices or other similar must-see-this-first information should be exchanged in a first encounter, and then honored in and presented in a consistent manner thereafter. • Suggested ways for UX mitigation include pop-up boxes or email responses to requests. Links to additional use information and adequate time to read should be included in the process for end users.

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

USABLE-BP-A. RECOMMENDED USER CENTRIC DESIGN Entities conducting digital identity management functions SHOULD apply appropriate user-centric design principles and methodologies to the design, evaluation and maintenance of the communications, interfaces, policies, data transactions and end-to-end processes they offer to USERS.

USABLE-BP-B. 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.

• Lightweight methods for adhering to 6&7 by a vendor or company • As a general principle, consent choices or other similar must-see-this-first information should be exchanged in a first encounter, and then honored in and presented in a consistent manner thereafter. • Suggested ways for UX mitigation include pop-up boxes or email responses to requests. Links to additional use information and adequite time to read should be included in the process for end users.

-QUESTIONS: • IDESG needs to define what constitutes an interaction and what 3rd party eavesdropping is. Also, IDESG would need to state whether identity information is being used, whether the user should be notified.
• Attention paid to the unique dynamics around attribute exchanges.
Retrieved from "https://wiki.idesg.org/index.php?title=UX_Usability_Requirements_and_Guidelines_Working_Document&oldid=9218"