Building a local council website: How we got to a prototype we could test with users in 5 days
We’re working with Eastleigh Borough Council to make their website meet user needs.
I personally wanted to see how fast we could get there.
Starting by setting objectives
How do you know you’ve achieved something? By setting out clear, measurable objectives at the start.
We knew people come to a council website not because they want to, but because they need to. If we understood the jobs they were trying to do, then we could, for example, measure the time it takes doing them on the current site compared to the new. Less time may mean we’ve made it easier. That’s just one example, but getting away from “it should look nicer” and towards measurable human-centred goals makes for a more successful project.
Getting to job stories
We had a list of features, which, while prioritised, lacked actions for us to complete. Reformatting them into job stories allowed us to empathise with users and instruct us on how they would complete the tasks to fulfil their needs.
With such a large site, this activity took an hour and a half, but was well worth the exercise.
The four columns (below) link to the four user types that were identified in previous work:
- The Council themselves
Prototyping early with content
With any council site, the usefulness is in the utility of it. Users are on there to complete a specific job, such as paying their council tax, or finding out when the bins will be collected.
Getting to content design early allowed us to condense pages and all the while, inform the information architecture.
Because local government should follow the design manual set by government, there’s a prototyping kit made available for just this kind of activity that product designers like me can pick up pretty quickly.
Testing with users
Once we had a working prototype, we can test our decisions with users very early on — in this case, Day 5 of the project.
We started with our first group of users — residents. Putting scenarios to them (that matched up with the job stories) was our way of testing whether they could complete the jobs easier on the prototype. All the way through, I was busily making notes on areas to improve, specifically on content.
With a list of changes, we can adapt the prototype and conduct more usability testing to ensure that what we launch meets user needs.
There are business objectives that also need to be met and it comes down to the design balancing these with what users need.
Agile with partners
This is the kind of velocity that we like working at with partners. Hitting the hard stuff early and delivering value within a few days.
What happens with the prototype? Well, once we’re at a point where we feel comfortable with the direction, we’ll start building it and switch the testing from prototype to the actual site, continuing the conversation with real users as we finish.
We’re effectively getting users to “sign-off” on the product, rather than just the group who are commissioning it.
To me, design is more about problem solving and less about visual art. The quicker we solve the problems, the more successful we’re going to be with this, and other projects.
I write a weekly digest collecting the best in product design, users and coolness — take a look!