Good design is environmentally friendly

There probably aren’t many carbon emissions which can be saved by adopting Jony Ive’s clean minimalist UI design aesthetic over something more 1980s looking, it’s true, and big flashes whilst causing a lot of visual pollution on the screen aren’t really responsible for the degradation in water quality or reduction in biodiversity. But what about Service Design? And Infrastructure Design? 

Does the Service Design introduce myriad steps into a process for which the necessity is arguable? Extra steps means extra work means extra resource means more energy expended in delivering the service. If extra steps also mean copying data from one system to another, rather than the service end user using the exact same system to work in that the citizen end user uses to make the request in the first place, that’s duplication, triplication, quadruplication of data in a data centre. Which then introduces the matter of data retention periods – it's inevitable for the time being that there will be some duplication of data occurring because the creation of One System To Rule Them All isn’t coming any time soon. 

So when the citizen user completes a missed bin collection form, that might result in the form submission being stored in the form database, an email being sent to a service mailbox, the submission being stored in the CRM database, and then also being stored in the back end line-of-business system. That’s four systems all holding the exact same data. There may be good reasons for all four of those systems to be holding that data for a period of time, but do they all need to hold it for the full five years your global retention policy specifies? The financial cost to the organisation of keeping huge amounts of data for long periods of time may well be pennies, but there is an increasing understanding that the carbon cost of not just lakes but oceans of data languishing in data centres long after the user of that particular system’s need has passed is not a trivial one.

You should only purge on creation for any given system in the chain if there’s a defined security reason to do so – such as where financial details are taken – because glitches in a chain always happen and if you have a copy of a form submission everywhere for a reasonable minimum period of time you can recover it if an error has occurred. But consider which systems in the chain can have a retention period of one month, which might need three months, or a year, or 18 months. Can you design your data retention in your systems in such a way that means you can purge non-essential parts of a submission but retain essential parts – for example, when compiling management information and comparing year-on-year trends, you might only need to surface the number of pothole reports in any given ward and the size of them, you won’t need to compare the free text details where the citizen went on to mention the pothole was just in front of the Spar and kindly provided a photograph too.