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.

The kickoff meeting (and me understanding accessibility requirements for Government websites!)

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:

• Residents
• Businesses
• The Council themselves
• Visitors

Transitioning features (yellow post-its) to job stories (orange) — Photo by Will Ayling

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.

The current prototype using the GOV.UK prototype kit. Visual aesthetic will be improved, but unlike other projects — we’re going to look at that last (done is better than perfect)

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.

Our first usability testing workshop with real users. Tea and cake and some background music helped soften the mood. Bunting next time.

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.

Scenarios. I tried to keep them realistic!

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!