Phase banner #57
Comments
|
There's some evidence here from the GOV.UK Notify team that the beta banner can cause confusion and even put some people off using their service: alphagov/notifications-admin#1838 |
|
Worth noting that they weren't using the beta banner, just the beta tag – as per the product page example. A traditional beta banner might have been fine. It possibly is evidence that that the tag by itself isn't working, though. |
timpaul
added
the
component
|
It would be useful to have clarity on whether the phase banner (and breadcrumb)s should be inside the main element or not. (I'd say outside) However for example https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction has it inside the main element, This means the Skip to content link only cuts out about half the points of keyboard focus it would otherwise. |
|
@jbuller @stevenaproctor Hi, you'll find this implemented in many different ways across GOV.UK sites as they were all made at different times. If you're using the GOV.UK Design System / GOV.UK Frontend then this page on the design system clarifies the structure of the page we intend people to use https://design-system.service.gov.uk/styles/layout/#page-wrappers |
|
Thanks for the pointer. |
|
So to request a few changes to this:
|
|
Thanks @sanjaypoyzer, as this is a direct request for an update to the guidance I've moved this into an issue on the Design System itself so it can be triaged in our next session. |
I am not sure how to interpret the placement of phase banner. Should it be directly underneath header but before main element? My main concern is that if the phase banner is in the main element, then it is read by screen reader at the beginning of the main content. |
|
I agree it's still not clear. The phrase "so that they sit directly underneath the header." suggests outside of the But yes your reasoning is correct, don't put the phase banner inside the main element to avoid clutter.for assistive technology users on every page. |
|
I propose a rethink of the phase banner. It doesn't satisfy a user need for the services that I'm involved with and doesn't appear to add a business benefit either. I've never understood what it's for and the guidance page doesn't say. I asked on slack and there were two suggestions: (2) somebody suggested it helps if a service is undergoing rapid change. Scenario 1 makes sense. I can see why scenario 2 exists but for most services and most users it's a moot point. As long as the user can get from the start to the end of the journey there's no benefit in the banner. The phase banner contains a feedback link. Here are my thoughts on that: (a) if it's important then there would be a feedback link for live services; (b) on our service in the last month, we got ~11700 instances of feedback, only 26 of those via the feedback link in the phase banner, the rest were from the post-submit feedback; (c) Of the 26 instances of the feedback some of them were requests for assistance and so the feedback link is drawing users away from our 'Get help with this page' link on the same page; (d) having a feedback link in a feedback page is too weird for me but that's what we do. In summary, I'm raising two separate issues: the first relates to the phase banner; the second relates to in-page feedback. These two issues can be considered separately. What do others think? |
36degrees
added
awaiting triage
|
Thanks fo the comments @terrysimpson99 - I've fed them back to our Standards and Assurance team here at GDS. |
|
Just an update on this. Some services modify the banner design. This can involve splitting the tag from the feedback link. It can also involve putting the banner below the page content. The hmrc app goes even further and has no phase banner which is what I think we should do. @timpaul has the Standards and Assurance team responded to you? |
|
Somebody previously suggested a phase banner might be useful to users if there's more than one version. However, the current pattern makes no reference to this or how to switch between versions. The Coronavirus dashboard is available in two versions and allows users to switch between them. Unfortunately it's inconsistent because it used an alert for the live site (because there's no phase banner for live). I think this is another reason the phase banner needs a rethink. See: |
|
Thanks again Terry. I've fed this back to the relevant team in GDS again. I think you're right that beta banners are trying to do multiple things, and not all well. Changing them requires close co-ordination with the Standards and Assessments team here in GDS, so I'll try and arrange a chat with them. |
|
There is inconsistency in how services apply the phase banner guidance. It's common for the feedback link to open in a new window. Some services warn the user by making the link text I found guidance on the phrase '(opens in a new window)' at: |
|
In the Government Gateway example above, it does open a new tab. Following guidance, it should have the warning text. I think the question is should the default example of the banner in the Design System open the link in a new tab. Possibly, as users might lose data and their place in the service if it does not. |
|
I propose some changes to the example text in the Design System phase banner pattern. There are currently some issues with the existing content:
A potential improvement could be to draw upon the example text in the Confirmation page pattern where we ask for feedback, which is 'What do you think of this service? (takes 30 seconds)'. For example, 'Tell us what you think of this service (opens in new tab)'. |
|
There are some services that are "live" but still claim to be in Alpha. e.g. DartCharge |
|
I'm not really sure how that works. Certainly runs counter to what we're trying to tell people about phasing their service, meeting the Standards, passing assessments, etc. If it is an unfortunate anomaly, should it be part of the x-gov pattern? |
|
We're currently testing the phase banner with the hypothesis that 'users that are not in the digital industry don’t know what the terms “alpha” or “beta” mean. Instead, users would understand the term “new service” and that could lead to higher engagement rates on the feedback link and reduce confusion.' Questions we're asking:
Results so far:
|
|
Live services don't get a banner at all. Which is odd. Perhaps we should use a banner that says "MATURE SERVICE. We don't want any feedback". Half joking. |
|
Hi, just to bring up the placement of the phase banner again, along similar lines to @rinto-c 's question, is the intention of the phase banner to be placed after the main navigation? |
|
The Get a fishing licence service has passed live assessment but our team do not want to lose the feedback link. We think the feedback is useful for users and for the service. Our current plan is to remove the status badge and keep the feedback text, as shown below.
|
|
@murfious congrats on passing the live assessment! Out of curiosity, can you give a rough indication of how many users (number or percentage) give feedback via the link? I've always found it to be quite low...! |
|
@frankieroberto, from May 2020 to April 2021 we had just over 1.5M users. Just under half of the instances of feedback had written comments. Some people may visit twice to buy multiple licences but we think those numbers are low, although we can not yet tell. We are currently working on something to enable users to buy several licences in one pass. |
|
Adding some notes that might be helpful to others. The service I'm working on, is currently in Alpha but has a 'live' (publicly accessible) aspect to it. The reason for this is because our service is also a 'platform' (a service to help people build other services) which necessitates it being publicly accessible to the users we're designing for and researching with, so that our team can test, try and throw-away various incarnations of it. Currently I'm testing a hypothesis that the content of our phase banner needs to emphasise the rapidly changing functionality as well as content of the platform/service. In other words, somehow tell users that it is a risk to form a critical dependancy on it (in whatever form it currently takes for them) during Alpha/Beta phases. Will post back when we have more. |
|
Hopefully this is the best place to report this rather than the colours discussion? We’ve had an accessibility audit on the beta version of the digital identity service and the audit picked up that the colour contrast is 5.16:1 between feedback link (#1d70b8) and background (#fff). This passes AA but fails AAA. Please let me know if you’d like to see the full section of the report for more information. |
christopherthomasdesign
moved this to Not published
in GOV.UK Design System: Discuss styles, components and patterns
christopherthomasdesign
moved this from Not published
to Published
in GOV.UK Design System: Discuss styles, components and patterns
We need to show a GDS phase banner[1] on all pages of the app in order to capture feedback from users or receive emails from them. In the main sub-sections of the app we will need specific links to feedback forms as well as a link to email, but on the home page we just need copy to direct users to email us. This commit adds the component to the header partial. We decided to sit it below the `mojPrimaryNavigation` because it did not look quite right sitting between the main header and the nav. Although the GDS guidance says to put it directly under the header, there's some discussion about this being the right place [2] and this seems like the right thing for us. [1] https://design-system.service.gov.uk/components/phase-banner/ [2] alphagov/govuk-design-system-backlog#57
We need to show a GDS phase banner[1] on all pages of the app in order to capture feedback from users or receive emails from them. In the main sub-sections of the app we will need specific links to feedback forms as well as a link to email, but on the home page we just need copy to direct users to email us. This commit adds the component to the header partial. We decided to sit it below the `mojPrimaryNavigation` because it did not look quite right sitting between the main header and the nav. Although the GDS guidance says to put it directly under the header, there's some discussion about this being the right place [2] and this seems like the right thing for us. [1] https://design-system.service.gov.uk/components/phase-banner/ [2] alphagov/govuk-design-system-backlog#57
We need to show a GDS phase banner[1] on all pages of the app in order to capture feedback from users or receive emails from them. In the main sub-sections of the app we will need specific links to feedback forms as well as a link to email, but on the home page we just need copy to direct users to email us. This commit adds the component to the header partial. We decided to sit it below the `mojPrimaryNavigation` because it did not look quite right sitting between the main header and the nav. Although the GDS guidance says to put it directly under the header, there's some discussion about this being the right place [2] and this seems like the right thing for us. [1] https://design-system.service.gov.uk/components/phase-banner/ [2] alphagov/govuk-design-system-backlog#57
We need to show a GDS phase banner[1] on all pages of the app in order to capture feedback from users or receive emails from them. This commit adds the component to the header partial. As with CAS1, we decided to sit it below the `mojPrimaryNavigation` because it did not look quite right sitting between the main header and the nav. Although the GDS guidance says to put it directly under the header, there's some discussion about this being the right place [2] and this seems like the right thing for us. [1] https://design-system.service.gov.uk/components/phase-banner/ [2] alphagov/govuk-design-system-backlog#57
We need to show a GDS phase banner[1] on all pages of the app in order to capture feedback from users or receive emails from them. This commit adds the component to the header partial. As with CAS1, we decided to sit it below the `mojPrimaryNavigation` because it did not look quite right sitting between the main header and the nav. Although the GDS guidance says to put it directly under the header, there's some discussion about this being the right place [2] and this seems like the right thing for us. [1] https://design-system.service.gov.uk/components/phase-banner/ [2] alphagov/govuk-design-system-backlog#57
We need to show a GDS phase banner[1] on all pages of the app in order to capture feedback from users or receive emails from them. This commit adds the component to the header partial. As with CAS1, we decided to sit it below the `mojPrimaryNavigation` because it did not look quite right sitting between the main header and the nav. Although the GDS guidance says to put it directly under the header, there's some discussion about this being the right place [2] and this seems like the right thing for us. [1] https://design-system.service.gov.uk/components/phase-banner/ [2] alphagov/govuk-design-system-backlog#57
|
Personal opinion but I think the feedback link should be removed from the phase banner. There are better moments in a journey to collect feedback, usually at the end of a transaction or set of tasks, so that we don't distract the user from achieving their outcome. Stephen Gill wrote about it recently. |
|
It'd be great to collect more evidence on how users don't understand the phase banner, especially the alpha and beta terminology. It's currently a poorly evidenced hypothesis! |
|
Just wondering if anything ever came of the discussion about moving the link to the end of the line. |
|
Has the placement of the Phase banner been reviewed in relation to other items that might sit in the same spot, specifically the Primary navigation component that I understand is making its way through to x-gov? 
|
|
2 things:
|
|
Does anyone have any insights on the effectiveness of the phase banner for generating feedback? I have a hypothesis that a lot of services use the phase banner as a convenient place to stick a feedback link rather than from any need to indicate the development status of the service (which I think we all agree doesn't mean much to users). A key benefit seems to be that it enables you to provide a feedback link on every page but I wonder:
Could a specific feedback pattern or component targeted at the right place in a user journey result in more and better feedback? |
and others
Use this issue to discuss this component in the GOV.UK Design System.
The text was updated successfully, but these errors were encountered: