Pillar 4 · Interfaces X. Design Week 2026

AI interfaces and user experience

How the visitor meets the destination when AI sits at the front door

Who builds the interface between the visitor and the destination and what is the DMO's role inside it?

The interface is the destination's new front door

In this report
02The argument
03Alma
04Selfe
05Strategic recommendations
06Re-enter the zones
The argument

From building the page to deciding what to build

Three channels

The visitor used to meet a destination through search results, brochures and travel agents. Today the visitor meets the destination through interfaces that AI helps build, that AI sits inside or that AI controls on the visitor's behalf. Three channels are taking shape.

The first is the destination's own assistant, a conversational interface that sits on the DMO's website, answers in the visitor's language and routes from inspiration through plan to book. The second is the agent layer, the AI assistants the visitor carries on their device, which research, compare and book on their behalf. The visitor never opens the DMO's website. The third is the curated content surface: newsletters, microsites, hubs and campaign pages built with AI as part of the production stack.

Three channels, one destination
Tap a channel
forum
01

The destination's own chat

Alma, on the Slovenian Tourist Board website

check_circleAnswers in the visitor's language, on the DMO website
check_circleRoutes from inspiration through plan to book
check_circleVerified information at the moment of need
smart_toy
02

The agent layer

The AI assistant the visitor carries on their device

check_circleResearches, compares and books for the visitor
check_circleThe visitor never opens the DMO website
check_circleReads the content and decides what to recommend
description
03

Designed in an AI tool by vibe coding and then published

The XDW newsletter and the participant hub

check_circleNewsletters, microsites, hubs and campaign pages
check_circleBuilt with AI in the production stack
check_circleDesigned in Claude, vibecoded, then published
DMO
Channel one · Own chat

On its own surface, the destination answers the visitor directly and keeps the conversation.

Where the work has shifted

The three channels share a working method. Building an interface starts with a conversation about the visitor, and the tools have caught up far enough that whatever a team can describe clearly, they can prototype quickly. The technology runs alongside the thinking now, which puts the visitor at the centre of every interface decision.

The conversation that matters is the one about what the visitor is trying to do and what specific question the interface needs to answer for them. Teams who hold this conversation properly produce interfaces that hold up well. The build follows the thinking, and the editorial judgement that decides what to build has become the work that matters most.

The space this opens for destinations is wider than it looks. Campaign microsites that would have needed months of planning get built and tested in a working session. Internal tools come together in an afternoon when previously they would never have made the priority list. The prototype itself becomes part of the conversation, surfacing as quickly as the ideas behind it.

The DMO's role and how far to push it

The role of the DMO is shifting towards digital architecture and the protection of brand trust. Teams now design platforms that perform beautifully for human visitors while remaining perfectly readable for the automated systems scanning the web. This dual focus requires a complete understanding of both user experience and technical data structure.

Deploying automated code directly onto a live public website creates valid operational anxieties. These concerns focus on compliance, brand consistency and long-term maintenance. A technical failure during a peak traffic period remains a significant risk if the underlying system was generated without human oversight.

A successful strategy separates initial experimentation from the final public launch. Automated coding tools work effectively for building internal prototypes and short-term campaign assets. The main consumer website requires a higher standard of engineering to handle large volumes of traffic reliably. Destinations secure this stability by using software tools for rapid concept design and then employing developer teams to stabilise the code before publication.

Accuracy and the chatbot question

Accuracy carries more weight on an automated messaging tool than on almost any other digital system. An incorrect answer is immediately visible to the visitor and directly compromises the reputation of the destination brand. Preventing these errors requires a strict management process based on verified data sources, expert reviews for complex questions and clear escalation paths to staff when the software is uncertain. Every automated platform carries this operational risk and requires an explicit plan to maintain quality standards.

Case study

Alma, Slovenian Tourist Board

A destination's own assistant built around verified information.

92%
Positive ratings
up from 82% at launch
7
Languages
English through to Slovene
3
Questions
what, when and where

Pilot launched on the Slovenian Tourist Board website

The Slovenian Tourist Board built Alma as a chatbot on its website. The system runs on a ChatGPT API, sits in seven languages and was framed from the start as a pilot project, which gave the team room to test the experience with the industry first, gather feedback at events and refine the design before scaling.

The conversational flow rests on three questions. Alma asks the visitor what activity they want to do, when they want to do it and where they want to be. The three answers give the system enough context to recommend specific routes, attractions and timings. The questions also reveal what visitors are actually looking for, which feeds back into the content strategy.

Where the integrations did the work

Two integrations did the most to raise quality. The first was Google Maps, which answered the location and timetable questions visitors asked most often. The second was Outdooractive, the platform used by the Slovenian Outdoor Association, which gave Alma access to curated hiking and cycling trails. Both integrations addressed a specific weakness the team had identified through red teaming. When Alma was asked about outdoor attractions, the answers were poor because the underlying content was poor. The integrations brought in the verified, structured data Alma needed.

From 82% to 92%

Positive answer ratings sat at 82% when Alma launched. Recent measurement puts them at around 92%. The improvement came from incremental work: better content indexing, the integrations above, voice input added for mobile users and an expansion of indexed content from English-only to all seven languages. Indexing Slovene content costs around 60% more than English because of the way the language is processed, and the upgrade made Slovenian content available to international visitors through the model's translation layer.

Compliance ran alongside development

The team registered Alma on the Slovenian register of public AI systems. They published legal notices to meet the EU AI Act and the European Accessibility Act. They added optional features that let visitors receive their itinerary by email, with all the data handling that implies. The compliance work happened during the pilot, alongside the rest of the build.

What comes next

Regional DMOs across Slovenia have asked to use Alma. The legal questions around extending an AI system to other public bodies are still being worked through. The early signals are that a shared destination assistant is achievable when the underlying content and compliance layers are owned at the national level.

Case study

Selfe

Preparing for the moment when the visitor's agent arrives.

Selfe’s work highlights how automated digital assistants now handle a major portion of holiday planning for travellers. These systems scan all available online material, evaluate destination credibility and deliver a highly refined list of recommendations. This shift eliminates the traditional website visit from the research phase. Travellers form their perceptions of a location based entirely on the specific summary generated by the software.

This shift changes the exact type of content destinations need to produce. A recent green paper on the future of travel discovery highlights this requirement clearly. Remaining visible to digital planning tools requires authentic storytelling that captures a location through the experiences of the people who live there. The voices carrying the most influence belong to the chefs, makers and innkeepers who shape the daily reality of a place. These narrative details translate directly into the specific, verifiable facts that automated systems look for when evaluating a destination.

From storytelling to recommendation

Specific stories become verified data, and verified data is what the agent trusts enough to recommend.

01 · The voices
restaurantThe chef
handymanThe maker
cottageThe innkeeper
hikingThe local guide
arrow_forward
02 · The content layer
verifiedStructured and verified
arrow_forward
03 · The recommendation
smart_toyThe agent
Try the harbour kitchen. The chef there is known for cooking the morning catch.

Selfe is building the data layer that helps that translation happen. A content surface that destinations populate with curated, verified information, queryable by the agents researching on behalf of a visitor. The principle underneath the product is the part worth holding on to. A destination is recommendation-ready when its stories are specific enough to be matched accurately and verified enough to be trusted.

Two readers, one surface

The same content page, read two ways.

smart_toyThe agent reads
check_circleStructured data check_circleVerified facts check_circleSchema markers check_circleAvailability at a moment
personThe human reads
check_circleInspirational language check_circleImagery check_circleReassurance

One surface serves both. The signals each one picks up are different.

The destination's role becomes editorial. The work is to curate the stories the agent layer can rank confidently and verify the data points underneath them. For many visitors, the DMO website now acts as a back-end service the visitor never sees directly.

Strategic recommendations

Key Questions and the Path Forward

This section pairs the core challenges raised by DMOs throughout the day with the strategic conclusions reached by the group. Six practical recommendations follow.

01

Should we build our own chatbot or invest in the content layer that agents will read?

Both, in different proportions based on the destination's visitor volume and content depth. National tourism organisations with high inquiry volume justify a chatbot first. Regional DMOs with lower volume invest first in the structured, verified content the agent layer will rely on. The chatbot adds value when the question volume justifies the operational cost of maintaining it. The content layer compounds regardless of question volume.

02

How do we protect against hallucinations in a chatbot?

expand_more

Establish a comprehensive verification system before launching an automated messaging platform. This framework relies entirely on verified informational assets, trusted technical integrations and human expertise. When the software encounters an unclear inquiry, the system transfers the conversation to a staff member or acknowledges the limitation directly in the response. Comprehensive stress-testing must occur prior to launch and continue on a quarterly schedule, focusing heavily on high-risk topics where misinformation compromises visitor safety or brand reputation. This continuous testing exposes vulnerabilities within the core database, allowing teams to fix source data before errors reach the public.

03

How do we prepare for the agent layer?

expand_more

Treat the content layer as the primary interface design problem. Structured data, schema markup, llms.txt files and a verified business directory matter more than the chatbot, because they are what the agents read. A heatmap, or an equivalent measurement, lets a destination see where its authority signals are strong and where the gaps sit. National parks, food and drink, cultural attractions, accessibility information and seasonal events are the most common gap areas. Closing them means publishing structured, verified content the agents can read and quote with confidence.

04

How do we comply with the EU AI Act and the Accessibility Act?

expand_more

Register any public-facing AI system on the relevant national register where one exists. Publish a clear legal notice describing what the system does, what data it processes and what the visitor's rights are. Build accessibility from the start: voice input, screen reader support, language options and contrast settings, tested with users who rely on these features. The Slovenian Tourist Board scoped all of this into the Alma pilot from the beginning, registering the system, publishing notices that meet both Acts and adding features such as itinerary delivery by email.

05

Do we need an AI interface at all?

expand_more

Certain situations require delaying the introduction of automated tools. An automated interface introduces unnecessary complexity when a website already suffers from low traffic, confusing navigation, poor content and a fractured booking process. These structural weaknesses require direct resolution before any advanced digital layer can deliver value. Every automated tool must serve a specific solution to a clear visitor problem. Defining that user need represents the essential first step that must precede any technical deployment.

Recommendations to take into the second half of the year
01

Map the visitor journey before choosing a digital tool

Identify exactly what the traveller needs at each stage, from initial inspiration through to the trip itself and their eventual return. Clearly define the specific question the digital platform must answer. Defining this precise user need avoids the mistake of launching an automated tool simply because competitors are doing so.

02

Invest in foundational information first

Prioritise accurate information assets, verified business directories, expert contributions and clear technical website coding. This preparation delivers long-term benefits across all digital marketing channels. This foundational step requires a smaller financial investment than launching an automated tool while providing a stronger return.

03

Introduce automated messaging only after establishing accurate data

Deploying an automated messaging tool using unverified information leads directly to factual errors that frustrate visitors and damage the destination brand. Teams must secure their source data before placing an automated communications system on top of it.

04

Address regulatory compliance from the start

Register public digital tools immediately, publish clear legal notices and integrate accessibility standards from the beginning of the project. Attempting to fix legal and regulatory requirements after launch creates unnecessary financial costs and exposes the organisation to operational risks.

05

Employ professional developers for all public systems

Automated coding software works well for creating internal prototypes and temporary digital assets. Public platforms require a professional development team to refine the code and ensure the system operates reliably under heavy visitor traffic.

06

Build and test quick prototypes regularly

Modern software makes the process of testing new ideas fast and inexpensive. Teams can experiment with multiple designs to gather rapid insights and launch a public tool only when a prototype proves its practical value.

lock

Log in to continue reading.

From the room

Re-enter the zones from XDW 2026

Each group examined the development of digital interfaces from a distinct perspective. The summaries below outline the discussions and the practical conclusions reached by each room, while the links provide direct access to the digital environments built during the event.

science

The Lab

What happened

Inside The Lab, practical experimentation demonstrated how modern software drastically accelerates the design and live deployment of digital assets. Teams generated functional campaign pages, interactive timelines and curated information hubs in minutes, proving that the technical barrier to launching new web experiences has disappeared.

The true strategic challenge involves the long-term sustainability of these rapidly built platforms. Organisations must establish clear operational rules for when a temporary prototype requires a transition to a properly engineered infrastructure. Recognising the exact boundary where automated software delivers speed and where it introduces technical risk allows destinations to innovate quickly while keeping their main websites reliable.

Takeaway

The technical barrier to building an interface has collapsed. The skill that decides quality has moved upstream into the editorial and strategic judgement that frames what gets built. Teams who bring a clear question to the build session produce sites that hold up. Teams who bring no question produce attractive prototypes that solve the wrong problem.

Explore The Labnorth_east
hub

The Strategy Room

What happened

The Strategy Room examined the core decision between licensing an existing digital platform or committing to a bespoke build. Licensing brings a functional system online within weeks, allowing a destination to connect its data and demonstrate immediate progress. Developing a custom system requires a long-term commitment to a multi-year partnership. Both strategies rely completely on a properly structured data foundation. A functional system requires deeply organised and connected information, as simply collecting articles in a digital folder lacks the technical structure required for automated tools to read it.

The discussion also addressed automated coding tools, framing their utility differently from pure experimentation. Automated software functions well for internal prototypes, small audiences and short-term experiments. The operational requirements increase significantly at the consumer interface level, where a main website must handle hundreds of thousands of visits. These public platforms require strict standards for security, performance under heavy traffic and reliable user paths. Destinations manage this transition effectively by pairing automated prototyping tools with a professional development team capable of refining the code for final publication.

Takeaway

The decision to license software or build a custom platform, alongside the choice between automated prototyping and traditional engineering, depends entirely on a destination's scale, ambition and technical capacity. Smaller teams can move faster and experiment more creatively. Larger organisations require strict technical checks and balances to protect their existing digital infrastructure. Success relies on a realistic assessment of local resources and a clear understanding of the risks associated with each path.

Explore The Strategy Roomnorth_east
forum

The Debating Room

What happened

The Debating Room ran on where to put investment: in the destination's own AI surfaces, or in the high-quality data layer that other surfaces will read. The room arrived at a bit of both, which sounds less satisfying than the reasoning underneath it. A destination's own AI surface has natural distribution limits. A busy DMO website might reach a few hundred thousand visitors, the conversion from those visits is a subset, and the visitors actually moved by the surface are smaller again. The case for the surface is the value it delivers in the moment to the visitor who does land there.

What has changed is the cost of producing the surface, which has fallen dramatically in the last few months and makes the return calculation look different from any point in the past. Underneath that sits the harder long-term work, producing high-quality data that holds up over time and aligns to strategy. This is what feeds the wider AI ecosystem through crawls and APIs into the major LLMs, Google AI mode and the surfaces other companies are building. The caution is around what happens to the data once it leaves the destination's own surface, because if it shows up in another company's product without alignment to strategy or brand, the version of truth that lands in front of the visitor stops being the destination's version.

Takeaway

The strongest investment is the underlying data layer. The destination's own surface earns its place because it now costs little to produce and delivers value to the visitors who reach it. The harder work is making sure the data feeding every other surface is high-quality, aligned to strategy and able to keep showing up correctly across the wider ecosystem.

Explore The Debating Roomnorth_east
support_agent

The Advisory Clinic

What happened

The Advisory Clinic worked on the framing question for the day. What is the role of an AI interface in a destination? Chatbots in their most basic form feel quite outdated, and tourism risks losing its way if AI-first interfaces start replacing the human interactions that make the experience worth taking. The balance between AI and human interaction is the first thing every destination has to settle for itself. Every AI interface needs a clear sense of purpose and an objective shaped by the destination's own situation. Inspiration from other platforms is useful and not transferable on its own, because the interface a destination builds has to solve a problem its visitors actually have.

The conversation moved to personalisation, and whether the homepage itself can adapt to the individual visitor. Some destinations already do a version of this, with separate landing pages for each campaign and segmentation feeding the experience. A separate thread emerged on the AI interface as a data-gathering surface. A well-designed interface, run as part of the visitor experience, produces qualitative data that is more visitor-friendly than a traditional survey and connects directly to the destination management work behind the scenes. That brings the EU AI Act and the handling of personal data into the conversation, because interfaces that gather information have to be designed for the responsibilities that go with gathering it.

Takeaway

The question underneath every interface decision is whether the destination needs an AI interface at all. When the answer is yes, the interface has to be built with purpose, designed to solve a specific visitor problem and held to the same accuracy, accessibility and legal standards every other public-facing destination product is held to. If the foundation is not yet in place, the interface is the wrong project. Fix the foundation first.

Explore The Advisory Clinicnorth_east
arrow_backBack to overview Continue to Follow-uparrow_forward
lock

Log in to continue reading.

chevron_right
01 · Overview
keyboard_arrow_leftArrow keys · swipe · tap a dotkeyboard_arrow_right
01 / 06