Midpoint Review - Design Feedback - MHV to VA.gov Team - Medical Records (Comprehensive Domains)

[allison0034]

VFS actions

• [ ] Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
• [ ] Comment on this ticket:
  • [ ] If the Platform reviewer has any Thoughts/Questions that require responses.
  • [ ] When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
  • [ ] When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
• [ ] Close the ticket when all feedback has been addressed.

Thoughts/questions

• I will be OoO for the meeting. Matt will be able to speak to any design issues. I will watch the recording Tuesday and adjust feedback if necessary.
• Thank you for all the hard work! I know this project is HUGE.
• If the drop down with print/download is approved, submit and an experimental design ticket.

Feedback

Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).

• Must: Remove border radius from all card styles, the cards should be square.
• Must: On About VA medical records, under What you can do in this tool, unbold the text in the link and use normal font weight if you want to use the default font style or add the chevron if you want to use the active link style
• Must: On About VA medical records, increase the size of the + on the accordion. I cannot tell the exact size but Sketch and the design system should be correct. If Sketch is smaller please let me know.
• Must: On lab and test results, bold the text for the active link style

[humancompanion-usds]

Accordion handles

I just double checked the Accordion drawer handles (+ and -) in Sketch and in Storybook. They are massive by comparison (you could see them from space). They should be 16px x 16px.

Split button

Should The split button is not approved and I don't see an issue for it with the Design System. This is an odd implementation of a split button in that there is no default action. Thus it’s really just a menu of links.

Split buttons are for presenting several related tools if one option is used most frequently. Making the most commonly accessed option a [default](https://www.nngroup.com/articles/the-power-of-defaults/) lowers the [interaction cost](https://www.nngroup.com/articles/interaction-cost-definition/) to use that option since it removes the need to open the menu before selecting the item. The obvious penalty is that accessing the menu becomes harder because it requires hitting a small target (which takes [more time according to Fitts’s Law](https://www.nngroup.com/videos/fittss-law/)) and also involves an extra mental operation to decide which part of the button to activate.

From https://www.nngroup.com/articles/split-buttons/

I would recommend either making this a split button or breaking it apart.

If it's to be a split button then:

• Make Print the primary action and a button that when clicked executes a print action.
• Separate the menu with a bar between the primary button action and the arrow icon. This provides affordance for the tappable target of the smaller menu action.
• The contents of the menu are traditionally (well, as traditional as split buttons get) not styled as buttons or links. I defer to a11y as to whether they should be buttons or links but given that the primary here has to be a button I would make them button-y or leave them as text with significant padding but do not style them as links.

If it's not a split button then break it apart by having:

• Primary print action (again, defer to a11y guidance for link vs. button)
• Secondary download PDF
• Secondary download as text file

Button pair update

Should: You should submit your Previous / Next Button pair as a new variation to that component: https://design.va.gov/components/button/button-pair

Pagination vs. load more

Consider On Lab and test results your using the Pagination component but on the Images view you are using a "Load 5 more images" Why not use the same in both places? Is one superior to the other in those contexts?

[coultonbunney-usds]

@humancompanion-usds We've thought quite a bit about the print/download interaction, and wanted to respond to your Should feedback.

Your characterization that

Thus it’s really just a menu of links.

is spot on. That was actually our intention. This is not a split button at all. It's a dropdown menu. Dropdown menus are widely used, including on VA.gov (the header mega menu is technically a dropdown menu), Bootstrap 3, Material 3, and are described in this nngroup post (referred to as a command menu).

In the article you quickly linked to, it says

Split buttons are for presenting several related tools if one option is used most frequently.

I agree. And from a Veteran's POV, each of these actions are weighted equally and its our design intention to present them equally. Choosing one option to display as default would reduce a Veteran's access to other frequently used options, especially because the split button hides the additional options much more than a typical dropdown menu would. From a usability perspective, the additional options are much less discoverable in a split button than in a dropdown menu.

I would recommend either making this a split button or breaking it apart

Your second suggestions of breaking it apart pushes the actual content quite far down the screen on mobile, below the "fold." This layout affords that the primary way to consume information such as a lab result is to download or print it. This wouldn't normally be a huge issue, but in MHV Classic, the only way to access your medical content is to print or download it. Therefore, we believe by unnecessarily pushing the HTML content further down the page, the current mental model reinforces that users need not scroll down past these options to get to the richer HTML content. This is counter to our design intention, and could in fact hide the most accessible version of the content.

The last route we considered was putting print/download after the HTML content, but given that some medical results are incredibly long and we cannot shorten them, this all but makes those buttons disappear. This is also something we don't want to do and runs counter to our design intent.

Because of all of the reasons above, we felt that the dropdown menu was the best option. It is also a component that could be used in various other places in MHV on VA.gov, such as in secure messages.

With all of this said, it seems like the only reason to not use a dropdown menu would be due to a11y issues. The same a11y issues exist for a split button and a dropdown menu. We can work with a11y to see if there is a good path forward. If there is not, then we will need to likely go with splitting the options apart.

[BobbyBaileyRB]

• Must: Remove border-radius from all card styles, the cards should be square.

All card styles have been updated in the designs. We removed the border-radius and now they are square.

• Must: On About VA medical records, under What you can do in this tool, unbold the text in the link and use normal font weight if you want to use the default font style or add the chevron if you want to use the active link style

We removed the bolding of text for these links and now the links are in normal font-weight.

• Must: On About VA medical records, increase the size of the + on the accordion. I cannot tell the exact size but Sketch and the design system should be correct. If Sketch is smaller please let me know.

The sizes of the + (plus signs) on the accordions were updated and now follow the design system.

• Must: On lab and test results, bold the text for the active link style

We updated the text to be bold.

Thank you.