Make more iterations of prototype documentation for the Reveal component that tests different ways to communicate the inclusivity score results alongside other documentation about the component.
User stories
As a designer, I want to know the current status of a component, so that I can make informed decisions about which components to use.
As a designer, I want to know the best practices for using a component, so that I can build good experiences for clients.
As a researcher, I want to be able to see the top things we’ve learned from research reflected in a page so that I know it is helping to inform designers across the organization.
As an engineer, I want to know how to implement a component so that the UI can meet accessibility standards and be usable for all clients.
Priorities for next iterations
How to translate Inclusivity Score results into status and clarify status.
How to express that there are concerns with HTML
Call out specific alternatives
Call out research sources for usability issues
Consider how to reduce the work of managing the content
Planned Iterations
Uncurated results: no high-level status, no summaries, has the current Inclusivity Score table at the top
Is it ready status with AUR: Single “is this ready to use?” status on top, scroll down to see detailed table with accessibility, usability with people tags, and research summary of inclusivity scores.
Component lifecycle with WUE: Single “Where is this component in the development lifecycle?” status, possibly incorporate what it needs to be done, scroll down to see new inclusivity score table version framed around WCAG compliance, usability (with tagged groups), and external research.
Can be made in Notion or any other mediums that help with testing ideas
Should explore ways to display all the results we found when checking the Reveal component
Should be made for a broad audience: designers, researchers, engineers, PMs, HC team.
creative improvements to HC documentation that don't focus on the inclusivity score results are welcome but out of scope for this tasks.
should be be able to communicate main types of results (not checked, checked with issues, checked and looked good)
should have a way communicate the details of the issues found
would be great to explore the balance between making the results scannable at a glance while also making the details accessible on the page
The goal of making multiples versions is to have a way to explore the tradeoffs we might encounter when trying to be both brief and detailed.
Timing
We should finalize the design by end of September
Acceptance
This task is complete when we've made three different prototypes for how to communicate inclusivity score results.
Tasks
[ ] [SDS] Uncurated results: no high-level status, no summaries, has the current IS table at the top
[ ] [SDS] Single “is this ready to use?” status on top, scroll down to see detailed table with AUR with people tags
include list of “is this ready to use?” statuses that would be linked to
[ ] [SDS] Single “Where is this component in the development lifecycle?” status, possibly incorporate what it needs to be done, scroll down to see new IS table version framed around WUE
include list of “development lifecycle” statuses that would be linked to
might consider using autoformat as an example instead of reveal
[ ] [BG] Create external reference page on current IS checks
[ ] [BG] list of “is this ready to use?” statuses that would be linked to
[ ] [BG] list of “development lifecycle” statuses that would be linked to
Summary
Make more iterations of prototype documentation for the Reveal component that tests different ways to communicate the inclusivity score results alongside other documentation about the component.
User stories
Priorities for next iterations
Planned Iterations
Details
Timing
Acceptance
This task is complete when we've made three different prototypes for how to communicate inclusivity score results.
Tasks