You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Help a customer do a tax check when applying for a licence
Overview
Our internal service has a combination of forms that must be completed by using user supplied answers and some that must be completed by using data from internal HMRC systems, the data entry screens must not be asked to the customer and during user research we found a lot of Stride users said they would read the question to the customer even if it's just to make sure, it is important that the data entered into these screens is valid HMRC data and not a customer's version of it. This is because there is no API connectivity for this service to collect or validate customer data, this is by design and ensures the service can act as a failover in times of API issues. This user behaviour led us to consider how to instruct users in a simple way not to ask the customer for the answers.
HTML/NUNJUCKS
<divclass="govuk-notification-banner hmrc-records-caption"
tabindex="-1"
role="{% if errors %}region{% else %}alert{% endif %}"
aria-labelledby="govuk-notification-banner-title"
data-module="govuk-notification-banner"
><divclass="govuk-notification-banner__header"><h2class="govuk-notification-banner__title" id="govuk-notification-banner-title">
Do not ask the customer, use HMRC records to complete this page
</h2></div></div>
It is unique because it performs a unique function, it is an instruction rather than a notification (notification banner) or a navigational helper (section captions), this can be useful to other teams who find themselves having to distinguish between pages like this and regular customer answered pages. Of course the instruction could be extended to other instructions to Stride operators or reference their internal guidance e.g. See guidance point 3.2 to find this data
Other components or patterns you've tried
We tried using standard heading captions on the H1 to tell the user to not ask the customer but enter this data from HMRC systems, semantically this was wrong as these captions are intended for context and section labelling, not instruction. In addition to being semantically off users were not picking up on the instruction within and said they would ask the customer to confirm the data within. We considered the notification banner component as it fits more semantically, however the frequency with which it was being shown, sometimes 2 or 3 pages in a row, can dilute the importance of reading it and also, perhaps more importantly, dilute the importance of other notification banners should they be required in the service. We consulted with DIAS team in Newcastle to help work an accessible solution and we settled on using the notification banner mark up and data attributes to leverage existing behaviours and accessibility but with some custom CSS to provide a unique appearance. This could be classed as a modification to the notification banner but given it's semantic shift, to be an instructional caption/banner it maybe warrants its own component.
Research on this pattern
We researched the current version with internal call operators and found they were much clearer on when not to ask customers for any data that they were when we used heading captions for the instruction (this was after a further iteration on the caption content in an attempt to fix the same issue of users behaving as if they had not read it). Can dig out research findings if needed.
The text was updated successfully, but these errors were encountered:
Instructional Caption
Help a customer do a tax check when applying for a licence
Overview
Our internal service has a combination of forms that must be completed by using user supplied answers and some that must be completed by using data from internal HMRC systems, the data entry screens must not be asked to the customer and during user research we found a lot of Stride users said they would read the question to the customer even if it's just to make sure, it is important that the data entered into these screens is valid HMRC data and not a customer's version of it. This is because there is no API connectivity for this service to collect or validate customer data, this is by design and ensures the service can act as a failover in times of API issues. This user behaviour led us to consider how to instruct users in a simple way not to ask the customer for the answers.
HTML/NUNJUCKS
SASS
Is it useful and unique?
It is unique because it performs a unique function, it is an instruction rather than a notification (notification banner) or a navigational helper (section captions), this can be useful to other teams who find themselves having to distinguish between pages like this and regular customer answered pages. Of course the instruction could be extended to other instructions to Stride operators or reference their internal guidance e.g. See guidance point 3.2 to find this data
Other components or patterns you've tried
We tried using standard heading captions on the H1 to tell the user to not ask the customer but enter this data from HMRC systems, semantically this was wrong as these captions are intended for context and section labelling, not instruction. In addition to being semantically off users were not picking up on the instruction within and said they would ask the customer to confirm the data within. We considered the notification banner component as it fits more semantically, however the frequency with which it was being shown, sometimes 2 or 3 pages in a row, can dilute the importance of reading it and also, perhaps more importantly, dilute the importance of other notification banners should they be required in the service. We consulted with DIAS team in Newcastle to help work an accessible solution and we settled on using the notification banner mark up and data attributes to leverage existing behaviours and accessibility but with some custom CSS to provide a unique appearance. This could be classed as a modification to the notification banner but given it's semantic shift, to be an instructional caption/banner it maybe warrants its own component.
Research on this pattern
We researched the current version with internal call operators and found they were much clearer on when not to ask customers for any data that they were when we used heading captions for the instruction (this was after a further iteration on the caption content in an attempt to fix the same issue of users behaving as if they had not read it). Can dig out research findings if needed.
The text was updated successfully, but these errors were encountered: