https://insidegovuk.blog.gov.uk/2013/09/26/updating-smart-answers-and-calculators/

Updating smart answers and calculators

There are 3 main reasons why smart answers, tools and calculators take longer to update than normal (what we call flat) content.

They are often more complicated

This isn’t to say that flat content isn’t complicated - translating complex tax or legal terms into plain English is often very hard. If there is a logic change (eg, taking out a step in a process), we need to make sure that it won’t affect the rest of the tool. Or if there is a change to a calculation, we have to test it to make sure it works for all the possible calculations that the tool should do. Any change to the logic or calculations takes us extra time to develop, test and deploy.

More than 1 team needs to do the work

The content team will usually get a request to make a change to a smart answer through zendesk. We’ll assess it and see what work needs to be done (eg, a text change, rate changes or new step in the logic). After that, we usually check with the relevant department whether we’ve interpreted the change correctly by sending over an updated logic document.

Once we've made the changes we'll usually also send the department a preview of what the update will look like. A preview is a version of the smart answer that is not yet live on GOV.UK but has all the changes made to it. In that case, the request has had to be added to at least 2 backlogs.

The developers and the content designers have their own backlogs and standups because our work can be very different. So in one sprint, a content designer will assess the request and, often in the following sprint, a developer will assess the changes from their point of view. Most of the time this is straightforward and changes will be made without any problems. However, it could be that particular changes may significantly change a tool, or that more work will be needed. And all of that is assuming we're confident about making the changes without any user testing.

For new tools and smart answers, it can take a few weeks to make everything work, depending on how complex the calculator or tool is. If it follows a similar type of smart answer it could be made a lot faster. For example, register a death abroad and register a birth abroad have similar logic flows. However, the holiday entitlement calculator is a one-off. Most likely, there won’t be another calculator that can borrow its functionality - it is essentially custom made and will take a lot longer to develop.

We can’t publish smart answers like we can flat content

For content designers, getting new content published is relatively simple. A content designer can create a new piece of content or a new edition, do the work and send it to be reviewed. The reviewer will then approve or send back the content for amends. Once the reviewer is happy with the content, they can then send it to get fact checked or published (we call this role “2 eyes” or for short 2i). The 2i function is very important as it enforces our style guide and editorial standards. This is how we can have many different content designers but the content itself seems like it could be written by one person. No one can create a piece of content and publish it by themselves, it needs to be reviewed by one other person to get published.

Bespoke tools, calculators and complex smart answers are different in that they aren’t created in our publisher system. The developers have to change code and text for changes to appear in the new version. After that, it can’t just be published but rather is 'deployed'. There are only certain times of the day where deployments can happen and we don’t have a monopoly on them. Each different team at GDS has to book a 'deployment slot' or a time when the code they’ve updated can be merged with the rest of the code on GOV.UK. Even small changes need to be tested so they don’t break anything else on GOV.UK.

Requesting updates to smart answers and tools

When requesting changes through zendesk for tools, keep these few extra things in mind:

  • request the change as early as you can (about a month before the change needs to be made if possible)

  • be as detailed as possible (eg, include links to the relevant outcomes in the tool or smart answer)

  • let us know if it has to be deployed on a specific date, so we can book a deployment slot

  • make sure someone is around who can answer policy questions in case it isn’t a quick change

We don’t like to guess on updating content, so it is more likely your smart answer or tool will be updated quickly if the person who requests it can follow up on any questions we have.