Design notes
The Quick reference component was developed as a replacement for the Key details bar.
Design goals
We wanted to clearly make the Quick reference component a place for background information rather than a way to make something prominent or important. The design intent is to indicate to the user that they are in the right record or case at a glance.
We also aimed to give designers more flexibility in styling and positioning the component on a page.
What we did
Reviewing the key details bar in use we found several repeated issues:
- it was being used as a general banner container for anything considered important, which led to too much information being included and a lack of clear information hierarchy
- there was a common request for including multiple status tags and flags
- the name ‘Key details bar’ suggested a specific position and presentation, when others might be more suitable for a service
- the default presentation with white text on a blue background suffered from ‘banner blindness’; users repeatedly overlooked information contained in the component
- it was used to show information that was only needed in part of the journey, for example identity verification
The proposed changes for the next iteration would result in removing the ability to add multiple attributes and tags. The change is to make the component’s purpose succinct rather than a generic header bar for a data dump.
With this in mind we decided that a name change would be appropriate to more accurately describe the purpose of the component.
As the key details bar is used in live services we decided to retain it as a separate component rather than renaming it. This would also avoid introducing breaking changes to live services.
Information displayed
Implementation of the key details bar was inconsistent across services. The quick reference component will be fixed to only 3 details:
- Primary identifier (required)
- Secondary identifier (optional)
- Status (optional)
Primary identifier
This is a required information item, so all uses of the Quick reference components should at minimum have a primary identifier to signify what record/case the user is viewing.
Secondary identifier
The secondary identifier is optional and can be used to support the the primary identifier if it is not unique. For example, if the primary identifier is a person’s name it may be necessary to have a secondary identifier such as a date of birth, case reference or National Insurance number to distinguish between records.
Status
The status tag can be used to communicate the state of a record or case. If a record has a state then all records must have a state. For example, Not started, In progress, and Completed clearly communicate the possible progress states of an application.
Only displaying Completed on completed applications is a flag and not a state. This leaves room for ambiguity when some records have a state and others don’t: if there is no Completed state has the case been started or not?
The quick reference component can include a label showing state, but can not be used for flags. Flags can potentially be added endlessly and harm the usability of the component: if needed they should be shown elsewhere on the screen.
Field labels
From examples of the key details bar in use, we found that some designs used field labels and others did not. In one case the secondary identifier of a National Insurance number had the field label 'NINO'.
We did not find any examples that labelled the primary identifier, which was usually a person's name.
We decided to make field labels optional and built example designs both with and without field labels.
Other information
We wanted to avoid the component being used as an ID verification tool, and also to avoid it being filled with too much information.
Additional information we considered included:
- flags
- key-value pairs
- actions (for example ‘Copy to clipboard’)
However to keep the design layout simple and flexible we decided to limit the permitted fields to the primary and secondary identifiers and a status tag.
Layout position
The Key details bar is limited to a single layout (a ‘bar’) and a position at the top of the screen.
The quick reference component is designed to work in within different grid columns so that the information being referenced does not need to be the first item on the page, and can be moved to suit the needs of the user.
Banner blindness
It was found that users missed the information within the Key details bar due to banner blindness. There is a risk that the blue bar has created a pattern of behaviour/recognition which closely associates it with information in the header that shows name, NINO and a tag.
Even though removing the background may improve readability and avoid banner blindness, taking away the blue background may create a negative experience as users may have learned to look for this information in a blue bar at the top of the screen.
To avoid this, we have included a variant of the quick reference component with the same white on blue colours, which can be used if research shows users need it.
Next steps
This is a new component and we need more research from live services. We will also offer hands-on support to DWP teams migrating from the Key details component.
Get support
Need help implementing this in a prototype or production build? Get support from the Design System team.
Give feedback
We depend on insights from real projects to update and improve the design system. If you use something we made, tell us how it went.
Could we improve this page?
Send questions, comments or suggestions to the DWP Design System team.
Last updated: