Design system team weeknotes: Issue 5

Matt Tyas
4 min readOct 23, 2020

The design system team is part of one web following our overarching vision of:

Coherent and cost-effective user experiences for Co-op.

The design system team provide the solid foundational tools, resources and standards to enable other teams to work fast — with quality baked in from the start.

Show and tell

We’ve not done an external show and tell yet, but we do record the ‘no prep’ show and tells. We felt this show and tell was such a good update (and felt prepped) that we should start inviting external people. In the meantime you can watch the web team show and tell here — same content as the weeknotes, but including Coherence and Efficiency. The Design system update is first lasting about 14 minutes.

We’re almost ready to test our user journey (level 2) accessibility testing framework

We’ve previously written about the levelled approach to accessibility testing we’re developing so far we’ve developed 2 levels, these are:

  • level 1 — that assesses the components in the design system — currently 515/548 tests pass giving us a 94% pass rate
  • level 2 — the user journey level testing we’re developing now

The goal of the level 2 framework is to make accessibility testing in key user journeys as simple as possible for product teams. We’ll also begin to assess how well we’re doing as an organisation with regards to digital accessibility.

This is something we can then report on and improve over time.

What we’ve done

This week we began to further filter the areas we need to test. The problem we were solving here was trying to get the issues that must be tested (and fixed if issues are uncovered) down to a manageable amount for teams.

We did this with the team and the Dave Cunningham (leading the accessibility work across digital) by working through our Miro board of issue areas and ranking them by:

  1. Critical issues — things that will stop someone from using our products or services.
  2. Major issues — things that will make it very difficult for somebody to use our products and services.
  3. Minor issues — things that will make it frustrating for somebody to use our products or services.
Minor and Critical accessibility issues on an online whiteboard

We also introduced a horizontal line. Below the line are the issues that anecdotally we rarely see in Co-op products or are likely to be handled by the component (level 1) testing — assuming they pass.

This left us with 7 critical issues every team should spend time testing. These are:

  • making all functionality available from a keyboard
  • allowing people to resize the content
  • making sure videos can be understood with no sound
  • checking that all the parts of each form have text labels
  • not using hovers to reveal extra information
  • if something changes on a page, it must be described to screen reader users
  • the use of semantics, ARIA landmarks and roles

The last one — HTML mark-up semantics is a big topic. It means using the right HTML tags and attributes to describe the content of the page to machines — the browser or screenreader. Further work is required to break this one down into things that are absolute requirements and things that are less important, as well as ways to easily test.

From this we’ll create a spreadsheet similar to the component (level 1) testing framework but grouped according to our filtered issues.

The testing framework level 2 spreadsheet

Along side this framework we’ll include information on how to test as well as a plain English guide to what standards we support and what they mean for users.

Making component development easier and better documented

Alongside all of the accessibility work running in the design system team, we’ve also got a functional spike of Storybook up and running — massive thanks to Jiebin Su for all the work he’d done in his own time on starting this up — this allows us to provide an a single repository where anyone can see components and interact with them, change properties etc. and see how they react.

This will also give us a place to host internal documentation — rather than relying on adding too much technical information to the design system website — which we expect to become more user friendly for a range of colleagues.

It’s really, really early on its lifecycle, but it’s an exciting starting point for the journey ahead… watch this space!

What’s next

We need to finish off our framework spreadsheet and research some of the critical issues further. We’ll then test this framework with the Food digital team in the near future.

Our roadmap and walls

We’ve revamped our web team walls so you can easily see our strategy, goals and roadmaps for the web platform teams in once place.

Onward and upward.

The design system team

--

--

Matt Tyas

Service and interaction design. Product, team management and front-end engineering. matt.tyas.fyi