-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider more generic public body questions #1057
Comments
Importing some comments I made elsewhere:
The code complexity is a concern for me - the usability less so. Reason: It's a one stage click-through, choose the right option and the form appears. The technical side may need refinement! Elaborating on usability: The key thing here is simplicity - we render the public body questions where the request form would usually be (save for WDTK Pro, and if memory serves, users without JS enabled). The form is a list of radio buttons, it's a one step process to click the option most applicable; therefore, provided the wording is plain and simple, there doesn't seem to be much risk here.
This risk is minimised by being careful as to how we word things, and being clear about who/what we are. If we do this, we can minimise the current risk - we've certainly had more than a few users in the past who, somewhat inexplicably, thought they were dealing with the public body directly. Quite how they manage it, I'm not sure. IMO, we don't want to be seen to be giving advice on these matters - it's generally outwith our own expertise, and we can better serve people by linking to official sources, and / or reputable sources (e.g. Citizens Advice). We should always be clear as to why we're doing that. The expansion of this toolset has been with the aim of minimising misuse in a number of public bodies where we see persistent patterns - there's possibly a good bit of anecdotal evidence there, but also general observations from WDTK team members. A common pattern is outlined in #722 and #745 - the TL;DR summary being: "quite often we see the service being misused by folks trying to access information about themselves, or to make customer service queries to public bodies about sensitive matters. We need to act to minimise the risk."
I don't think we can at the moment, based on the code that is in Alaveteli - without refactoring. There's certainly some merit in looking at a generic "What are you asking for?" question, so I wouldn't be dismissive of us exploring the art of possible. @RichardTaylor had noted in response to this point:
… in essence, however, I'm not sure we can always be so generic. The research that generated the questions proposed for #745 (comment) was based on identification of the key themes behind misuse for that type of body. I don't think a one size fits all approach would work for all bodies, as it'd essentially just replicate the warnings that we already provide in at least two places during the new request workflow. We've refined these over years, and used public body notes to further outline our approach, but it doesn't necessarily dissuade users who see our service as a contact form. Providing a specific pointer may dissuade misuse. Perhaps there's scope for some a/b testing here? With that said, I think a generic approach for bodies we haven't identified specific patterns of misuse / inappropriate usage from might be interesting - if we can make things more user friendly, and simultaneously reduce risk, it's to everyone's benefit. |
I don't think we should replace the specific interstitial questions with a more generic approach where we've already got specific questions. The suggestion is: Can we do something generic that we can easily add to a wider group of bodies? To clarify what's been quoted from me, I'll add a bit at the end:
|
I think we should consider this on the basis that I feel like we're a little at risk of looking too "official". I'm not saying there's definitely something we can change; just that we should consider this as we review what we have in place. |
Are we being more controversial than what we already do with the Home Office? The risk with the benefits ones is there’s often special category information involved - so if we can dissuade them by offering a “you can’t do that here - use their website or contact an advice service” that seems a reasonable thing to do. My suggestion here would be: we have a generic boilerplate which attaches to each question via an include - it would be no trouble to add a “why am I seeing this?” link that branches out to a help page which includes a reminder as to who we are and gives an overview of why the question appeared. It’s not strictly necessary, but it does feel like a nice to have. |
A pre-request question requiring a user of the WDTK public service to confirm they understand they are making their request via our public service, and not directly and privately to the public body could, if carefully phrased, help prevent confusion between our site and official direct contact forms. This would be extra friction for all users though. We could target it on bodies which receive sensitive direct correspondence eg. police forces. |
I ought to have noted this here - originally posted in #722:
|
This issue is being closed due to a lack of discussion or resolution for over 12 months. Should we decide to revisit this issue in the future, it can be reopened. |
We've now built up quite a selection of pre-request questions for a handful of bodies, and some more on the way.
These attempt to minimise misuse, and the subsequent risk of misuse, as we find there are quite a few individuals who misunderstand the purpose of the service. While we haven't measured, there's a feeling that these have reduced misuse on at least some bodies.
We should reflect on our use of these, as they do have some downsides.
I think the thing to consider is whether we can refactor the current questions into a more generic set that applies to all of the bodies identified as needing this extra step.
The text was updated successfully, but these errors were encountered: