Case Study: Developing a new museum website

This case study is about the development of a new website for the Royal Pavilion & Museums, Brighton & Hove (RPM). As a local authority museum service, this was the first time they were permitted to develop a website dedicated to RPM. Preliminary work began on the website in 2013, and the site went live in early 2015.

Jump to:

What was the issue? | What did we do? | What happened? | What did we learn? | What one piece of advice would I give to other organisations?

What was the issue?

RPM had been managing a website independently from the Council since around 2000, but this was shared with the local library service. The previous version of the website had launched in 2009 and suffered from a wide range of problems.

The old site was built with Sharepoint, a platform that is primarily designed for document management and use as an intranet (a private network often used as a means of sharing information within an organisation). It provided very little flexibility, and even minor changes required expensive support from the developer. It had also been designed for desktop screens, and was almost unreadable on a mobile phone. By 2014 about 40% of our website visitors were using a smartphone or tablet, and it was clear that mobile use would grow rapidly.

The site was also compromised by the shared presence of museums and libraries.  While the two services may have been part of the same local authority department, their audiences are very different.  It also led to some people believing that RPM did not even have a website. On a couple of occasions I spoke to people who had used the website but were convinced that they had been using the main Council website rather than one managed by the museum.

Both of these problems were relatively easy to solve once we had the required agreements in place. By the time we came to start the redevelopment, we had permission from the Council to create our own dedicated website, and we were committed to using an open source platform (a platform usually developed as a public collaboration and made freely available to access and use, making updates easier and cheaper) with a design template that would work with mobile devices.

But there was another, trickier problem we needed to solve. We knew that the site was not working for our users from the frequent complaints we received from the public and staff, and we were committed to making the new site more user friendly. Yet it is easier to say this than to do it. While reading through the notes from the previous redevelopment project, I was struck by the fact that this had also started out with a firm ambition to make the site work for its users. So why had this gone wrong? And how could we avoid making the same mistakes again?

What did we do?

Our first step, before we even thought about the technology or speaking to a developer, was to do some research. Here we had an advantage over our predecessors, as we had a lot more data to hand than the team that had developed the 2009 version of the website.

Most of this data came from Google Analytics, which we had been using since 2011. We used this data to answer a simple initial question: what are people doing on the site? The analytics data gave us a good indication of what areas of the site people were using, and what parts of the navigation were working well against those that were seldom used. It was also a good opportunity to take stock of our online visitors, such as where in the world our users were coming from, and which collections pages received the most views.

One observation from the data proved particularly startling: over 50% of the page views across the whole site took place on just 11 pages. While that fact won’t be particularly surprising to anyone who has managed a website, it was a helpful starting point for persuading colleagues that some information, particularly pre-visit information, was clearly more important than others.

However, as useful as the Google Analytics data was, it only told part of the story. What people were doing on the website was obviously shaped by current constraints. What if users were trying to find content or do things that the site wouldn’t allow them to do?

This led to a second research question: what motivates our visitors? Here we built on Phase 2 of Culture 24’s Let’s Get Real action research programme. As a partner in this project, we conducted a survey of users visiting the website, asking why they had come to the site.

The one startling find from this survey was that people coming to the website saw us as a collection of buildings, confirming a pattern we could see in the Google Analytics data. This was partly shown by the high number of users who came for pre-visit information, but even those who were researching for professional or personal interest were more likely to be focused on our buildings than our services. This was in marked contrast to the website, which prioritised RPM as a collection of services, such as venue hire or learning, over the buildings.

I wanted to expand our understanding of motivations by using some form of visitor profiling, particularly in terms of understanding the needs of those looking for pre-visit information. The visitor profiles we had to hand were demographically based, focusing on characteristics such as age, gender, and socio-economic measures. Such demographic profiles are not always useful for understanding behaviours, and are particularly ill-suited to understanding online behaviours, as web analytics reveal (quite rightly) very little about these characteristics.

Without the resources or expertise to develop our own profiling, I turned to the work of John Falk, an American academic. In his Identity and the Museum Visitor Experience (2009), Falk describes a set of behavioural profiles based on individual needs that are derived from a fairly fluid sense of identity. You can find a good summary of Falk’s ideas here, but for me the key idea was that the visitor journey starts long before they arrive at the door of the museum. The motivation for the visit is quite likely to be rooted in needs that have little to do with what’s in the museum (eg needing to entertain a visiting mother in law on a rainy afternoon) and our website should be shaped according to these broader needs (eg emphasising the catering facilities).

This in turn opened up an internal conversation about our use of language. For example, museum professionals typically talk about ‘objects’ yet the public are much more likely to talk about ‘exhibits’. That seemed deeply counter-intuitive to many of my colleagues, but was easily demonstrated through a search on Google Trends.

What happened?

Once the research phase was complete, we appointed a developer, using our research as part of the invitation to tender documentation. I was keen that any developer who worked with us should respond to our research rather than presenting their own solutions based on questionable assumptions.

Once the developer was appointed, the website had to be built entirely from scratch. It took about nine months to develop from appointment to launch. In addition to the developer and RPM staff, our Access Advisory Group played a critical role in testing during development.

The new site solved many of the old problems at a stroke. Built in WordPress, it is now much easier and cheaper to maintain. WordPress is so easy to use and well-supported that many problems and enhancements can be dealt with in-house rather than relying on developer time. It also uses a responsive design template, so that it now works more comfortably on mobile phone screens.

The site was also shaped around our various museums, giving each venue the space to express its unique offer, and address its audiences’ particular needs.

In terms of measurable success, the results have exceeded our expectations. Visitor numbers to the website had flatlined in the last couple of years before redevelopment, but they have grown by over a quarter in the last three years. Of course, overall visitor numbers depend on a variety of factors, so a more reliable sign of success is depth of engagement with the site. Users are spending more time on the site and engaging with more content: page views are up by a whopping 41%.

One of the more surprising effects of the relaunch was a huge increase in the social sharing of web pages: Facebook and Twitter traffic to the website more than doubled on launch and has more or less stayed at that level ever since — something that has very little to do with our own activity on those channels.

This success has also been reflected in real world measures: online ticket sales have increased enormously, and surveys of visitors in our buildings show much more recognition of the website as part of their pre-visit experience.

What did we learn?

Understanding user needs requires research and hard data. Without that it is very easy to be steered by unconscious biases: if you work in a museum you will tend to see it as a series of operations of contested importance; someone from outside is more likely to see it as a building or an attraction with an occasional role to play in their lives.

The move to WordPress has also liberated how we use the site. The ease of use and ready availability of online advice and plug-ins, means that we can develop and experiment with the site with minimal IT or developer support. Even when we don’t have the time to make measured, planned developments we can still make rapid, testable changes.

Of course, the website is far from perfect, and this culture of thinking iteratively about the site continues. We are currently looking at a major refresh of the website in about 2020, and amongst the areas we are considering improving are news content, event information, and further streamlining the mobile experience.

What one piece of advice would I give to other organisations?

Question your assumptions, and be prepared to upset colleagues. Everyone who works in a museum feels that their area of work is important, and needs to be prominent in the site navigation. But if people are not looking for that information, a link on every page of the site will not change that.

It’s important that you are able to show colleagues how users use the site, and show them that making content optimised for search engines is often far more important than where that content sits in the site navigation.