Why are people really using your website (and who are they)?

Before I started working in digital, I worked at a venue myself, in the box office. This was a long time ago (pre-smartphone 👴), and we always had a constant stream of staff from other departments checking sales figures with us. It was relentless: people would come in person, they’d radio, they’d phone, they’d text, they’d email. The sales figures informed everything else the organisation did, from staffing, to ordering bar stock, to marketing campaigns, to front-of-house planning.

The same is true at Ronnie’s, except nowadays everyone does have a smartphone — and at Ronnie’s, lots of people also have logins to the website. As a result, everywhere I went at the club, I saw people surreptitiously checking sales figures on their phones. The managing director on the stairs to the back office; the maitre d’ on the podium during a show; the bar manager in the pre-show staff briefing.

It quickly became clear that there was an important user experience consideration here. More importantly, it was a user experience which the existing website wasn’t properly catering. Aside from the fact that the website CMS wasn’t responsive on mobile, staff who really only needed to see how many people were coming through the doors tonight were logging in through the same full fat system as a box office manager. That meant wading through multiple screens that weren’t relevant, just to find a single number.

But we never would have known this was a problem (or any of the other things we uncovered) if we hadn’t spent all those days upfront observing how the club actually runs.

The Ronnie’s project is a special case, obviously, because it has its ticketing built in. But don’t kid yourself that your plain vanilla website isn’t used across your organisation in ways you don’t expect.

We’ve worked on projects where it turned out that the “Contact Us” webpage was accessed most often by the company’s bid writers, who used it to copy and paste the registered address into RFP documents. We’ve worked on projects where the front-line staff who answered the phones had a single page to which they always directed callers for answering common questions (newsflash: it wasn’t the FAQ page). And we’ve worked on projects where the marketing team used the website’s old event pages as a sort of wiki about past shows at the venue.

In all those cases, you’d better believe that if those pages were moved or removed by a well-meaning website rebuild project, you’d hear about it — and not in a complimentary way! This is why we knew it was so important to spend time embedded at Ronnie’s.

Still, for many website projects there’s no need for your web agency to shadow you at work for a few days, nor is there time or budget to allow for it. So when you’re starting out on your own website project, how should you prioritise what kind of research to do?

1. Use existing data. You probably already measure your website’s success in some way, whether that’s through Google Analytics, or proportion of total sales through the website, or even just the number of confused phone calls you get from customers. So take advantage of that data you already have to establish some benchmarks and find insight. What do the successful pages have in common? What pages is nobody visiting? Can you work out why?
2. Ask everyone to contribute. This doesn’t need to be an exhaustive or even a very involved process. You could just send a single, simple email to the whole company — or a representative sample across departments, depending on the size of your organisation — that says, hey, we’re rebuilding the website, do you have any ideas about what the new one should look like? For those people who use the website every day, you’re sure to hear from them, whether they love it or they hate it.
3. Talk to the people who talk to your customers. Proper, comprehensive audience research is often beyond the budgets of smaller website projects (or even bigger ones). But if you can’t talk directly to your customers, you still have a great proxy for them in your front-line staff. These are the people constantly answering the calls and emails when the website goes wrong, and so they’re also the ones who know what your customers are actually trying to do with it.

Getting all this insight is only part of the problem, of course. You also need to work out what to do with it all.

With so many different ways to carry out research, there’s obviously no single “right” way to collate your findings and turn them into actionable plans. The best format for digesting your findings also depends on what you hope to do with them. Is it meant as a checklist for your developers? A starting point for a larger discussion with the project team? An executive summary to persuade a board of directors that the website needs more funding? Each will require presenting the information in a different way.

With Ronnie’s, we distilled all our research into one giant document of “Key user tasks” that the website and ticketing system needed to provide for. We divided these by user group (e.g. customers using the website, box office staff, finance), and then used this to prioritise each task with the internal project team at Ronnie’s using the MoSCoW method (Must have, Should have, Could have, Won’t have).

What we didn’t do, however, was write a clear spec for how to implement a lot of these features. That was because we wanted to rapidly prototype and iterate as the project went along, having Ronnie’s staff use early versions of must-have features to ensure they worked as required. The prioritised list of key user tasks was vital here, because it meant we weren’t doing that prototyping in a vacuum. Whenever we reached a decision point about how to build something, we were able to look at that bigger picture document and make sure we weren’t going to hamstring ourselves further down the line.

This process worked for Ronnie’s, but on other projects we’d do things very differently. (On other projects we wouldn’t dream of starting development without a really clear spec for every feature!) The important thing, again, is to ask from day one why you’re doing the discovery. That will ensure you talk to the right people at the start of the process, it will make it easier to sift out the most helpful insights as you go, and it will give you a better idea of what you need to come away with at the end of it.

And with any luck, it will mean that, when your new website launches, everyone who uses it will be able to do the things they really want to.