Epic | Profile | Profile design patterns

[andaleliz]

Background

As we iterate on the VA.gov profile, and teams contribute products, we're increasing the risk for inconsistent patterns and the LOE required for maintenance (on FE and for design). Let's think about how we might streamline things.

Areas of opportunity:

• the cards we're using aren't part of the design system. Can we switch to DS cards? If not, why not, and can we get our cards added to the design system?
  • e.g. mobile vs desktop padding changes
• spacing between sections and components varies across pages (e.g. between addresses and phone numbers and email on Contact info, and between apps in connected apps).
• spacing between the profile side nav and the main section of the page (currently inconsistent in design files)
• we don't have any guidance about when to use the gray background headings (e.g. contact info) vs the sections with small headings (personal information).
• the small headings don't work well without the gray background headings, they're really small and hard to visually scan. When we change those headings to the Bitter h3 style, it's clunky and ugly.
• there are many things in profile we could add to the Auth Exp pattern library to reduce Figma maintenance (e.g. the cards, the "system down" alert, success alerts, error messages)
• Are we consistently using the same language for additional info components (statements vs questions)? is the placement consistent? (probably yes, but worth double checking)
• Document spacing/layout specs for profile pages so designers don't have to manually inspect/double check things against prod every time we've taken a break from design files.
  • E.G. document the margin between the h1 and breadcrumbs, and top and bottom margin for our alerts

Important Artifacts

• mural board

Tasks

### Tasks
- [ ] #78460
- [ ] #82669
- [ ] #82672
- [ ] #82684
- [ ] #82688
- [ ] https://github.com/department-of-veterans-affairs/va.gov-team/issues/72677

[andaleliz]

We had a productive meeting with Matt Dingee today and talked about 4 areas of the profile to improve. I think breaking up the work as follows makes sense. The task items could be tickets for practioniners, and I added notes as bullets where relevant. @mtcA6 lmk what you think.

Section containers

• [ ] UX to evaluate how profile uses a list vs a card vs a section, and when content should just be on the page alone.
  • This could have big implications for the design of profile. Would OCTO support a redesign of the profile? Can PM get this answered?
• [ ] UX and FE should collaborate to determine if it makes sense to use the va-card component for all cards (sections?), and if so, what variations on the existing card component we might need for profile.
  • Our heading w/ gray background is a desirable contribution as a card variation for the design system, so contributing that back through the experimental design process could be a separate ticket if we get to that point.
• [ ] UX and FE should collaborate on vertical spacing tokens and possibly contribute this back to DST

Heading variations

• [ ] UX to evaluate how we're using these headings and see where these can be streamlined across various parts of profile. Get it down from 4 to 2?
• UX to reach out to DST and see if we can be an experiment for public sans

Intro text

• [ ] UX to determine how to better align this across profile pages and create mock-ups. Currently this is only on notification settings and connected apps. Intro text is not ideal, since it doesn't have a lot of guidance.

Null state or empty values in sections, when nothing is present for a piece of data

• [ ] UX to explore design treatments on how to elevate important information that is not a featured summary item or an alert.
  • Run a quick comparative analysis
  • Explore design options
  • Incorporate into existing null states where possible, or at a minimum update null state on Military info to be plain text, and evaluate connected apps to see where we can do this, given the intro text on that page.

[adamwhitlock1]

Allison might be able to lend a hand with the card variations with heading since she created the original card and got it added to the design system. If she can't I'm happy to jump into that ticket when it comes time.

Great work summarizing the main points and I think each of these items could lead to a better experience on the profile long term. 🚀

[mtcA6]

I'll discuss next steps w/Chante when she's back in on Monday.

[mtcA6]

@andaleliz I discussed this with @clantosswett

Are you able to rank these in order of how impactful these will be for the profile and design system? (or are they ranked that way already) I think we'd want to start with whichever one will lend the most impact back to the design system.

I don't think we approach this as a total outright rework of the profile. What do I mean by this? The way I view us working through this is:

• we pick the most impactful item that makes sense to work alongside whichever portion of the profile we're updating
• As we have work that crops up throughout the year when we initiate that work we roll this in along side those other initiative
  • for example, we'll likely need to incorporate new notifications to support the debt team (first initial meeting about that is today 3/26/2024)
  • as we take our steps to consider how the page is impacted by adding a new group of notifications and new notifications we consider say the intro text?
  • we should likely rework the account security page given the DS Logon and MHV retirement so we'll have the opportunity to reduce code in that part of the profile and reduce complexity, we can consider how to work these 1 or more of these patterns in
  • it may make sense to add a new demographics page later in the year as we start to incorporate race and ethnicity (this is stalled for now but I don't expect it to be stalled for forever) this would give us a huge opportunity to thing ground up for a new page about potentially ALL of the behaviors called out here.

I think it's also worth setting up some time to discuss in more detail how we coordinate with Matt and the design system. I wasn't fully clear (and wasn't really able to explain to Chante) on what that back-and-forth might look like nor exactly how incorporating the tokens he mentioned would support this work. Do we make the changes and feed them back to the design system? Does the design system make the changes we ask/recommend and those automagically flow into the components we're already using?

[andaleliz]

Thanks @mtcA6! That general approach makes sense.

Are you able to rank these in order of how impactful these will be for the profile and design system? (or are they ranked that way already)

They're not ranked in a specific way, and I can definitely do that. I would also suggest adding "impact to users" as something we should consider as part of the evaluation process. Can you elaborate on what you mean by "impactful for the profile" though? I'm interpreting "impactful to the design system" as meaning something they'd find valuable because other teams can use them too, or because it's something they want to do but don't have bandwidth for.

I think it's also worth setting up some time to discuss in more detail how we coordinate with Matt and the design system.

We certainly can, though it's well-documented here and I don't know that I can explain it better than this. The short story is that we make changes, and propose them back to the design system. Usually they'll accept it as a "use with caution" component until we can sufficiently validate it through research. There is not a clear definition on what's sufficient though.

[mtcA6]

@andaleliz yep in everything we do, I hope, we're always considering the impact to our users.

Regarding your questions around the "impact to profile", you yourself said "This could have big implications for the design of profile" so I take that to mean some of these will impact broader swaths of the profile than others, and, I expect, may result in more design and dev work.

As for how you rank, incorporate what you feel makes the most sense. My comments on this ticket shouldn't be the end-all-be-all of how you're ranking things. I was giving context but that's not ever going to be exhaustive so feel empowered to incorporate whatever parameters you find pertinent for ranking which of these design patterns you recommend we should work first.

Thanks for linking to the process. Process documentation always feels a bit flat, when we discuss this next I'd like to hear your thoughts on how you want to navigate completing the design work and incorporating the myriad of steps called out in the documentation as part of this effort. Since this VA process is new to me, I'll need your expertise and guidance on when we incorporate which piece into our stories.

[andaleliz]

@mtcA6 sounds good. I can think about this more in the sprint after the one starting today, once my current research study is wrapped up.

[andaleliz]

Hi @mtcA6 I've created 4 tickets and added them to this epic. I've prioritized the section containers and null states for the next sprint, and then the intro text and heading variations to the following sprint (they should be labeled accordingly, but lmk if not).

My thinking is that the section container work will have the most impact to veterans, our team, and the DS team because streamlining that will improve the UX, reduce code, and potentially give us 2 things to contribute back to the DS team.

Next, I think addressing the null state inconsistency will also provide a lot of value for improving the UX by reducing the number of alerts we're using, cleaning up content, and establishing a consistent pattern which will reduce cognitive load.

The 2 issues for the June sprint will also be impactful, to be sure, but are less widespread so they're a little lower priority.

[andaleliz]

@mtcA6 just a heads up, I've unassigned myself from this epic and related tickets, knowing I won't get to these in my last week.