At LocalGovCamp, our designer Martin ran an interactive exercise that took attendees through a ‘consequence scanning’ exercise, as a way to predict and mitigate all the outcomes, both positive and negative, of a proposed piece of development.
In this case, the service under discussion was a fictional parking violation reporting app.
Let’s just repeat that, in case of any angry reactions: fictional!
So, what could possibly go wrong with a piece of tech designed to encourage residents to grass on fellow citizens for their poor parking? You can see how it played out in this video:
Now you’ve seen a consequence scanning exercise in action. If you’d like to understand more about the process, read on: this is how Martin explained the whole idea to us here at mySociety, with more detail on the underlying principles:
We’ve been working on a few sensitive projects recently – specifically our work expanding FixMyStreet Pro to cover issues of a more social nature, like noise reporting, antisocial behaviour, that sort of thing.
As experienced as we are with the ‘make a report by sticking a pin in a map’ style of interaction design, we recognise the need for extra care when applying this to issues that are about people, rather than things. There’s an increased risk of building a tool that results in unintended negative consequences; especially where the service concerns an area already prone to controversy.
mySociety Board member Jonathan Flowers put us in touch with Connected Places Catapult, who had been using ‘Consequence Scanning’ for this very thing, and we realised it was just what we needed.
It’s a structured system for drawing out the consequences of a new idea, and giving people a say in what actions are used to mitigate or address them. It originated from the Doteveryone thinktank, and CPC have taken it forward and customised it for their needs.
In Consequence Scanning, consequences are classified as either intended or unintended, with the important distinction that intended consequences aren’t always positive, and unintended consequences aren’t always negative.
The process is delivered in a workshop format and works best with a good mixture of participants with diverse views and backgrounds, directly involved in the service on both sides. This means ideally both service users and service officers should take part and be prepared to be honest about consequences. For this reason it’s important to create a safe space where information can be shared honestly and openly.
The process is split into three parts:
Part one: What are the consequences?
Part two: What are the positive consequences we want to focus on?
Part three: What are the unindented consequences we should mitigate?
This system works best on a new, but defined idea. If it’s done too early in the design process, the consequences end up being very general, or people bring their own assumptions and often focus on the wrong things. It’s best to bring it in once scope has been defined.
The primary function is to identify the consequences and not to “solutionise” the mitigations, but the group should be free to discuss possible mitigations where they feel it’s important.
We’ve been using Consequence Scanning in our work on noise reporting and antisocial behaviour, and it’s also proving useful for our internal anti-racism action group, where we want to understand the potential unintended results of any future development in terms of who our services reach, and who they exclude.
Image: Drew Graham
Here’s everything SocietyWorks is up to this sprint.
One big area we’re working on this sprint comes from our development roadmap.
We’re referring to it as a ‘photo first’ workflow, and it’d enable users to take a snap of a street fault and upload it as a way of initiating a report. This all keys into a piece of research we’ve done which found that reports with photos attached have around a 16% higher chance of being fixed than those without.
As part of our exploration, Developer Dave’s been training an AI model to automatically scan each image and guess what category it falls into — very cutting edge!
But at the same time, we’re aware that we must keep every type of user’s best interests at the heart of all our development: we don’t want to sacrifice the simplicity that’s always been the key to FixMyStreet’s success, and the reason it has such vocal advocates amongst its citizen users.
As an example of this: as we assess the available technology to help us work on this functionality, we’re being resolute about basing decisions on what the job needs, not which product has the most bells and whistles.
An avenue we’re also exploring as part of this work is the potential for extracting geolocation metadata from the photograph, which would cut down on the amount of detail the citizen needs to type in. However, here, again there are balances to be struck: we don’t want to increase the potential for errors where a phone’s GPS isn’t accurate enough, or where the data we pass onto councils isn’t as precise as they need it to be.
Meanwhile, Designer Martin has been looking into the user experience on mobile, making improvements for what is increasingly the most popular way to report.
We’ll soon be making the existing app redundant in favour of Progressive Web Apps (PWAs) — Martin’s work will still be relevant there, though.
PWAs are more flexible, allowing each council to incorporate their own branding and templates at no extra cost, and effectively offer residents what looks and feels just like a dedicated app. We’ve written a bit about these previously.
Development continues on our Waste product. We’re integrating with Bromley and Veolia’s Echo system and doing plenty of testing around that — in particular, making sure it picks up on irregular dates such as bank holidays, and that it can handle the 48-hour window for reports of missed bin collections.
And, having completed our user research and consequence scanning exercises on the Noise concept, we’ve come to the conclusion that it should incorporate anti-social behaviour reports: Noise and ASB are so intertwined that it makes the most sense to combine them into a single service, albeit one that will divert each type of report to the relevant council department.
Feedback from our test users was all good, so we’ve now reported our findings back to Hackney and are waiting to hear if they’d like us to progress with integrating with their two back-end systems.
Meanwhile, you can see more about consequence scanning in the well-received session Martin led at LocalGovCamp a couple of weeks ago.
We’ll be conducting one of our regular scheduled pen tests to ensure the security of FixMyStreet Pro.
We’re setting up a new instance of FixMyStreet Pro for our latest client: this one involved Symology, a system we’ve worked with extensively in the past, so it should be reasonably straightforward.
Hackney’s instance, an Alloy integration, should be going live by the end of this month, so we’re making plans for that.
One exciting feature here is that we’re looking into pulling ‘completion’ photos out of Alloy — that is, photos taken by the maintenance crew to show that the problem has been fixed — so we can display them on the relevant FixMyStreet report, and possibly also include them in an email update to the report-maker.
Welcome to the first of our sprint notes.
For anyone who’s interested in our work around Noise, or who would just generally like to understand more about how development is managed at SocietyWorks, these regular catch-ups will allow you to follow along as we progress through the various stages of making a new service.
So: here’s what we did last sprint.
In our last post we explained how we’ve been developing a new Waste service with the London Borough of Bromley. At the same time, we’ve also been working with the team at Hackney Council to develop a simple, efficient path for citizens’ noise reports.
As with our explorations into Waste, the work on noise first required us to learn a lot in a very short period of time. What exact form do noise reports take; and how can a citizen make a useful, actionable report if they’re not sure precisely where the noise is coming from?
We also had to examine the characteristics that would class a report as an anti-social behaviour (ASB) complaint, and whether the report path should differ for these.
We’re now at the stage where we’ve created early prototypes for two workflows — noise-related ASB reports, and standard noise complaints. Next we’ll be thinking about whether the two journeys can be combined into a single tool.
The handling of ASB reports carries its own potential hazards: we need to consider the possibility of unintended harm, such as the stigmatisation of at-risk individuals and families.
The team at Hackney are well aware of the risks: and introducing process efficiencies through a new online service could make these issues much more acute if not considered properly. As such we are conducting an extended discovery process to go deeper into these issues upfront.
During our workshops with Hackney so far, we have been able to look at the positives and negatives from the different viewpoints of council staff, citizens and the wider community, incorporating ‘Consequence Scanning’ into the discovery.
This exercise was originally developed by Dot Everyone and has more recently been adopted by Future Cities Catapult. It ensures everyone can take a 360 degree view of the possible consequences — both positive and negative — that might arise from a new service design, and consider what additional mitigations might need to be put in place.
Armed with these insights, we’ve created an alpha version of the Noise reporting tool that we’ll be sharing with Hackney shortly so that they can test it and give us feedback for the next phase.
Our Designer Martin, who ran the workshops, says, “There’s a limit to what you can find out verbally, so we aim to get to the alpha version of a service as quickly as we can.
“The knowledge and understanding we get from seeing people using a new service for the first time is invaluable and can be immediately fed back into the design process to become improvements or new features.”
If you’d like to chat or find out more about how we’re progressing with the development of our noise services, or any other aspect of the SocietyWorks local government suite, then please contact David through our online form or the details at the foot of this page.
Image: Brad Stallcup