Improve content proofing experience

kevwalsh commented 4 years ago

Background

User Story or Problem Statement

As a person who is editing, reviewing, or publishing content, I need a screen that shows me all of the information that’s part of a given piece of content, and review it for correctness before it’s published.

Problem description: Content view screen is a mess for most content types.

Affected users and stakeholders

Focus on editors of benefits detail pages
[Indirectly] All CMS users

### Hypothesis We believe that improved content proofing tools will help editors understand their content so they can edit content, review content, and look at revisions. We'll know this is true when: ### Assumptions * It is not clear to users what content was edited when using the "view" proofing screen * Opportunity to improve "revisions" screen by proxy *IA Improvement* * Room for IA improvement -- need to improve visual information hierarchy * Users have a difficult time differentiating cms labels from the content itself * ALL CAPS IS MEAN (users prefer not to be yelled at) * Users prefer styling on the content proofing screen to mirror what appears on the front end. (To what extent should we incorporate h2 vs. h3s -- expensive to reproduce this) * Users should be able to easily identify how content has been style (for example, that text has been styled as an h2). * Editors and a11y bots would want to be able to verify that h2s and h3 nesting is correct (for accessibility in particular) * Users would like to see content organized by component so they verify how the content will be nested when it is displayed * Need to explore whether users can find the page title (h1) w/ confidence * Research Q: Pages with a lot of nested content (e.g. 2019 VA DIC Surviving parent benefits rates) may benefit from the option to collapse some content on the view screen via accordions * Meta description: opportunity to put it top of mind for authors -- * Related to nesting -- Users may want to see embedded content on the proofing screen, in addition to having the option to edit it via a link. (Example: Mental health servies pages, alert: How do I talk to someone right now?) * Position of the preview button relative to the meta descrip box and other content is misleading -- what content is being previewed? Just meta descriptions or more than that? * Menu settings do not appear in the view screen. This could be a problem when the h1 differs from the menu title. *Break out into its own story for _satisfying_ quick wins* * Users may prefer either the breadcrumbs or the left side menu to help them understand where they are and navigate to other content, but may not need both. (Hypothesis: if the left nav did a better job of telling users where they are, we might not need the breadcrumbs) * ^ Related to the last point: having two ways to navigate and understand location may contribute to visual/cognitive overload (aka there's just too much on this screen) *Related epic, but not in scope* * Users need improved tools to communicate with each other about status of recent changes. * Users may need more clarity / plain language context to understand whether cms alerts/notifications are relevant to them (How will these assumptions be validated?) ## Acceptance Criteria * Testable_Outcome_X * Testable_Outcome_Y * Testable_Outcome_Z ## Runbook This is particularly relevant for feature launches, or for making changes to the content model that require front end changes as well. 1. Step_to_get_to_production_X 1. Step_to_get_to_production_Y 1. Step_to_get_to_production_Z ## Possible tickets to create for this epic - [ ] Spike task, with some of the following attributes: * Identify the baseline against which we will measure improvements: User journeys and initial usability tests * UX writing discovery * Ideation (sketching, cross-disciplinary meeting of minds around how the problem may be solved) * Understand how users are currently being introduced to content proofing during training/onboarding * Analysis of the Drupal landscape * Possible implementation(s) * Proof of concept or prototype - [ ] User research - [ ] Design - [ ] UX writing - [ ] Usability testing (eg with a prototype or other design stimula) - [ ] Implementation - [ ] Documentation (What needs changing or adding to the documentation? - [ ] Product release notes (How will we describe this feature to CMS users?) - [ ] Training (Will any users require additional training?) - [ ] Metrics (How will we measure any improvements)

rachel-kauff commented 4 years ago

@kevwalsh Would you be able to take some full length screenshots from preview for a benefits hub page so Jordana and I can map out the difference between preview and view (proofing)? You'll probably have the best sense of which page makes a good example, but we were thinking something with a lot of content in different components

kevwalsh commented 4 years ago

Yep! i'll do that here. I temporarily disabled the link reports, for now.

First, here's an example of what it could look like with an h1. It's interesting to see it right beside the breadcrumb, you can see the menu item is not the same anymore.

Menubar_and_How_To_Apply_For_VA_Health_Care___Veterans_Affairs