Skip to content
This repository has been archived by the owner on Dec 21, 2023. It is now read-only.

Product team user archetypes

Carolyn Dew edited this page Feb 22, 2017 · 3 revisions

To better understand who uses the guidance the accessibility guild creates, we are creating user archetypes for each member of a typical cross-functional team at 18F who impacts the final accessibility of a product. This is a work-in-progress and we'll update this as we learn more.

Front end

Who they are

A front end developer is working on a small feature and needs to ensure that their code is accessible. They’ve heard about accessibility their whole career but never made it a point to study it in depth. If they were interested on their own, they quickly became overwhelmed by the amount of information out there, accessibility specific jargon, and lack of guidance on how to get started. They broadly want their projects to be accessible but aren’t always sure what they need to do to ensure that.

Why they’d use the guide

  • They want to quickly find the guidance that is pertinent to the particular feature they’re working on.
  • They want to perform a series of end-to-end accessibility checks before a major release.

Goals

  • Complete their work within the current iteration and not let the team down.
  • Make sure their code is clean, semantic, and accessible throughout coding a feature.

Concerns and challenges

  • Isn’t really sure where to look for guidance on creating something accessible.
  • May be overly dependent on automated testing without understanding the results (false positives) or how to fix them.
  • Wants to understand how the accessible features they put in the code are experienced by the end user. Feels very disconnected from the disabled user.
  • They often feel they are the only check for accessibility before a feature is shipped.

Content strategist

Who they are

The content strategist is responsible for all the written content within the product, and their goal is to make sure the writing is understandable and appropriate to the product’s audience. They champion plain language and pooh-pooh jargon. They have a lot to contribute to microcopy on buttons, links, alt text for images, and descriptions for graphs and tables. They work with their ux teammates to make sure navigation is clear.

Why they’d use the guide

  • They want to make sure all the copy they’ve written conforms to 18F’s Content Guide and reflects plain-language best practices.
  • They want to check to see that content and visual elements work together harmoniously.
  • They need to determine whether content renders appropriately across devices.
  • They want to test whether users can easily navigate a site.

Goals

  • Write and iterate on all content (site copy, interface copy, documentation, marketing collateral, and more) quickly.
  • Make sure all content meets federal accessibility guidelines.

Concerns and challenges

  • Some folks may not be aware of all accessibility-related guidelines and/or when to perform accessibility checks.
  • Projects with tight timelines may not allow for comprehensive content testing.