While it’s been fascinating to see the talk among Bristol’s developer community following the roundtable on Bristol City Council’s Future Web Platform, there does seem to be an element of discussion around the project that is conspicuous by it’s abscence – the end user.
For those not familiar with the project – BCC are commendably taking opinion from Bristol’s digital community on the re-development of the council’s website.
We attended the roundtable last week, and discussion there – and online – since has centered around the arguments for and against the whole gammut of open-source platforms and technologies.
This is a little like architects arguing over the construction materials for a building before finding out what the building is going to be used for. The danger is, you design and build a wonderfully constructed office block when the client wanted a car park.
The council has produced a reasonably detailed requirements document – but there is nothing in there that suggests any robust measure of end user needs has been identified, or that suggested functionality has been evidenced against any user needs.
A massive investment in time and resources is being put into identifying and developing a platform before anyone knows what the platform needs to deliver for the people using it.
We risk getting bogged down in a discussion about the most “appropriate” platform before answering the most important question – “appropriate” for whom?
For instance, a lot of the discussion at the roundtable centred around migrating content. But what if the content is part of the problem? There was little or no discussion about content planning, Information Architecture, usability or the end user.
These are the elements that need to be understood first – before any decision on platforms is made. Not least, because they will – or should – be the determining factor in the functionality of the site.
The website needs to do stuff for people who live in Bristol. This “stuff” is the reason for the existence of the site, the technology is simply there to enable this stuff to be done. The CMS is the servant of the project, not the master.
Different platform, same issues
Back in 2007, we carried out an information architecture and usability review of the Bristol City Council Intranet. The issues we discovered with the site largely centred around poor information architecture, out of date and unreliable content, poor search and lack of user customisation functionality.
We’ve just carried out a (rather unscientific) user review of the BCC website and guess what the main issues identified by our user group were? Yup – IA, unreliable content, poor search, no customisation.
No technology solution is going to address the issue of poor content, no customisation functionality is going to understand how people living in Bristol want to customise their site. These are all planning issues.
We were able to deliver a 700% increase in engagement with target areas of the BCC Intranet by making changes to the IA, content and layout of key pages.
The technology didn’t come into it – we had to work within the constraints of the existing intranet platform. Getting a thorough understanding of what staff at the council actually really wanted to be able to do on the intranet did.
However, we also identified that had we been able to change the intranet platform to a more suitable one, we could have made even greater progress.
When we carried out our work on the BCC intranet, we ended our consultancy by discussing the imminent upgrade of the council’s website. Our key recommendation – don’t go out and buy an expensive off-the-shelf CMS and try to shoe-horn your user’s requirements into it, start with the requirements and develop a CMS to match them.
Three years later, we’re sticking to that.