Key details bar

[jonhurrell]

Hello, we'd like to kick off an open discussion on the use of the Key Details bar:

Why we need your help?

The goal of this discussion is to help us understand what services are using it and how. This will feed into our research and analysis phase of the components development.

What do we think we know so far?

It's a way to display citizen's identify and important information to a work coach/agent so they know and can check which record they are viewing.

What's the need?

Agents need to a mechanism to check they are looking at the correct application and review citizen identity details. The design shows what the service considers to be the key information. Common info includes Name, Date of Birth, NI number, status). Depending on the service they may also see the status of the claim/application.

Some discussion points to get things going?

• Have you used or know where this component has been used?
• Do you know if there's been any research or testing done on it or around it?
• Do you agree with the user need?

[a184studio]

We have something similar, I can add context.

[neil-holroyd]

We are using it on Kickstart to capture the main details of the applicant. It shows their application ID, organisation name as well as the contact details for that particular application. We also have a concept of a variation to an application through the Apply service and so the contact details change accordingly if needs be. These are useful for colleagues to quickly identify who to contact for any clarification on their application. The tag on the right also identifies whether this is an employer/gateway/gateway plus application.

We have also introduced the search function into the header to avoid people having to do three clicks to get to this on a standalone page.

[neil-holroyd]

I think it is also worth noting that if the details bar and the new notification banner are used in conjunction then this could create a visual conflict with both being predominantly blue.

[jonhurrell]

Thanks @neil-holroyd. Any associated research docs or insights notes from research (no worries if not)?

[neil-holroyd]

On the two blue components used together we don't have any insight. All we have is a comment from another IxD who brought it to my attention. The above was proposed for Kickstart Payments but is not going into production as too near the end of the service v value for money.

[petelonsdale]

Also in use on the Check a Digital Budgeting Loan service. We omitted the NINo as Budgeting Loan applications are unverified and we didn't want to present agents with potentially incorrect information.

Research showed it was familiar to internal staff and they were happy to see it. Many recognised it from other services within the dept. The main feedback from UR would certainly agree with the user need.

[a184studio]

Hi All,

Agent apply for Pension Credit
So we had something similar for our Agent Apply for pension Credit in 2018-2020. It it was canned and we then moved to a citizen service so this is pretty much dormant for us.

This was what it was like at the time.
— Applicant Name
— Caller name, if it was third party making the claim on behalf of the applicant
— NINO of Applicant.

2021 / G4s
Since then, we have a new G4s filter, in sort, it gets the right people to DWP to make a full application for pension credit.
This is our day one header.

— Applicant name
— NI
— DOB
— Helper or third party, will be a future add-on after day one.

The reason why DOB in now in the ID bar is that G4s use Name, DOB to find a nino in the event that they need to do a trace within SearchLight.

As you can see its, all the same info just light touch, UI wise.
Our basis for this approach was from the MOJ pattern.
https://moj-design-system.herokuapp.com/components/identity-bar

We also opted for this to try and save space and reduce manual note pad entries of NAMEs, NINOs, DOB, so that they can be used later if needed.

Goes without saying to help in the event that the Agent forgets the name of the caller.

[a184studio]

@michaelcattell You owe me a coffee. It's on the internet now. So it cant be deleted.

[a184studio]

@michaelcattell Also, happy to test what you have above, but it will be after our day one if thats okay.

[leahsmith1104]

In use in the health assessment service. From an interaction design point of view when managing a referral we have used it mainly for consistency purposes and continuity as it is used in the assessment space later in the journey. So we haven't fully investigated the user need for it from an internal case manager POV before putting it into a prototype, however it has tested well in prototypes when carrying out actions that navigate away from a referral such as updating status.

When a user leaves the referral to update the status, we use it as a reminder for the case manager, in case they are distracted, of the claimants referral status they are updating. Getting distracted in the update process by something in the office is something that has been observed in testing as they are sat close together and often get interrupted by questions from others.

Name, DOB (both for identification purposes) then status (as a reminder of what status they are about to update away from) Finally postcode and special rules terminally ill are also displayed, as the user will have to take different actions dependant on location or terminal illness, so we deem that key information. I know in the assessment journey the healthcare professionals have a need to identify using the key details bar. (Pete Jobes or Colin Passant can confirm the HCP needs).

[gazjoy]

@michaelcattell for context, the blue bar was originally used for JSA as a way to support an outbound agent to citizen call. The data in the blue bar was the key info to give confidence to the agent they were speaking to the right person.

[jonhurrell]

We appreciate taking the time to do this 👍.

[michaelcattell]

(unsure if useful but thought id include)
Quick build from Colin (front-end):
https://a11y-demo.herokuapp.com/components/keybar
https://a11y-demo.herokuapp.com/demo/agent-full

[neil-holroyd]

Is there a username and pw for this?
Thanks

[jonhurrell]

DM'd you on slack.

[jonhurrell]

Just lifting this from the slack conversation as @jonathanthomas83 may have findings related to this.
https://twitter.com/adambsilver/status/1324345198869139459?s=21

[martinwake]

I showed this to the DWP content design community on 25 November 2021. Questions that came out of the session:

• How would this behave with longer names than "Jane Doe"?
• "Welsh speaker" is on a different line to "Language". Should we avoid field labels and their contents wrapping to different lines?
• Can the bottom block include one or more tag components or is it only for text?

There were several questions about using "flags" within the tag component.

In the guidance the preferred use of the tag in the top block is for a category that has several possible values. This is different from an optional flag which might or might not appear. We discussed "flags" as things that:

• don't always appear (for example a "high risk" flag on some records but not others)
• aren't mutually exclusive, so their number is unpredictable

If a service has several of these flags, could the design team use the key details bar to show them? If so, how?

Originally posted by @martinwake in #161 (comment)

[htmlandbacon]

based on using https://design-system.dwp.gov.uk/components/key-details-bar a couple of services have looked at re-using the nunjucks component - a lot of it is about the composability of the component -

1. Some services don't always use the national insurance number identifier
2. Some services use a variable amount of additional information (i.e only one item in the second line)
3. Status isn't used somethings - this should be optional

The only other thing I've noticed from other teams might be the ability to change the colour of the bar and text on the aria label.

[jamesashcroft]

The below example is something we have been testing within PIP.
This was quite minimal as we didn't need to display alot of the other things/didn't know if we needed them becasue of on-going research.

We tested some naviagtion below it to help a case manager to get around the system, in a more effective way and we wondered if the navigation should have been sitting above the details bar or not. In the end it was better to put it below the key details bar becasue it was secondry navigation rather than primary.

Further testing is still on-going.

The below example shows the use of markers, this was an idea we had to display PIP markers. These are very important to a PIP case and will be relevant all the way through the review of a case. The positioning is different to some other examples that show a status, this is more because there could be more than one marker on a case so having them at the top might not be appropriate.

This is still quite early and lots more research would have to be done for us to understand markers in more detail and if it's even appropriate to store them in the key details banner.

[leahsmith1104]

We've since done some more user testing in the Health Assessment Service (live in the health transformation area) around the key details bar, checking for banner blindness, mainly when looking at introducing a form of navigation. We tested with 8 users in total, split between 4 job roles (4 case managers, 2 healthcare professionals, 1 admin and 1 site lead). In our testing we set a task to check for banner blindness where we asked for the user to provide us with the date of birth, and made sure that date of birth wasn't available anywhere else on the page. Of the 8 participants 4 had banner blindness (2 case managers, one healthcare professional and the admin user, so a 50% split). All these users have access to the key details bar currently on the live service in the health transformation area on a daily basis, so this particular pattern isn't a new conceptual design to them. The users that missed the date of birth in the key detail bar, chose to navigate to the claimants details and expected to find it there (usually it would be duplicated, but for testing it was removed). Next steps regarding this piece of work for the Health assessment service is to look at testing the removal of colour from the key detail bar, and also any claimant information other than key identifying name and NINO, and using that space for any markers such as end of life, rather than duplication of information that can be found under the claimant details.

[jonhurrell]

Posting an example of a key details implementation from a searchlight prototype, that has an inline design treatment.

[timcooper-DWP]

As there is little context for accessibility would it make more sense to change this to "Customer name:"
<dt class="govuk-visually-hidden">Name:</dt>

[jonhurrell]

Thanks @timcooper-DWP we allow the primaryIdentifier object name string to be changed for this use case. If your service refers to its users as customers then the macro can be adjusted:

primaryIdentifier: {
text: 'Customer Name:',
value: 'Jane Doe'
},

[timcooper-DWP]

Thanks Jon

[a184studio]

Not sure if customer should be a thing, OPS use it, it's not strictly true. They can't take the custom elsewhere.

There is several things that need to be considered here:
— Applicant name, when outcome in not know, or in the process of Applying
— Claimant name, When they are in receipt of a "benefit" - if they don't get anything they are not claiming anything and therefore not a claimant. Also, you could have claimed and its been rejected. Are you still a claimant then? Possibly.
— Citizen is another
— Or just name

[jonathanthomas83]

We tested the key details bar on our agent facing Maternity Allowance service prototype and users were missing the information. We attributed this to possible banner blindness. We gave the blue version about two or three rounds of UR before trialling a plain white version.

This tested well and was noticed immediately and we've since iterated the design to lose the line because we have a menu just underneath it (with more lines) and it was too line heavy!

And within the context of the page:

[jonhurrell]

Thanks @jonathanthomas83 we have an update to key details planned this roadmap to add more flexibility into the component, based on how it's being used. Can you share the research insights?

[gazjoy]

@jonathanthomas83 would it be possible to share how this works on smaller screens?

[jonathanthomas83]

@jonhurrell The only real insight we have, has been mentioned. That the users were blind to the key details. Comments like "oh, I didn't see that" when asked to find the contact number, for example, were common when the bar was blue. Which prompted us to change things a little after 3 rounds of the same feedback. After changing to a white background, similar tasks to find information in that bar were completed quickly and without issue. Nothing further to that has been documented in our UR reports, unfortunately.

The iterative design process for our Alpha prototype is documented here: https://app.mural.co/t/dwpdigital7412/m/dwpdigital7412/1638872329200/15b94b179ad3dc77d62c323ec0d1e2ca55e81005?sender=u11c916d0c9d1ea1fb3c87693

[a184studio]

Nothing much to add here, but we didn't have any evidence to do anything more that the basic info needed to use to enter SearchLight Name, Nino. No issues with agents missing it as actions once tasks have started prompts you to use these two data items to safely enter SL knowing they are the person.

[timcooper-DWP]

Hi All,

I have an idea for an iteration. We have found that our users need to copy and paste the NINo into other systems. Whilst strategically it would be great to integrate the systems, we have a proposal for an easy fix that would facilitate it.

Problem: Many systems require the Nino without spaces, but we use spaces for presentation for lower cognitive load
Possible solution: Small amendment to the key details template to use "| safe":

{{ params.secondaryIdentifier.value | safe }}

Then use CSS to prevent copying the spaces:

<style> .nocopy { -webkit-touch-callout: none; -webkit-user-select: none; -khtml-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; } </style>

QQ 12 34 56 X

Now if the user pastes into a system that only accepts text, the spaces do not show.

This may not be the only way to make it work... any thoughts?
Thanks

[htmlandbacon]

Health assessment service has similar intent - keep the visual presentation, rhythm for screen reader but to remove spaces for pasting.

From memory it was implemented as a filter:

{{ 
    dwpKeyDetailsBar({
        secondaryIdentifier: {
            text: 'National Insurance number:',
            value: 'QQ123456X' | ninoFormatWithSpaces
        }
    })
}}

[timcooper-DWP]

oooo that looks good, thanks

[timcooper-DWP]

Found another alternative from Searchlight:

<span> 
    <span style="margin-right: .2em">QQ</span>
    <span style="margin-right: .2em">12</span>
    <span style="margin-right: .2em">34</span>
    <span style="margin-right: .2em">56</span>
    <span>X</span> 
</span>