February 6, 2015 UXC Meeting Page
User Experience Working Meeting February 6, 2015
Mary Hodder
Ann Racuya Robbins
Jim Zok
Ellen Nadeau
Mary added three requirements from the Privacy Committee into the UXC requirements spreadsheet. These are the three requirements that fit 7, 18 and 21 that what UXC requirements might be included. Agenda: Talk about each requirement and talk about core functions.
Tom Jones wrote up proposal for subject matter help, mostly likely through OASIS, to take our requirements and go and talk with experts for a usability study. Mary will share with UXC.
Paul Knight and Scott David – Mary had a conversation with them in terms of UXC requirements – current state of the industry and NSTIC requirements vs aspiration requirements. They discussed controls and criteria. Are there some requirements that are not currently implemented by a company, but will be. How do we give them metrics that will adjust for shall vs should or aspirational vs what they can do right now. We could id requirements right now, vs. jurisdictional requirements vs. aspirational, but have no jurisdictional requirements. We might make a third distinction where a particular requirement is jurisdictional for example. The guideline is aspirational and is required in some places. Define users: UXC users are end user – human users – in a relying party – or somewhere else. We are addressing human users. That is probably something we ought to have a tab for this, but also to potentially in these columns, how we apply the requirements – we might talk about an end user. Get specific. They also encouraged us to give implementation specific requirements. The Privacy Committee asked us about giving them help with the three requirements Mary copied in; we might give some implementation requirements. They said we might include links to best practices. We have a reference document for UXC, so we might want to reference a specific area of a specific reference item. They also discussed is in reference to best practices - is the notion that the “shall” should be auditable (for our metrics). Distinction of Security and privacy discussed. Security is about institutions. Privacy where individuals want control of some piece of information they are going to share or not to share. How could we broaden this definition? What if we created a graph and called out UXC issues around privacy and security around organizations vs individuals.
Paul and Scott liked the UXC notes/comments. We might pull some of those notes and format into language that will help a developer. These comments in the Specific controls, criteria or additional information section of the spreadsheet (column K) are from notes that Ellen and Suzanne included that were on the wiki.
Management Council meeting on Tuesday discussed the timing of when requirements are due; early to mid-March. Mary wants to schedule two or three more working sessions to get the requirements finished.
On agenda today – address the columns look at how the requirements are applied and what stage. Look at Privacy requirements again and look at the metrics.
Requirement #1: Information presented to users should be in plain language, which is clear and easy to understand.
User centered design - puts into focus the lack of. It refocuses design process. Who are we designing for? Developers? We need to have conversation and needs to be implemented without any grounding. To what extent could we integrate the user centered design to help answer questions discussed earlier. Maybe it belongs in the Metric area. Paul and Scott talk about building usability concerns early, you do it before coding. This requirement needs to be part of registration process. Do we direct people to other resources section?
Should we have some overall building guides and process? Mary will address with Paul and Scott. As part of overarching, both privacy and usability should be designed into the front of the progress; too late to add in later. This should be preamble for all requirements.
To what extent did you work directly with users at each stage? Should be measureable. We are trying to get things into requirements that could be measured and audited and verified.
Security requirement has one high level requirement. “Service providers in the ecosystem follow recognized information security standards, frameworks, and/or appropriate practices.” We could include something like this and the supplemental guidance could point to more resources. UXC could add a similar requirement too. Mary edited requirement from a UXC perspective (as #8) “Service providers in the ecosystem follow recognized usability and user centric design, standards, frameworks, and/or appropriate practices. UXC team will revisit.
Notes section (Column K): Whatever notes we have here in this column apply to all phases. UXC agreed to include check marks in columns D, E,F,G,H for Requirement #1.
Requirement #2: All choices, pathways, and solutions should be available and clearly identifiable by the user.
Mary included check marks in columns D, E,F,G,H. The note: “When initially choosing an identity provider at an RP site, the available options are clearly presented so that a user can make an informed decision.” Was changed to: When a new end user chooses an identity provider, the available options are clearly presented so that an end user can make an informed decision.
Next bulleted note: When a new user visits an RP site that requires identity. .. Was changed to: When a new user visits a site that requires identity…
Requirement #3: The system shall make reasonable accommodations to be accessible to as many users as is feasible.
Mary put check marks in columns D, E,F,G,H.
Went to Section508.gov
Universally accessible with fewer barriers is more palatable. International convention is 1 of 5 languages.
Added new note in Column K: User Centered Design shall be used whenever possible. Added more clarification to Column J: Section 505, in particular Section 1194.1 Purpose Requirement #4: The system should have a way to collect user feedback on site usability, while conforming with the other high level requirements.
Mary put check marks in columns D, E,F,G,H.
Requirement #5: The system should provide opportunity for redress: any easy way for users to report errors, complaints, etc. while preserving user privacy.
Security has this in their requirements.
Column K: All IDESG members should provide a mechanism to gather feedback from user.
Requirement #6: Where user requirements standards exist, users should have structured opportunities to document and express their requirements before interacting with Service Providers in online transactions.
Picked up next meeting.