Designing Visitor Experiences Around People

01Day one: the project gets complicated

More people arrive. Roles settle. Suppliers are appointed. Governance becomes more formal. Decisions start coming quickly.

Everybody has their own part of the project to deliver, usually with their own budget, programme and pressures.

This is the point where the original idea can quietly disappear into the machinery of delivery.

You do not need another layer of process. You need a small number of things everybody can keep coming back to.

Clear enough to help people move in the same direction without slowing them down.

Governance tells people how decisions get made. You also need something that reminds everyone what those decisions are trying to achieve.

02Put a stake in the ground. A big one.

Take all the work that already exists and distil it.

The business case, audience work, access commitments, interpretation strategy, commercial assumptions, brand, community ambitions, cultural principles and anything promised to funders.

Turn it into something people will actually read.

I call this the Project Manifesto.

It is not another strategy. It is the current, readable statement of truth about the project.

The Project Manifesto should make clear:

• what you are creating
• who it is for
• what you are trying to achieve
• what must not get lost
• what is already committed
• what remains flexible
• what is still an assumption rather than something you know

And keep it current.

The funding documents explain how you got here. The Project Manifesto tells everyone where the project stands now.

Define the perfect visit

One of the most useful things a project team can do early is describe one really good visit.

Describe one really good visit:

• Where did it start?
• What made the person decide to come?
• How did they plan?
• What happened when they arrived?
• How long were they there?
• What did they understand?
• What did they buy?
• How did they feel when they left?
• What happened afterwards?

It sounds simple. It rarely is.

If you decide what a good visit looks like, that starts affecting booking, capacity, staffing, food and retail, interpretation, accessibility and how groups move through the site.

Decide the experience first, then make the systems and operations support it.

Decide what a good visit looks like first. Then make the systems, spaces and operations support it.

This exercise also gets people talking about the same experience. It exposes disagreements early and moves the discussion away from “what do we want to provide?” towards “what does the visitor actually need?”

You are not only defining the visit. You are teaching the project to think like a visitor.

It can also help to define the edges.

Not fast food

Prompt food you could comfortably eat in your lunch hour.

Not an encyclopaedia

Enough information to make someone curious and want to know more.

Not a tourist gift shop

A curated retail offer that follows the purpose of the place.

A useful “not” should change what somebody does next.

03Walk in the visitor’s shoes

The visit does not begin at the front door.

1. 01Someone hears about the place or sees a post.
2. 02They search and look at the website.
3. 03They check opening times, pricing and accessibility.
4. 04They decide whether to book.
5. 05They travel and arrive.
6. 06They work out what to do next.

After the main experience they may eat, shop, ask questions, leave a review, recommend it, return or continue the relationship online.

Map that journey.

Not because you need another diagram, but because it gives everybody a way of seeing the experience in sequence.

• A booking system can be efficient but set the wrong expectations.
• A sign can be perfectly clear but appear ten metres after the point where somebody needed it.
• Interpretation can be excellent and still arrive at the wrong moment.
• A shop can work beautifully in isolation and create a bottleneck when everybody reaches it together.

For every significant decision, ask:

What does this do to the visitor journey?

The visitor journey is not proof that the work has been done. It is the tool you use to do the work.

04Let’s agree who we’re designing for

There is no single visitor.

Someone may have planned their trip months in advance. Someone else saw the road sign ten minutes ago. One person wants to spend hours. Another wants the short version. Someone needs certainty about accessibility before they will even leave home.

Start with the audience work you already have. Use enquiries, reviews, ticket data, analytics, staff knowledge and previous research. Where an important assumption remains, find a proportionate way to check it.

Do not create a wall full of personas because the methodology says you should.

A persona is useful when it changes a decision.

• If e-bike users matter, are you providing charging?
• If people with limited mobility matter, where can they stop and rest?
• If families matter, what exactly does that mean?

“Families with children” is not precise enough. A parent with a three-year-old has very different needs from a school group or a family travelling with teenagers.

If children are an important audience, design for them properly. Think about learning age, interpretation, reach heights, toilets, baby changing, food, buggies, circulation, supervision, group size and staff interaction.

“Family friendly” is not an audience definition.

Agreeing who matters does something else as well: it gives the project permission to spend time and money serving those people properly.

It also protects those decisions when budgets tighten.

05Join it all up

Visitors do not experience your organisation chart.

They experience a sequence.

1. Website
2. Booking
3. Travel
4. Car park
5. Front door
6. Welcome
7. Signs
8. Interpretation
9. Toilets
10. Multimedia
11. Café
12. Shop
13. Wi-Fi
14. Confirmation emails
15. Follow-up communication

Internally those things may belong to ten different people.

To the visitor they are one experience.

That is where the journey becomes genuinely useful. Put the touchpoints against it and ask what each one is there to do.

Before travel

Someone may need confidence.

On arrival

Reassurance and orientation.

During the visit

Context, discovery and enough time and space to absorb it.

At the end

Perhaps food, something worth taking home, or simply a clear sense that the visit is complete.

The same thinking applies to communications. Rather than starting with “what should we put on social media?”, ask what somebody at that point in the journey needs from you.

It also exposes gaps.

Who owns the information people need before travelling?

Does the promise in the advertising match the reality on arrival?

Does the booking system support the visit you designed?

Does guest Wi-Fi feel like part of the organisation or a random technology product somebody installed?

Projects are delivered in workstreams. People experience the whole thing.

06Everyone’s right. Now what?

This is where projects can slow down badly.

Not because people lack expertise. Usually because there is a lot of it.

The accountant is protecting affordability. Academics are protecting accuracy. Archaeologists are protecting evidence. Local people are protecting lived culture and meaning. Operations are protecting something that can actually run. Accessibility specialists have requirements that cannot simply be designed away.

They can all be right.

And they can disagree.

Some truths are contested. Archaeologists do not necessarily agree with other archaeologists. History is rarely as tidy as an interpretation panel would like it to be. Local understanding can sit alongside academic knowledge rather than underneath it.

In a living culture, local knowledge is not simply another stakeholder opinion. It is part of the evidence base.

A team can be technically expert and still miss something obvious to the people who live there.

The project still needs to move.

So agree early how difficult decisions will be made.

Agree this before the difficult decisions arrive:

• Who has authority over factual accuracy?
• How will conflicting evidence be handled?
• How is local cultural knowledge represented?
• When does something need consultation?
• Who makes the final decision if consensus is impossible?
• How is the reasoning recorded so the same argument does not start again six months later?

You may not be able to remove disagreement.

You can stop disagreement becoming paralysis.

Agree how you will make difficult decisions before you have difficult decisions to make.

07Make the difficult decisions before they become expensive

Many project arguments happen too late.

Drawings are detailed. Content has been written. Software has been built. Suppliers have committed time. Changing anything now costs money.

Agree the basics earlier.

Take an interpretation panel.

Before somebody starts laying it out, decide what the panel is for, who is likely to read it, how much they should reasonably read, type size, viewing distance, contrast, content length, hierarchy, terminology and language treatment.

And if you say something such as Gaelic first, decide what that actually means.

Does the thinking begin in Gaelic and then move into English?

Or is English written first and translated?

Which language leads naming and terminology?

Which version has authority when a literal translation does not work?

What happens with place names, pronunciation or local forms?

Putting Gaelic above an English translation may technically be “Gaelic first” while the whole experience is still being conceived in English.

Agreeing “Gaelic first” is easy.

Agreeing what Gaelic first actually means is the useful bit.

Test the multimedia too

Digital exhibits often seem to escape this thinking.

A touchscreen, film, audio installation or interactive piece gets commissioned and built. The project sees polished designs or a supplier demonstration, and by the time anybody tries the real thing almost everything is committed.

Do not wait.

• Can people tell the screen is interactive?
• Do they know how to begin?
• Are the controls obvious?
• Can someone seated use it?
• Can a child reach it?
• Does the content justify the effort?
• What happens when four people gather around it?

And most importantly: does it support the visitor journey you agreed?

Supplier acceptance testing tells you whether the system functions.

That is not the same as finding out whether people can use it.

If people are expected to interact with it, watch people interact with it before you open.

1. Print panels full size.
2. Put temporary signs in the space.
3. Walk the route.
4. Try the booking system.
5. Test the menu.

Learn while change is still cheap.

08By opening day, you should know more than you do today

Every project starts with assumptions.

• How long people will stay.
• What they will understand.
• Whether the café model works.
• What families need.
• How locals will use the place.
• Whether the ticket price feels reasonable.

Some will be right. Some will not.

The point is to know more before opening.

You do not need to test everything. Concentrate on the assumptions that would be expensive, embarrassing or difficult to change later.

The business case, visitor journey and operating model should become more accurate as the project develops because the project knows more than it did when they were written.

Protect the commitment. Update the assumptions.

And prepare for what happens after opening.

The first year should be designed as a year of learning.

Teach staff to notice:

• where people hesitate
• what they repeatedly ask
• what gets ignored
• what sells
• where queues form
• where expectations do not match reality

Then give them a simple way of reporting it.

The dashboard should exist before opening. Not just visitor numbers and revenue, but the things that tell you whether the experience is actually working.

09The project needs a shared memory

Long projects forget things.

People leave. Suppliers change. Decisions disappear into meeting minutes. Six months later, nobody can remember why something was agreed and the discussion starts again.

By now the project may have audience research, access requirements, interpretation plans, brand guidance, Gaelic principles, visitor journeys, business assumptions, operating procedures and hundreds of individual decisions.

Nobody can remember all of it.

The useful starting point is not a new technology project. Most organisations already have the pieces: Teams, SharePoint, Google Drive, project folders, meeting notes, Microsoft 365 or similar systems.

Get the knowledge organised first.

1. Keep one current Project Manifesto.
2. Record important decisions and why they were made.
3. Make it obvious which documents are live.

Then AI becomes much less of a leap.

Increasingly it is already sitting inside the tools organisations use.

Instead of asking it to invent the project, use it to help the project remember:

• Does this booking system change still support the visitor journey?
• Does this panel design update still meet the accessibility requirements?
• What did we agree about Gaelic naming?
• Which commitments are affected if this space is removed?
• Have we already made a decision on this, and why?

Start with the project knowledge you already have. AI makes it easier to use.

AI can do much of the remembering. People can do the judging.

10It begins again when you open

Opening gives you something you have never had before: real behaviour at scale.

• People will take routes nobody expected.
• They will ignore things that seemed obvious.
• They will queue in strange places.
• They will ask the same questions repeatedly.
• They will use spaces differently from the drawings.

That is useful.

Watch it.

Some fixes will be tiny: different wording, a moved sign, a change to a booking slot, a better staff response.

Others will expose an assumption that has been sitting in the project for years.

That is fine too.

The point of everything before opening is not to build something that can never change.

It is to build something capable of learning.

Opening isn’t the finish line. It’s when the evidence gets interesting.

11Where FabUX fits

You should be able to use much of this guide without bringing in another consultant.

There are points, though, where an experienced independent view helps, particularly when a decision is expensive, contested or difficult to reverse.

FabUX brings knowledge of visitor behaviour, accessibility, interpretation, digital interaction and service experience, together with practical tools for discrete pieces of work.

That might mean reviewing a website or booking journey, testing multimedia before sign-off, checking interpretation and accessibility, looking at guest Wi-Fi or visitor communications, walking the arrival experience, or helping a team resolve a decision that has become stuck.

The aim is not to replace the expertise already in the project.

It is to add another informed view and, where it matters, test decisions against the visitor journeys and evidence rather than personal preference.

Sometimes that is a short review. Sometimes behavioural research or testing. Sometimes support at one critical point in the project.

The common thread is experience assurance: increasing confidence that all the individual pieces will work together as the experience you set out to create.