The problem
The system couldn't handle multi-destination tours or custom itineraries, so operators created duplicate listings to work around it. Search returned zero results or irrelevant ones, and the backend capped the catalogue below 700 tours.
Case study · Tours Management System
Three audiences, one system.
A bespoke tours platform for VisitScotland serving tour operators, tourists at home and abroad, and VisitScotland's own administrators. Three groups with incompatible needs and one backend between them.
At a glance
If you read nothing else · 40 seconds
What I did
Six personas across the three audiences, journey mapping, prototypes and workshops, then user acceptance testing with eight operators across ten questions.
What changed
Three front-end deliverables in visitscotland.com with real search filtering, itinerary mapping and a booking flow that fits how operators actually sell.
How the work ran
Select a step
01 · Separate
An operator listing a fourteen-day multi-city tour, a visitor from abroad planning six months out, and an administrator moderating the catalogue are not variations on one user. Naming them separately is what allowed the system to stop averaging them.
What was handed over
1,600+Tours listed in year one, up from under 700
600+Active tour operators engaged
6Personas across three audiences
8Operators in acceptance testing