When “website” means different things to different people
sometimes you need to explain it

Abstract image of 2 colours

Earlier this year, I took on a project with a private sector client - a large company, working on something for a government department. I was effectively a sub-contractor, working with another sub-contractor, and we were on hand to help with content design, clarity and accessibility. Pretty typical stuff.

Our task was to help a small team create some “guidance” on a particular topic. Me and my co-contracting buddy put our heads together and quickly decided that the guidance should probably exist on the internet. That was the obvious home for it.

But there was a problem. Until we piped up with this suggestion, both the private sector client and government department had imagined and assumed that the end result would be a document of some kind. They were expecting something that looked like a Word doc, or maybe a PDF, that would be sent out to many different stakeholders once it was “done”.

When we first said: “This should be a website,” the good news was that the team we were working with weren’t against it. In fact, they were keen. The problem was higher up the command chain: the bosses were uneasy about this whole website idea.

It took a while to work out why.

After a few calls and bit of prodding, it emerged that those bosses had only ever worked with websites in a particular way: as expensive projects that had to be “commissioned”.

To their ears, us blithely saying “This should be a website” sounded like more work, and more expense. To them, it sounded like we were saying: “We can’t solve your problem with mere content design, clarity and accessibility. You need to spend more cash on web designers too.”

That’s why the message didn’t go down too well.

So, my co-contractor and I worked on a slightly different message. We had to make plain that saying “This should be a website” also meant “This should be a website, and we have enough skill in the existing team to build the first version of it.” Between us, we knew enough to make a working HTML prototype using the GOV.UK Design System. No commissioning necessary. No additional cost.

What’s more, we had to make clear that websites don’t always have to be expensive projects that you commission. They don’t have to be things that suck up time in meetings where people discuss “how the navigation is going to work”. They don’t have to be, in short, a big deal.

Websites like this can also be things that you build a little bit of, really fast, and show to someone in a browser and say: “Here’s a first effort. Obviously we’ll add the missing bits later this week.”

It didn’t take us much time or effort to change their minds, and once we had, things moved faster and more smoothly. We built an alpha, did some lightning-fast, remote-only user research, iterated and improved. We ended up with content ready for the web.

The eye-opening thing about this project for me was that there are still people in senior positions, in large companies and in government departments, who have this fixed vision of what “This should be a website” means. They still think it’s a big deal, a big thing, a big hassle. I mean, sometimes it is: but it doesn’t always have to be.

Filed under: work
(23 December 2021)