Lots of government services require their users to report when things in their life or an organisation change.
This places a lot of responsibility on the user - they need a good mental model of the service to know what to report, when they should do it and how. It also generates a need for lots of secondary transactions and services: update this, report that, change this, re-apply for that.
The 'digital assistant' approach to designing public services could start to make things simpler and reduce the number of 'Report an X to Y' style government transactions.
After all, if services understand your past circumstances, why can't they use those circumstances to ask you the right questions?
Here are 7 possible* patterns (there are probably many more).
1) Recurring change
Some circumstances need updating on a regular basis (things like monthly childcare costs). The 'recurring change' pattern notifies users (via push alerts or sms) that they need to provide some information. The service should be smart enough to know the optimal number of days to ask this before any deadlines.
![A pictogram of a 'recurring change' user interface](/content/images/2015/10/Untitled-2-2.png)
2) Future confirm
If a user reports a temporary change of state, for example they are going on holiday or taking their car off the road, the service should be able ask the user if that state has passed.
![A pictogram of a 'future confirm' user interface](/content/images/2015/10/Untitled-4.png)
3) Date determined confirm
Similar to 'future confirm' there are some circumstances that the service should be able to determine from information it already holds, for example if it knows the user has a child of a certain age.
![A pictogram of a 'date determined confirm' user interface](/content/images/2015/10/Untitled-5.png)
4) Recurring confirm
A 'dead man's handle' style confirmation, so the user has to actively confirm: "does your cafe still have 12 tables on the pavement outside your business?".
![A pictogram of a 'random ignore to confirm' user interface](/content/images/2015/11/Untitled-5.png)
5) Recurring ignore-to-confirm
As above, but inaction is taken as confirmation.
![A pictogram of a 'random ignore to confirm' user interface](/content/images/2015/11/Untitled-6.png)
6) Random change
Ask a user to submit new information on a subject at random intervals to help keep their data up-to-date.
![A pictogram of a 'random change' user interface](/content/images/2015/10/Untitled-3.png)
7) Cascading updates
Sometimes the service will be able to determine if a change in a particular circumstance is likely to have caused a change in a related circumstance. For example, registering for a particular license or moving premises may ask the user to confirm information relevant to a related tax.
![A pictogram of a 'cascading updates' user interface](/content/images/2015/11/Untitled-6-1.png)
- No, they have not been tested, but then you can't build what you can't think of in the first place.