govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Help users know how long something might take (time estimation)
What
It may or may not be helpful to help users understand how long something might take, for example:
- to complete a form
- to get a response
- to read some guidance
It's arguably helpful for people to know roughly how long something might take so they can plan their time. However on the other hand, things can take longer or shorter depending on the user's situation, disability, etc.
If we do give estimated times, it would be good to discuss and standardise on how we estimate those times.
Why
This is something we currently do on Start pages, and Confirmation pages
A post in which time estimation was removed, and no issues seem to have been found: https://www.tempertemper.net/portfolio/a-minimal-task-list-pattern-for-govuk
Thanks for that post, which:
- confirms a suspicion I had all along about the 'not buttons that sort of might be buttons' in the task list pattern
- shows that removing times seems to have little effect on users.
Thanks. Issues that I think are relevant:
- Time estimates add content. If the content does not add significant value then it might just be clutter.
- Hypothesis: time estimates damage trust. I don't believe time estimates and I think many others don't. The estimate has an element of selling (to sell the interaction) and users know that.
- Time estimates are often wrong for the particular user. Even well-intentioned teams simply measure the sum of average page dwell times for the happy path at one point in time. There are many reasons why that won't match the experience of an individual. By definition, half of users on the happy path will experience longer than the average. Some users don't go the happy path. Some users make more than one attempt to get through a service. It's common in usability to regard the end of the ranges (minimum, maximum) rather than the middle. In theory, we'd publish the worst case duration but in practice the 99th percentile duration is pragmatic.
- Time estimates almost certainly aren't based on the duration from start to finish. They're only based on page dwell time and don't measure total journey time. So if a user logs out, or is timed out, they are using their time but it doesn't get counted as part of the time estimate.
- Time estimates don't get updated when changes are made to the service, the device proportions change, the demography of users change, etc.
- Time estimates are very difficult to remove or modify. In one case, the assertion was that a service took 20 minutes but it was fairly easy to identify that this was wrong. It could take up to an hour and in some cases several days (because users had to contact other people to provide answers). Unfortunately, anytime I suggested removing it, people said GDS required a value and the onus was on me to provide the 'correct' value.
- Time estimates are almost certainly wrong for users with accessibility needs.
On the major point, which is providing time estimates.
We need to distinguish between tasks and delays that are controlled by the user, such as:
- reading some guidance
- deciding where to find the answers for a form
Tasks that are controlled by government, such as:
- sending a response to an application
- making a decision on the application
- communicating that decision
And tasks that may have complexities in them that can be in the hands of third parties, such as:
- asking someone for a reference or other document to include in an application
- searching your own historic records/filing system for something that is not easily to hand, such as a birth certificate
- relying on a different government or official body for something, such as maybe applying for a birth certificate from a country that is not the one relevant to this form
It seems to be to be helpful to users and possible to create estimates for things that are wholly within the control of the organisation that is publishing the estimates. For example, we might say: After you send in your form:
- we will reply within 10 minutes with an email to let you know we received it
- we will reply within 4 weeks with the result
On the other hand, things that are wholly within the user's control or that are subject to third parties are very difficult to estimate, and can be demoralising for a user who reads more slowly or had trouble with concentration for reasons of disability or circumstances ("this was only meant to take 10 minutes but I'm still not finished after an hour! I'll never finish"
My substantive comment and @terrysimpson99's arrived at exactly the same time! I think we make complementary points and I agree with the ones @terrysimpson99 makes.
All good points!
I think an important aspect is people's expectations that they bring to a task:
On Register to vote, we found from research that people overestimated how long it would take, putting them off doing it when they had shorter time available. We found adding the estimated time (taken from many rounds of research) helped people go ahead and do it.
On Verify we found the opposite. People expected something that looked like registration/sign in to be very quick, but the digital identity process could actually take a long time. So again, trying to correct expectations we found to be helpful to users, instead of starting a process and not having enough time to finish.
Like Joe says I think there are two very clear instances where a "Time" indication would help - the first is where something which appears complicated is in fact quick and simple, "Bish Bash Bosh", and the other where a service, like LPA, requires preparation and forethought and which will take time, so make yourself a coffee first. So an indication of the kind of service may be more helpful than a estimate on time to complete :) Is it a "badger" or is it a "mug" job? :)
One place where I’ve seen time estimates sometimes used is for feedback surveys, where service teams want to encourage users to voluntarily complete the survey by reassuring them it won’t take long.
On Ethnicity facts and figures I tried to achieve this by referring to the number of questions instead (which is at least less subjective):
Answer 4 short questions to help us improve this website.
Response rate was still quite low though, so hard to know how much impact it had.
What we find at Companies House is that users tend to want to know how long a service will take to complete. They often have to bill for their time so they use that information as an indicator of how much it will cost to use that service. An example from one of our services is that one user billed in 6-minute blocks, so if the service took 10 minutes to complete they would bill 12 minutes. So keeping the service less than 6 minutes to complete and making sure it was clear the expected time it would take to complete was useful.
The other type of time users like to know is what has been mentioned above, knowing the expected time an application or a submission will take to be accepted or rejected.
The hypothesis appears to be:
- "Completion rate is greater if a time estimate is given compared with no time estimate". Has anybody done an AB test for that?
Does it matter if the time estimate is not the time value suitable for 95 % of users (as it is sometimes)?
@terrysimpson99
The survey methodologists research this sort of thing all the time. Have a look in the survey literature
Yes, I think it does matter. The hypothesis is couched in terms that suggest 'mean time to complete' (arithmetic average) to me. These times nearly always to follow a distribution where the mode is considerably shorter than the mean, but there are also some extremely long times that pull the mean upwards. It might be better to have a test that reflects a more useful estimate such as "Most people take around 10 minutes to do this, but we have heard that for a few people it can be an hour or more"