uswds / uswds-team Goto Github PK

User story: As a PM, I want to guide and streamline the issue management process so that our team is working smoothly in an agile framework.

This story will help to create consistency with the agile methodology and provide guidance as to where, when, and how work is tracked.

Acceptance criteria:

• Approved documentation of issue management guidance
• Archived to appropriate location for ease of reference
• Plan for a revisit and revision for continued improvement

Tasks to Complete:

• Research current agile process and determine issues and improvements
• Research current issue content process
• Research best way to treat epics, stories, tasks, subtasks with in Github.
• Determine best options on how to measure LOE
• Submit documentation for feedback and revisions

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Create a communication plan for Sample contract language. Review and approval of plan.
Draft Comms messaging
Plan should include:

• Create short post to cross promote on Digital.gov and in the Digital.gov newsletter
• Draft email and share with web managers listserv
• Draft Slack message and share on #uswds-public Slack
• Draft social promos and tweet from USWDS and Digital.gov

DoD

• USWDS review and approval
• Comms review and approval 2/3
• follow up w execution of comms plan #60

Read background materials:

• Design guidelines in Section 11 of Guidelines for GSA's Digital Presence🔒
• Initial categorization of GSA sites by type🔒
• Some recent user research🔒

Why we're doing this

Designers and developers need to provide contextual awareness of where a user is in a websites and provides users a simple way to navigate back to page higher in the site hierarchy.

The Breadcrumb component is available in pretty much every design system🔒 and is a baseline expectation for a design system like USWDS.

Related issues and documentation

TK

How we'll know this new component is done

Clear

• Include a well-formed user story, preferably one that connects to research findings
• Use existing code as much as possible
• Include only the code necessary for the component
• Affect as few other components as possible
• Use USWDS code style
• Use only USWDS design tokens, mixins, and functions
• Use the same design patterns to solve the same problems

Accessible

• Add component-based tests to automated testing
• Pass automated CI accessibility review (aXe)
• Pass semi-automated accessibility review like Accessibility Insights
• Pass WCAG 2.1 review
• Use screen reader and keyboard accessible markup
• Make scrollable elements focusable for keyboard users
• Assure markup describes a logical structure/outline

Resilient

• Use a mobile-first design methodology
• Stress-test with edge cases (and document these variants in the library)
• Outline contexts where this component might appear (and add these templates to the library)
• Perform critical tasks with low bandwidth and unreliable CSS load
• Perform critical tasks when JavaScript does not load
• Document and addresses any new package vulnerability
• Pass Snyk scan
• npm audit: Contain no Critical vulnerabilities
• npm audit: Contain no High vulnerability standard dependencies
• Justify any High vulnerability dev dependencies
• Provide a print stylesheet
• Autoprefix with: "> 2%", "Last 2 versions", "IE 11"
• Test back to IE11 with a cross-platform testing tool
• Include functional unit tests

Evidence-based

• Document internal or external developer usability test findings (and link to the documentation)
• Document internal or external end-user usability test findings (and link to the documentation)
• Collect links and references to any sources used to create this component in the documentation
• Perform landscape analysis of existing government examples of the component
• Compare component features with landscape to assure we're meeting expectations

Documented

• Include a guidance page on the uswds-site linked to the new uswds work branch via package.json
• Include the following sections in site documentation:
  • Name
  • Description
  • Example
  • Component code
  • When to use
  • When to consider something else
  • Usability guidance
  • Accessibility guidance
  • Implementation guidance
  • When to consider something else
  • Resources
  • Package information
• Document any additions to USWDS settings on the settings page
• Create a component package that allows Sass to import only that component and its dependencies. See an example.
• Use plain language and explain any technical terms
• Document source code with comments
• Include a blog post that contextualizes the component work and explains what, why, and how of the component
• Content proofread with no typos or broken links

Why we're doing this

Designers need a card component to organize summarized materials, and present these summaries in a scannable, browsable format. A card pattern serves to:

• collect together related materials
• distinguish related collected materials from their context
• connect related collections as a "collection-of-collections"
• provide a simple followup action related to the collected content

The card component is available in pretty much every design system🔒 and is a baseline expectation for a design system like USWDS.

Related issues and documentation

Card prototype
Problem Statement
Initial Assumptions and Hypothesis
Landscape Analysis
Landscape Analysis of Existing Gov Solutions
Draft Card Principles
Initial build of card component
Site documentation for the card component
flex-fill not working in IE11

How we'll know this new component is done

Clear

• Include a well-formed user story, preferably one that connects to research findings
• Use existing code as much as possible
• Include only the code necessary for the component
• Affect as few other components as possible
• Use USWDS code style
• Use only USWDS design tokens, mixins, and functions
• Use the same design patterns to solve the same problems

Accessible

• Add component-based tests to automated testing
• Pass automated CI accessibility review (aXe)
• Pass semi-automated accessibility review like Accessibility Insights
• Pass WCAG 2.1 review
• Use screen reader and keyboard accessible markup
• Make scrollable elements focusable for keyboard users
• Assure markup describes a logical structure/outline

Resilient

• Use a mobile-first design methodology
• Stress-test with edge cases (and document these variants in the library)
• Outline contexts where this component might appear (and add these templates to the library)
• Perform critical tasks with low bandwidth and unreliable CSS load
• Perform critical tasks when JavaScript does not load
• Document and addresses any new package vulnerability
• Pass Snyk scan
• npm audit: Contain no Critical vulnerabilities
• npm audit: Contain no High vulnerability standard dependencies
• Justify any High vulnerability dev dependencies
• Provide a print stylesheet
• Autoprefix with: "> 2%", "Last 2 versions", "IE 11"
• Test back to IE11 with a cross-platform testing tool
• Include functional unit tests

Evidence-based

• Document internal or external developer usability test findings (and link to the documentation)
• Document internal or external end-user usability test findings (and link to the documentation)
• Collect links and references to any sources used to create this component in the documentation
• Perform landscape analysis of existing government examples of the component
• Compare component features with landscape to assure we're meeting expectations

Documented

• Include a guidance page on the uswds-site linked to the new uswds work branch via package.json
• Include the following sections in site documentation:
  • Name
  • Description
  • Example
  • Component code
  • When to use
  • When to consider something else
  • Usability guidance
  • Accessibility guidance
  • Implementation guidance
  • When to consider something else
  • Resources
  • Package information
• Document any additions to USWDS settings on the settings page
• Create a component package that allows Sass to import only that component and its dependencies. See an example.
• Use plain language and explain any technical terms
• Document source code with comments
• Include a blog post that contextualizes the component work and explains what, why, and how of the component
• Content proofread with no typos or broken links

• Create Interview Research Plan
• Create Interview Script
• Create intro email language
• Client review and approval

Task checklist
Link to interview research plan
Link to interview script

• Identify interview subjects
• Do not add interview subject names to GitHub issues or Gdocs. Protect identity by using anonymous pseudonyms.
• Send intro email to interview subjects, copy Ammie and Dan
• Identify interviewer & other attendees
• Schedule in Google Calendar, 45 minutes
• Ask for permission to record
• Create, share, and synthesize notes
• Capture findings
• Archive notes, archive recording

UX/CS recommendations: preliminary steps in updating product values. https://github.com/uswds/uswds-site/issues/977

• Schedule interviews
• Share out interview script
• Conduct interviews
• Consolidate themes/notes

DOD

• Summary of findings

August Monthly Call (8.20) fairly light due to outside presenter
Topics:
• 2.8.1 release review
• Any new site launches
Tasks:
• Pre activities: script submission and review
• Prep // run through meeting
• post activities (blogs, etc)

Tasks:

• Meeting to determine what to share. Scheduled 8.26.
• Schedule a reoccurring 30-min post call recap from 3:40-4 pm ET (Dan, Ammie, Jaimee, Katie, Allie goal: collect links and high level recap in post)
• @katieekline to develop post call gDoc for review
• Approval of message by client
• Share a recap of the call with links to a key resource or two in #uswds-public.

QA the USWDS questions for the customer loyalty survey and provide feedback🔒

Description: Anchor component is a complement to the footer. Its purpose is to provide a consistent way of presenting information and links that are required by federal policy. The Anchor Component is distinctly different from the footer. It has a simple, neutral default. Embedded within the component are best practice suggestions as to what links or information should be included.

Value: will add some nice consistency to how agencies link back to USA.gov.
Making the requirement that states that all gov sites need to link to USA.gov "official" in the USWSDS (with consistent language in both, English and Spanish) is fantastic. Other gov agencies won't have to worry about where exactly to put it, the verbiage and the style.

Issue info: This component has previously been developed by digital.gov. The Bixal team should complete discovery process to validate digital.gov or further develop a new prototype or new features.
Example: https://digital.gov/
Digital.gov Issue: GSA/digitalgov.gov#2351
USWDS Issue: uswds/uswds#3525

Acceptance Criteria

• All associated tasks and issues are complete:

• Discovery - #28

• Wireframe/Prototype - uswds/uswds#3565

• Content

• Build

• Test

• Release

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

We need to submit the Federalist site review questionnaire🔒 for the four production USWDS websites:

1. https://components.designsystem.digital.gov
2. https://designsystem.digital.gov
3. https://public-sans.digital.gov
4. https://v1.designsystem.digital.gov

Develop and add draft agenda to the gDoc, Spring 2020 Digital Experience Meetup.

The meetup is tentatively scheduled for Tuesday, June 2nd, 2020, and will be held virtually.

This week, we’re exploring what it means to promote continuity. See the draft gDoc 🔒.

Use the monthly call to update various sections of designsystem.digital.gov. Below is a link to a few options for how we might update some of the pages/content based on the June Monthly call.
https://docs.google.com/document/d/15lXC8nIfPwAXdr-Wzp7XNxDJEhPysBV699vKPgA7fyI/edit#

Gathering current state of analytics to create a baseline view and begin to formulate KPIs

• pull current analytics (google, DAP, search terms used)
• incorporate stakeholder findings
• formulate baseline KPIs measures
• formulate initial product values

DOD

• Vision Plan

Tasks to deprecate https://components.designsystem.digital.gov:

• JA - Inventory and crosswalk the components on components.designsystem.digital.gov to confirm they're on designsystem.digital.gov/components
• JA -Create issues to add any missing components to the USWDS site
• JM - Remove all links to the components subdomain from uswds-site
• AFF - Submit an issue in https://github.com/18F/dns/issues and ask them set up a 301 redirect from components.designsystem.digital.gov to designsystem.digital.gov/components
• AFF - Update #7, the issue that tracks our modernization punchlist, to mark this item as complete
• AFF - Update the GSA website inventory to list components as a redirect

Build Sites to Address the Entire User Journey
https://docs.google.com/document/d/1xp5eVLXWIUSEOzHdrPXYL4Jd7StWbLx_-w0yMRUnftM/edit#heading=h.uhqjgz9ylxby

User story:
As a UX specialist, I want to evaluate current personas so that I can either develop new personas and /or revise, validate existing personas.

This story is about the need to have accurate and updated persona information so that the team can better tailor content and customer experience to specific users of our product. Personas help define common user needs and bring them to the forefront of planning. They provide the team a shared understanding of users in terms of goals and capabilities and help keep our product user focused.

Updated personas will lay the foundation to fulfill product roadmap items such as, but NLT “getting started” content directed at specific users. This information will also inform a larger needs assessment surrounding site IA, content audit, and overall usability.

Existing Personas and Roadmap

Acceptance criteria:

• Documentation of key findings to include recommendations and next steps. What we know, what we need to know.
• Persona creation/development, revisions, and/or validations.

Tasks to complete:

• Synthesize and analyze user research tests, and any other existing information to
  develop key findings and recommendations
• Persona creation/development/updates
• Possible next steps with Katie

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Background

As an agency customer
I would like to see a Voluntary Product Accessibility Template (VPAT) for USWDS
So I know can evaluate the design system for accessibility

Section508.gov recommends generating a VPAT™ for any technology that’s intended to be marketed to the Federal government.

**Acceptance criteria **

• USWDS uses the VPAT™ to make specific statements in simple recommended language to demonstrate how its features and functional characteristics of meet the Revised 508 Standards.

Tasks to complete this issue

• Generate a VPAT for USWDS
• Publish information on the VPAT

Definition of done

• Acceptance criteria met

Update and validate site scanner information

Tasks

• QA spotlight data from August
• re-run site scanner
• QA updated spotlight data from September

AC

• Tasks complete

As a staff member at TTS
I would like to know more about USWDS
So I can understand how it applies to my work, contribute, and provide feedback

The upcoming 20.3 issue of UXPA Magazine will cover UX governance:

When designing experiences for our users, different disciplines merge into the equation. IT infrastructure, APIs, Data structures, Design Systems, Open and Dynamic repositories for continuous improvement, to name a few, come into our mind. We need to synchronize all of them building a governance framework that puts users in the center of the system. All of those who want to write about the topic are welcome to submit. We are looking for articles that cover the topic from different perspectives and disciplines.

Article proposals are due August 15, 2020. Visit http://uxpamagazine.org/information-for-authors/ for information on how to submit submittal.

Draft key points and a high-level overview of USWDS in gDoc🔒.

September monthly call (9.17)

USWDS 2.9.0
Improvements:
Added align-self utilities
Added accent-warm buttons
Added SHA-256 hash to zip release

Bug fixes
Disabled radio button styling
Secondary button active state
List alignment inside alerts
Proper styling of legends

Three new components
Identifier
Step indicator
Time Picker

Website updates:
USWDS fundamentals and getting started guide
Sample contract language for 21st century IDEA

Tasks:

• Pre activities: [script submission and review](Monthly call Script)
• [NA] possible re-record test
• Prep // run through meeting
• Post call sync
  Post call activities
• Release announcement
• develop post call recap announcement in gDoc template for review
• Share out call recap #uswds-public.

• Resource: Identifier Research Plan

Remediate the IAAF presentation🔒

Follow the tips in how to create accessible PPT documents including authoring guides, checklists and video series.

We are presenting at the 2020 Interagency Accessibility Forum (IAAF) on October 6 from 2-2:25. The format is a ~20 minute presentation followed by Q&A.

By September 10, we must send our presentation to Avis Ryan in OGP.

Topic
Embrace Accessibility and Build It Into Every Decision - 21st Century IDEA requirements are critical and necessary, but only the beginning. Accessibility is about real people who use our services. Everyone has a role to play in making federal websites and digital services accessible and inclusive. The U.S. Web Design System's Embrace Accessibility principle encourages teams to design generously and celebrate requirements as a set of constraints that help us create better products for all users. Accessibility affects everybody. Build it into every decision.

Panel Members
Ammie Farraj Feijoo, General Services Administration
Dan Williams, General Services Administration

Add updated information for USWDS in the FAS spreadsheet🔒 by COB October 8.

The instructions to use the sheet are in the Instructions tab. The data that was submitted for plans earlier this year is also pre-populated (as reference) in the sheet (Columns E and F).

See #7 for what's been done and what's left to do for the 4 USWDS websites.

Discuss approach to helping ASPA and associated agencies develop a strategy for adopting USWDS.

As a member of the USWDS product team,
I would like to see insights from the call data
So I can see trends over time and ensure the calls are valuable

Goal: better develop metrics and document process
• metrics: analyze rather than collect
• define goals
• set KPIs
• develop experiments to discover satisfaction--i.e. diversity across agencies
• Develop clear CTA
• Tighten up and document process

Finalize and present deck🔒

Here is a link to the main document.
https://docs.google.com/document/d/1Y1Sozh0AaFt-umWR2Sz_sjXrNZEAbmorBt-GmllivSk/edit#

Please review the items below:

• Link to recording on YouTube (not live yet)
• Link to captioning (which has been edited and custom timed with the YouTube video)
• Link to presentation
• Primary Resource Page
• Updates to Accessibility Pages

Robert Jolly's interview and notes are included as references, but we do not plan to post them. Sara just asked us to interview him for more background on the Trusted Tester program.

Background

As a USWDS customer
I would like to anticipate communication with USWDS on new component releases
So that I can understand the process and contribute feedback throughout

As a USWDS team member
I would like to follow a standard process to receive feedback from customers on new components throughout the lifecycle
So I ensure we're listening and taking customer needs and public user needs into account

This story is about documenting the process to get feedback on new components. We want to understand needs through the lifecycle from discovery to post-release:

• What agency teams need and for what public users
• What they would use the component for
• Existing research or work done by other teams
• Considerations for accessibility and usability
• Any applicable policies, standards, or guidelines that apply,
• Bugs in using the component
• Share successful implementations
• Further needs for improvements and customization options.

Acceptance criteria

• We have documented the process to get feedback on new components
• We have created some boilerplate language to collect feedback at each stage
• We have defined KPIs to measure effectiveness of our efforts to collect feedback
• A folder is created in Google Drive to collect the feedback and research
• The process is documented and findable in the wiki

Tasks to complete this issue

• Define the stages
• Review existing efforts to collect feedback, including from the 10x team
• Draft the high-level process
• Identify various touchpoints and channels, write boilerplate language, and define KPIs
• Schedule interviews with a few federal customers
• Analyze feedback and review the process
• Walk through topline with USWDS lead and validate to-be process
• Create gDrive folder
• Post to wiki

Definition of done

• Acceptance criteria met

Update the To check tab.

• Add two additional data sources
• Update data from site scanner

User story: As a PM, I want to standardize issue criteria, so that issues are detailed, clear and understandable to the entire team.

This story will create consistency across issues.

Acceptance criteria:

• Approved documentation of issue criteria guidance
• Archived to appropriate location for ease of reference

Tasks to complete:

• Research past issues for good examples
• Develop issue criteria
• Is there an existing template for guidance and SOP documentation?
• Submit for feedback and revisions and Approval

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

• Monthly call prep meeting 11/2
• Pre activities: [script submission and review]
• Prep // run through meeting
• Monthly call 11/19
• Post call sync 11/19
• Create post-call draft gDoc template for review and approval **NLT 11/23
• Create draft slack post announcement
• Add video chapter points into update when video is posted https://www.youtube.com/watch?v=r0H6CiP-FN0
• Share out call recap #uswds-public.

• Jaimee A.
• Chaz C.
• Justin S.
• Katie K.
• James M.
• Allie S.

scheduling internal meeting with Bixal and Dan and Ammie to discuss approach for meeting with ASPA product owner to discuss USWDS adoption

Global Accessibility Awareness Day (GAAD) is May 21. Draft some social posts🔒 on USWDS for GAAD.

Dependabot alerts for the week of Oct 27 - Nov 3

• All returns entered in POAM, ID# 010-028, new entries highlighted in yellow for review. Green highlight indicates returns that can be fixed. Four out of 19 returns can be resolved.
• Final Reviewer: Cross reference check with POAM, 2020-015, 2020-017, 2020-019, 2020-023
• PR for merge: uswds/luminance-tool#18

The Federal Chief Information Officer (CIO) Council Accessibility Community of Practice (ACOP) asked for recommendations for the upcoming Interagency Accessibility Forum (IAAF). Responses are due by 5/22/2020.

Each session will be a 45-minute discussion on the speaker’s area of expertise within accessibility and Section 508.

Event Details
WHEN: September 30 - October 1, 2020, 9:00 a.m. to 4:00 p.m.
WHERE: U.S. Census Bureau Headquarters: located at 4600 Silver Hill Road, Suitland, MD 20746
WHO: Federal government employees and contractors; industry technology and accessibility service providers
QUESTIONS: Contact us at [email protected]

For each of our repos, we should move from using a master branch to a main branch. This in line with what GitHub is doing and it's a small but meaningful step toward promoting inclusive language in our project and codebase.

We'll need to update not only our branches, but our documentation and codebase hooks — particularly with CI.

We can start with the instructions here in one of our smaller repos, and apply what we learned to the larger ones.

Are there any other downstream implications to this change?

• uswds
• uswds-gulp
• uswds-sandbox
• uswds-site
• uswds-team
• uswds-for-designers
• luminance-tool
• public-sans

Why we're doing this

All GSA websites must follow the Guidelines for GSA’s Digital Presence🔒 linked within GSA Order 2140.2🔒. GSA also developed compliance criteria🔒 to help web managers follow these guidelines and meet the goals of 21st Century IDEA.

All GSA sites were required to have a modernization plan in place by May 2020. Below are the action items from the website modernization plans for USWDS websites.

designsystem.digital.gov

In FY 2020, based on the Modernization Plan for designsystem.digital.gov🔒, we will make the following improvements on https://designsystem.digital.gov:

• uswds/uswds#3733 incorporate more a11y testing (est. 40 hours)
• uswds/uswds-site#1046 to add Identifer that follows GSA branding guidelines (est. 0-100 hours)
• uswds/uswds-site#1046 to add Identifer with the required links
• Update link notifications (est. 10-20 hours)

components.designsystem.digital.gov

In FY 2020, based on the Modernization Plan for components.designsystem.digital.gov🔒, we will make the following improvements on https://components.designsystem.digital.gov:

- [ ] Incorporate a11y testing (est. 40 hours)
- [ ] Use USWDS, follow GSA branding guidelines, and add anchor (est. 40 hours)
- [ ] Add DAP
- [ ] Add USWDS GA

• https://github.com/uswds/uswds/issues/3644 to decommission https://components.designsystem.digital.gov

public-sans.digital.gov

In FY 2020, based on the Modernization Plan for public-sans.digital.gov🔒, we will make the following improvements on https://public-sans.digital.gov:

• uswds/uswds#3734 to incorporate a11y testing (est. 10-20 hours)
• uswds/uswds-site#1067 to follow GSA branding guidelines (est. 10-20 hours)

v1.designsystem.digital.gov ✅

In FY 2020, based on the Modernization Plan for v1.designsystem.digital.gov🔒, we will make the following improvement on https://v1.designsystem.digital.gov:

• uswds/uswds-site#940 to add banner to clarify it is an archived site (est. 5-10 hours)

v2alt.designsystem.digital.gov ✅

• 18F/dns#427 to decommission https://v2alt.designsystem.digital.gov/ (currently returns a 404); closed by 18F/dns#450 and 18F/dns#453

Redirects

We will continue to maintain redirects for four legacy subdomains:

1. https://components.standards.usa.gov
2. https://design-principles-guide.18f.gov
3. https://standards.usa.gov
4. https://v2.designsystem.digital.gov

• Confirm date (June 8 or 10?)
• Finalize agenda
• Confirm attendees and send invites
• Draft pre-event questions
• Draft invite text/email
• Set up Eventbrite

Over time, how many RSVPs are from repeat vs. first time-registrants?

Goal: Increase the number of first-time registrants.

User story: As a UX specialist, I want to discover user needs surrounding the anchor component so that acceptance criteria for best default is accurate, and so the final component is as valuable as possible.

This story is linked to the Anchor component epic. This component is a complement to the footer. Its purpose is to provide a consistent way of presenting information and links that are required by federal policy. The Anchor Component is distinctly different from the footer and has a simple, neutral default. Embedded within the component are best practice suggestions as to what links or information should be included.

References:
USWDS Anchor Issue: uswds/uswds#3525

Previous landscape analysis examples:
https://github.com/uswds/uswds/wiki/Card-Landscape-Analysis
https://bixal.invisionapp.com/freehand/document/tSS644yrC
Previous heuristic analysis (sample: Preliminary analysis: https://github.com/uswds/uswds/wiki/Breadcrumbs-Landscape-Analysis

Acceptance criteria:

• Research based minimal acceptance criteria for best default and most added value.
• Landscape Analysis (used to create guidance)
• Heuristic Analysis (used to create guidance)
• Naming convention: suggest best practice terminology
• Identify users/roles to account for impacts.

Tasks to complete:

• Determine past research techniques. What has been used, what was most useful.
• Determine other (or new) platforms for feedback: Slack, 10x forms, Qualtrics on website.
• Determine if interviewing users is a useful option? PRA issues (ask Ammie)? Perhaps interview Bixal staff (ask Philip)?
• Landscape Analysis (used to create guidance)
• Heuristic Analysis (used to create guidance)
• Naming convention: suggest best practice terminology
• Identify users/roles to account for impacts. Who are key users and what is their specific information needs?
• Determine what is the best default. Define user needs surrounding the default.
• Develop minimal acceptance criteria for best default and most added value.

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

See the instructions at https://handbook.tts.gsa.gov/google-groups/

I created the request in REQ0532043