Talk:UXC Requirements and Guidelines for TFTM

Input by Ellen

Looking at the examples we received from the security and privacy committees, which are both farther along in requirements development, Suzanne and I came up with 4 high-level UX requirements as a starting point to spur discussion.

1) When choosing an identity provider at an RP site, the available options are clearly presented so that a user can make an informed decision.

    Alternative wording:
    - 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
          slow 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 to the RP.

2) All organizations regularly gather feedback from users on site usability and adjust the site design in response.

3) 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.

   Alternative wording:
    -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.
   -Service providers provide access, when feasible, to all users that is comparable to access by 
     individuals without disabilities.

4) Clear pathways exist for users to procure desired services.

   Alternative wording:
    - The user can find the path to the identity service that they desire, such as: privacy options, identity caching, etc.

Additions by Jim Zok:

5) 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. -- tj 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.

6) Organizations shall utilize identity solutions that are simple to understand, intuitive, easy to use, and enabled by technology that requires minimal user training.

7) Platform conventions for words, actions and situations are consistent across the platform. (Edited version of an "applicable principle" from other doc)

8) Error messages should be expressed in plain language--no codes and indicate clearly the problem and constructively suggest a solution. (Edited version of an "applicable principle" from other doc)

Jim also suggested including the "applicable principles" from the previous document below our requirements. Please see these below (minus the two principles included above as numbers 7 & 8).

• The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

• Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 


• 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. -- tj one example is "privacy enhancing technology", way too geeky, research show that "privacy protection" is better understood by real users.

• 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. -tj 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.

• Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 


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


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

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

• 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. -- tj 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

Additions by Tom Jones

Ideas for requirements - 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.

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

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

Note: Suzanne suggests moving the requirements up a level so that information on the level of participation in the identity ecosystem is clear to the user in case we don't adopt "trust marks". -- tj, point is not what the affordance is called, only that user can SECURLY know what providers and policies are in place and how to change them

I would also like to align the work of these requirements with the design pattern Common to any Internet Identity Ecosystem

Comments from Noreen

It would be helpful to frame the guidelines along an existing framework such as NNG's Usability Heuristics http://www.nngroup.com/articles/ten-usability-heuristics/ This will make it easier to see how each of the guidelines relate to one another and what usability problem each one is trying to solve.

I posted a number of suggestions in an email to Tom back in September regarding the Trustmark Evolving Design Pattern. Some of these may be relevant to all of the design patterns and general guidelines for implementing trustmarks.

Heuristic: Visibility of system status (covered by HL 2)

• 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 the theNounProject.com for icons that are relatively universal

• http://thenounproject.com/search/?q=trust
• http://thenounproject.com/search/?q=privacy
• http://thenounproject.com/search/?q=anonymous (this one is funny; may not be usable...)

Heuristic: Match between system and the real world (covered by HL 2)

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

Heuristic: User Control and Freedom (covered by HL 2)

• 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

Heuristic: Consistency and Standards (covered by HL 2)

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

Heuristic: Error Prevention (covered by HL 2, could also be HL 5 if that requirement is expanded to include notification of errors as well as reporting of errors)

• 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?"

Heuristic: Recognition vs Recall (covered by HL 2, could be covered by HL 4 if what you mean by feedback includes any kind of user action or input, not just collecting critical feedback or help requests)

• Jim touches on this above. 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?

Heuristic: Flexibility and efficiency of use (covered by HL 2. again could also be HL 4 if feedback includes collecting and responding to user action and inputs)

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

Heuristic: Aesthetic and minimalist design

• Dialogues should not contain information which is irrelevant or rarely needed. (Oops. This may be where the negative wording came from.)

Heuristic: Help users recognize, diagnose, and recover from errors (covered by HL 2)

• As above, clear confirmation messages and restating inputs before completing the next action.
• Allow user to delete session information and start over.

Heuristic: Help and Documentation (covered by HL 2)

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

--Ann Racuya-Robbins (talk) 20:58, 10 November 2014 (UTC)

Additions by Ann Racuya-Robbins

A conversation for "social cooperation" must take place at the beginning of interactions. [[1]]

# The NSTIC Guided IDEF shall enable the recording of a machine readable natural language conversation between the Human User and the Service Provider(s) setting out the terms of agreement between the parties relating to the life-cycle (person) attribute management balancing human user and service provider requirements, desires, and benefits including the description, detailing and valuation of the monetization of human attributes with required user created limits, remedies and benefits. Said recorded machine readable natural language agreement shall form an access and benefits policy that can only be modified by a subsequent machine readable natural language conversational agreement.

# The NSTIC Guided IDEF shall establish the requirements for a CONOPS (Concept of Operations -- "a document describing the characteristics of a proposed system from the perspective of the user of a proposed system, and this can be qualitatively and quantitatively describes for all stakeholders) for life-cycle (person) attribute management aligned with the NSTIC principles and created from a bi-direction approach balancing human user and service provider requirements, desires, and benefits. The user should be able to also communicate their unique preferences (state, claim and promote) about their attributes and how they are used.

Categorization of Requirements & Guidelines (Ellen & Suzanne)

We went through the above requirements/guidelines, grouping them into categories. These categories might be helpful in determining the HL user experience requirements, then filling in sub-requirements and guidance as desired/necessary.

We’d like your feedback on the titles of the 4 main categories and the organization of requirements/guidelines throughout. Jim, Noreen, and Tom: we have not yet included all of the requirements/guidelines that you posted – we’re interested in your thoughts on what belongs in which category.

1) HL Requirement: Information presented to users should be in plain language, which is clear and easy to understand. Category: Usable language

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

2) HL Requirement: All choices, pathways, and solutions should be available and clearly identifiable by the user. (Category: Clarity of pathways, options, solutions)

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

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

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

-> 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 should make reasonable accommodations to be accessible to as many users as is feasible. (Category: Accessibility fo all)

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

-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.
-Service providers provide access, when feasible, to all users that is comparable to access by individuals without disabilities.

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

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

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.

4) HL Requirement: The system should have a way to collect user feedback, while conforming with the other high level requirements. (Category: Response to user feedback)

-> All organizations regularly gather feedback from users on site usability and adjust the site design in response. (Ellen)

->The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. (Jim: applicable principles)

5) HL Requirement: The system should provide an easy way for users to report errors, complaints, etc.

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.