Save time, money and hassle without sacrificing take-up, usability or efficiency – 8 commonly-requested things that you don’t actually need to build into your consultation system

Writing a specification for an online consultation system can be a very cathartic exercise. You can set out all the things that bother you about the way things are done at the moment, all the things you might like to do someday, and then throw in some of the stuff you’ve been told is needed or read about online for good measure. However, people too often try to buy software without knowing how it works, what it’s really for, or thinking about whether they’ll have the time to get it working properly in the first place.

So, to help, here’s 8 things we see fairly frequently where there’s an easy opportunity to improve things by simplifying them…

1) Mechanisms people don’t actually use: discussion forums, online conferences etc
There’s an exciting plethora of interaction mechanisms on the internet;  surveys, polls, discussion forums, blogs, Twitter, video-conferencing, Facebook, email, Wave, games, SMS-controlled writing robots, voting tools, IRC, asynchronous YouTube video conversations, Bluetooth data points, even mobile social games where you can tell burglars what you’re doing at any given moment.  That doesn’t mean they’re all appropriate for consulting with citizens, though.

Of course, wanting to open up as many channels for interaction and make it easy for people to engage where they’re at is a laudable aim. But that’s just the point: the best mechanisms are those that people are happy to use, and use in the context of what is still a largely formal, official process.  So Wave isn’t ideal because, well, no-one understands it and it isn’t very widely used.  By contrast, YouTube might look tempting because it is very widely-used, but the problem is, we’ve found that people aren’t comfortable having government ‘butt in’ on their social space.  Sometimes, a more arm’s-length approach is actually preferable.  See diagram below for the ‘sweet spot’ of what people will actually use:

The short version: you don’t need to spend money creating obscure or frivolous channels for interaction. Certainly not before you’ve got the basics well-established, at least.

2) Mechanisms that already exist: bespoke e-petitions/collaborative editing etc
Similarly, why look to buy software when sometimes these mechanisms already exist in a self-contained format that can be used for free? For example, want e-petitions? Then try MySociety’s open-source e-petition tool. Want collaborative document creation and editing? MixedInk‘s free in-line commenting tool works just fine for us here.

You don’t need to spend money duplicating this work. Better to invest in a good central hub that can accommodate all of them and get used to working in diverse ways, rather than try and shoehorn everything into one uber-system.

3) Super-advanced search
Search is so tempting – everyone can think of a hundred and one ways they’ve once wanted to find something and so surely the system should support all of these, and more, right?  The problem is, this quickly tips from usefulness into a baffling overload: ‘we need users to be able to search and sort by postcode, interest, event type, whether it’s on a Tuesday, the hair colour of the person in charge of the consultation, the number of participants in similar things last year, the exercise’s internal reference code, the number of questions, the allocated budget, the preferred response mechanism, the distance travelled by participants, the estimated carbon footprint, the number of chairs used, the frequency of the word ‘user-friendly’ and 101 other things. Don’t we?’

No, no you don’t.  It doesn’t take much pushing of this mentality to its logical extreme to see how silly it is. We all know really that it’s always a trade-off between thoroughness and usability, and we’ve found that normally works best when you come down on the side of a simple system and helping people to do their jobs, rather than trying to automate absolutely everything.

You know what, if you really do want some nifty searching by multiple variables, why not export your data in .csv format and open it in that copy Excel you already have installed? You can sort that away to your heart’s content.

4) Calendar functionality
A calendar functionality for displaying your consultations seems intuitively like it might be of use. However, our research has found that they actually receive very limited use both internally and externally. In fact, the main use for them tends to be internal, to monitor the volume of consultation running at any one time, which is why we are developing a Gantt chart export of consultation information for the London Borough of Sutton, who also initially believed they wanted a calendar functionality.

If such a functionality is imperative though, then why not just set up a free and widely used package such as Google Calendar? A similar approach, not using Opinion Suite, is currently used by Cardiff City Council.

5) Total integration into Sharepoint or similar
So many organisations seem to think they need whatever they get to integrate with everything else they already have. It’s classic unnecessary IT tinkering.  What would you actually do with your consultation system being ‘totally integrated’ with Sharepoint or your existing CMS/CRM?  It’s a horribly expensive way to try and get two specialist tools to talk to each other with little tangible gain.  Quite apart from worrying about software integration, can you even hand on heart say that all consultation activity is integrated and joined up across your organisation at the moment? Perhaps worry about the people first, before the software.

However, it can be useful to have some flexibility available, and find the points where you really need to get systems hooked up by finding a lightweight way to support that. We’ve found RSS feeds from a system are great for this, and are pretty much as much as anyone realistically uses.

6) “Sign up for notifications about consultations of interest to you”
It sounds great doesn’t it, the public can say what they’re interested in, and the system will email them alerts automatically about consultations that match those interests. You know what though? No-one does sign up. Really. We’ve seen it in systems we’ve done, and we’ve heard it from other authorities too, the number of sign ups for such a system is generally in single figures. Sounds odd, but it’s not if you think about it. People suffer from email overload as it is these days. Is an occasional email from your local council about its consultations really that exciting a proposition?

People do though sign up to be notified of the outcome of a consultation once it’s closed and been analysed. They have an interest in that process, having taken part in it. Even then, you can just ask users for their email address and whether they’d like to be notified of the results as part of the questions you set up in an online survey. Simple.

This point is odd when you think of point 5 too. On the one hand people want their software systems fully integrated, but then want an isolated contact list for people interested in consultation. One of the best things we’ve seen done here recently is at Bristol City Council, where they’ve just started integrating consultation information into their regular newsletter, which people do sign up to.

7) Nice ideas that break the law: deleting users, comments, etc
In the heads-down work of specifying and designing the perfect consultation system, it’s easy to lose sight of the bigger picture or to overlook side-effects of certain decisions. Often, legal details fall foul of this process and, of course, this will invariably risk costing you far more money than the value added by the feature.  For example, we often see requests for the ability to delete users, or the comments they submit, from the system. A request born, no doubt, from the understandable desire to keep things neat and tidy.

But what if your consultation gets called in, appealed or legally challenged and you need to be able to have your entire process audited? “We deleted some of the responses we received, and we can’t bring them back” isn’t a response that works well either in committee or in court.

For all people worry about system and data security, the weakest link in your chain will always be the people using the system. You can’t delete records from accounting systems, you shouldn’t be able to in consultations either. Hide things from public view, moderate offensive comments into a hidden section, fine. But don’t go designing a system that’s going to lead you into trouble further down the line.

8 ) User registration
We see it quite a lot, detailed lists of requirements for user registration in a system. User registration is a difficult issue in terms of online consultation though, as often it presents real barriers to participation to the end user, and builds disengagement with the decision making process, whilst doing nothing to prevent multiple or fake responses.

We do use user registration at times, but we keep it light, non-complex and gradated to levels with which different end user profiles will feel comfortable. It seems to work well as an approach, but as an instinct we’d always recommend against it unless there were a real and demonstrable reason as to why it is needed.

One thing that often goes along with user registration requirements is the ‘need’ for the system to be able to send emails to different groups of people. This is rarely a good idea, at least for the public.  First of all, if you have a system sending automated emails, then this often introduces unnecessary security and usability issues into system. An email automatically generated by a computer rarely looks good, and if you let the system get on with emailing people. how much of an eye are you realistically going to keep on it until it does something wrong?

The more interesting point we’ve found though, is that such systems are again rarely used in practice. People in an organisation have their own email system, and that’s what they use to contact people. That’s why a better approach in this area is to allow comprehensive contact data exports from the system to be used with existing email packages by real humans. Attempt to replace commonly used software systems with new ones generally results in poor internal implementation and uptake, again giving poor return on investment.

So there you have it, 8 things you thought you needed to buy but probably don’t in reality. If anyone’s got any more to add to the list, then please do!