Are we confident that this pattern has had enough testing across a range of services to be sure this is the best way to solve this problem? – Would different approaches work better for different combinations of sign-in methods or services?

That sounds good. It might help to add a bit more clarity as to how confident we are with these if this content is being shared more widely.

Rather than having several pages confirming that details are correct, could we just play back all the users data on a single page and have some kind of ‘Yes, these are correct’ option at the bottom and ’Change my name/DOB/address’ options beside the data, similar to the examples here? – presumably the majority of users data will be correct, so it might allow many more users through with a few fewer clicks.

Does allowing the user to change their own details open up opportunities for fraudsters to Verify themselves at one address and then use a different address to get a permit wherever they want? Also, if they change their address, what happens to that data? Is it somehow fed back and updated on the IDPs side? Would users expect this to be how it behaves?

Caroline JThe most natural reading pattern on forms is to look for the next box to type into / next question to ask, and the first place that people look is immediately under the left-hand edge of the previous text box.

This is particularly important for users of screen magnifiers, who have to laboriously search in other places if they don't find the button where it ought to be.

Make sure the button text clearly describes the action that the button performs (not the action performed on the page the button takes you to). So for example, on the screen before a payment screen use 'Proceed to payment', not 'Pay now'.

Caroline JIf the action of the button changes, then change the text of the button to match the action

If the action of the button is simply to continue to the next page, it's fine to use 'continue' repeatedly.

if the action changes, then change the text to match it. For example: 'Find address', 'Proceed to payment', 'Review your answers'

We slightly prefer 'Continue'to 'Next'

'Continue' is a verb implying progress, so is slightly more suitable in this context. Continue' is a little easier to combine with other words than 'Next' (for example, some services have buttons labelled 'Save and continue'.) 'Save and next' arguably sounds a little weird.

We slightly prefer 'Next' for navigation links like pagination, where no user data is being changed. 'Next' works better in places where users may wish to step backwards and forwards through pages: it combines nicely with 'Previous'.

The GOV.UK Verify team has tested journeys that use 'Next' for the parts of the journey on GOV.UK and 'Continue' for parts on the identity provider. Partipants don't notice any difference and don't comment on the change.

Buttons are for performing actions, not making choices. Try to establish the convention of a single, strong call to action on each page. If you need your users to make a choice, use something else like radio buttons. Alternatively, if one choice is much less important then try styling it as a link instead.

It only shows up for an application where a user must create an account to use the application, and we have two user groups those that don't have an account and want to create one and those that have an account and want to return to them.

did you investigate having that as a decision, with a continue button? dunno if it'd be better or worse - Are you starting a new application, or returning to a saved form? Purely from research on Verify, I'd be worried that people saw the 'Apply now' as a strong call to action, regardless of their situation (we had [verify my identity] [I've already been verified])

It's similar to LPA's start page: https://www.lastingpowerofattorney.service.gov.uk/home 'apply now' means create an account and start filling in the form 'Return to your saved form' means sign in to the 'account' you created earlier and complete or continue to work on your application.

We tried an approach closer to LPA's 'sign in' but found that too many returning users missed the 'sign in' link and started with a new application.

Definitely a pattern here - apply / renew is very similar. I wonder if you make the first question after the 'Apply' button "Are you renewing your X or are you applying for the first time?". Particularly for low-frequency transactions where you might only use it once a year people might need reminding.

Another option: if someone goes down the 'apply' path but enters an email address that's already been used, get them to sign in? Might be security issues here...

We currently use one page with a 'double' button design on Passports. It's certainly not something you want on every page, but it's worked for us for where we have two equally weighted forward paths. We also tried doing it as a question with a radio, but found the choice was clearer in this case with the dual buttons. We may revisit later.

Re 'Apply now' and 'Returning users' - I've always thought this part of our start page journey was the most broken. Having a returning users link only after they click 'apply now' feels like hiding it. It feels like some users would be very hesitant to click on apply now, knowing that's not what they want.

Personally, I'm not aware of any research on Register to vote, HMRC or Verify that people weren't clear on the buttons - not to say it hasn't been a problem elsewhere. However, I think the 4 points stand anyway - if it's not a button it shouldn't look like one, few buttons is simpler, same for long text, and actions are good

I'm really not a fan of faded buttons - much better to have buttons always 'work' and if there's a problem, be explicit what the problem is. A faded button shows there is a problem but doesn't say what.

Feels like it's usually better to avoid needing them in the first place. However, are there situations where they might make sense? Where you want make the scope of the UI clear, but indicate that something is blocked? I'm thinking more for complex interfaces (admin / caseworker?) rather than service ui. The best solution is to design out the need for them.

Agree with Ed Horsford. If you've got a complex piece of software that people are going to use repeatedly (rather than as a one off) seems like greyed out buttons could make sense. Thinking of something like Photoshop, for example.

yes thats true, in Sketch, the 'send back a layer' is greyed out when theres nothing selected. You could have it show a message on click, but its quicker for an expert user to see that the button is greyed out and assume its because nothing is selected

Or zoom in and out in maps. It's odder to have the zoom in button disappear than having a consistent interface. Worth keeping in mind that these use cases are nearly all very rare on the services we make.

I think it depends on the context. We normally use 'Back' would to take the user to the 'page they were previously on' - ie not a specific page. Though there may be contexts where it could be closer to how 'back' is used on iOS - ie up one level.

In this case the user has started on 'Business overview', gone through a process to amend business details and at the end of this clicks to return to 'Business overview'. So in their mind they are very much returning to 'Business overview' rather than continuing to it.

If this green button is on a screen that confirms the amended business details, 'Continue' would be my preference. If it shows amendments that have not yet been confirmed, it would be 'Submit'. 'Back to business overview' doesn't seem a CTA; if the user would logically expect to return to business overview after confirming amendments, 'Continue' makes more sense. However, this is just one example and the query I received was more in general about use of capitals when referring to screen titles.

hm, good question on capitals, I'm not sure to be honest - We normally use sentence case throughout. So "Continue to business overview" or just "Business overview" - but this might be a question for a content person like Stephen Gill

I think it's sentence case. You either understand what we mean by 'Back to business overview' label or you don't - I don't think capping up 'Business' helps. If people don't understand what you mean, the answer is probably to change the label.

Hi Adrie. Elsewhere in the prototype I've used a green 'Save and return' button for the final action in a series of screens that returns you to the 'index' page. Not sure if it's appropriate here - but if the link is saving data then it should probably be styled as a button.

Caroline JThe most natural reading pattern on forms is to look for the next box to type into / next question to ask, and the first place that people look is immediately under the left-hand edge of the previous text box.

This is particularly important for users of screen magnifiers, who have to laboriously search in other places if they don't find the button where it ought to be.

Make sure the button text clearly describes the action that the button performs (not the action performed on the page the button takes you to). So for example, on the screen before a payment screen use 'Proceed to payment', not 'Pay now'.

Caroline JIf the action of the button changes, then change the text of the button to match the action

Lee Crossleywe’ve seen auto tabbing bomb in testing. It confused everybody, including highly skilled users. They’d be keyboard tabbing through form fields and not looking at the screen. There is an argument however that it could be useful for internal data entry interfaces.