A Data-Driven Case for Burlington's Best Kept Season

Before deciding on a solution, we needed to understand who our audience was, what they were trying to accomplish, and how they approached trip-planning decisions. Although this project differs from traditional training, we used the same human-centered process we use to understand learners and the situations in which they need support.

We started by creating a persona to represent our audience, or learners in a traditional training context. Our persona, whom we named Jodie, represents a realistic traveler planning a fall trip. We developed Jodie into a character with a busy life, competing demands, and a genuine desire to get away.

From this persona, we created a user story to capture what we felt would be Jodie’s primary goal when engaging with Burlington content:

As a prospective traveler, I want a simple way to find nearby fall destinations and events so I can plan a memorable weekend trip.

We then created a user journey that walked step by step through Jodie’s planning process, from her first search to the moment she would book a trip. This helped us identify opportunities to surface fall options in Burlington for Jodie to consider.

Walking through the user journey helped us land on key things a traveler might be looking for. We consolidated them into three key areas: fall highlights, such as fall foliage and seasonal hiking tours; attractions, including fall festivals and local museums; and food, including meals and seasonal treats.

We knew that other things would also play a key role in planning, including budget, length of stay, and the general interests of the traveling party. Was this a family weekend with the kids, a romantic getaway, or a fishing trip with friends? To motivate the user to stay engaged with trip planning, we needed to make sure they were seeing options that appealed to them and matched the kind of trip they were searching for. For that, we were going to need to create a highly personalized experience.

We also took into consideration that our persona, Jodie, was stressed and did not have a lot of time to spend on research and planning. We knew that if Jodie could leave the experience with an actionable plan in hand, she would be more likely to book a trip. We therefore decided to provide a personalized trip itinerary as the takeaway.

Our design was starting to take shape. We had refined our purpose, determined key design principles that would guide our decision-making, and created a repeatable instructional framework to organize the content and user flow.

We designed a repeatable “explore, choose, and generate” instructional framework based on the three main areas of interest we had identified in our user journey: seasonal highlights, attractions, and food. The “Explore” portion presented an interactive section that introduced area options. The user would then “Choose” a preference by responding to a question prompt. Their answers were saved and later used to “Generate” personalized results in the itinerary.

Key design principles included making the experience feel like a webpage rather than a course and using customized visual content instead of out-of-the-box interactions that favored a more traditional course design.

The key to tying the experience back to our business objective of promoting local businesses and attractions was creating a content library that could surface places matching the user’s interests.

We built a library that included hiking trails, cafés and restaurants, lodging options, seasonal highlights, and various places of interest. To connect each entry to the user’s search criteria, we added a tagging system. We tagged entries across several dimensions, including location, setting, and budget, so the system could filter, combine, and score relevant itinerary results.

Not every input carried the same weight. Some acted as firm gates: the system would not recommend an option that was incompatible with the traveler’s companions, budget, available time, or lodging needs. Other tags contributed to a softer scoring model, allowing especially relevant places to rise without narrowing the results so much that every similar traveler received the same itinerary.

We also organized the library into six geographic areas so the itinerary would function as a realistic plan, not simply a collection of individually relevant recommendations. We did not want the system to suggest breakfast in one part of town, an activity across the region, and then send the traveler back to the original area for lunch.
‍

To help shape the overall composition of the itinerary, we grouped our users into five travel archetypes and asked a personalization question that allowed the user to select the one that most appealed to them for that trip-planning session.

The recommendations for each archetype focused on different types of experiences and centralized areas. For example, a Scenic Explorer drawn to hiking trails and lake views received recommendations centered on scenic and outdoor destinations, some of which offered picnic spots. A Creative Explorer drawn to arts and local dining received recommendations centered more heavily around Burlington’s arts district.

Each archetype pulled a different mix of offerings. Additional personalization questions allowed the system to select anchor experiences that held the day together and fit within the user’s budget and length of stay. Lodging, meals, treats, and other stops could then be arranged around those anchors and adjusted based on the traveler’s other preferences.

Two travelers could answer the same four questions and walk away with two different weekends.

Because this was a capability demonstration, the platform was part of what we wanted to prove. We could have built the experience as a standalone website, but that would not show whether this kind of adaptive, highly customized experience could be created inside a learning tool and delivered through an organization’s existing LMS. We chose Articulate Rise so the concept would remain applicable to more traditional organizational learning environments.

Rise gave us a responsive foundation and the continuous scrolling structure that matched the webpage-like experience we envisioned. However, its standard interactions still carried a recognizable course look and could not support all the functionality we had planned. We designed Burlington to blend traditional Rise functional blocks with custom HTML, CSS, and JavaScript, preserving its responsive framework and LMS compatibility while adding the functionality and visual control we wanted for this experience.

Rise natively keeps a button selection within the block in which it was made, so the value is not available to later blocks. Using JavaScript and CSS within custom HTML blocks, we designed our personalization questions and connected them directly to our content engine. Within those blocks, we stored each response as a session-level variable, retained the user’s preferences throughout the experience, and used those preferences to generate the itinerary.

We also handled responsive spacing, layout changes, and image behavior within custom blocks. For several section headings, we used graphics to retain the display style established in the visual design without relying on a web font that might not render consistently in Rise. Placing those graphics inside custom code removed the unwanted caption divider and allowed us to use one composition on desktop and tablet and swap in a better-proportioned version on a phone. Because the heading text was part of the artwork, we added descriptive alt text in the code so screen-reader users would still receive the same section cues.
‍

We added illustrative traveler reviews throughout the experience to make the recommendations feel more realistic and help users picture themselves visiting the featured activities and businesses. Each custom review block layered an illustrated avatar over the review card and incorporated full-width decorative graphics on larger screens, giving the testimonials a more distinctive presence while allowing the layout to simplify for smaller devices.
‍

Maestro’s Mighty plugin created graphic transitions between selected sections, while responsive spacers built with JavaScript gave us precise control over the pacing of the page on different screen sizes.

Once the experience was assembled, we needed to test more than whether the screens worked. We needed to know whether users could move through the experience without becoming overwhelmed, whether the personalization logic produced a realistic trip, and whether the final itinerary was useful enough to carry beyond the experience.

For a live tourism implementation, we identified measures that could be tracked in stages.

• A 75% itinerary-completion target would show whether users remained engaged long enough to generate a plan.
• Outbound clicks would indicate whether they continued to lodging, restaurant, and attraction websites.

Over time, changes in fall lodging and dining receipts could help determine whether that engagement translated into tourism activity. Because Burlington was developed as a capability demonstration rather than launched as a live tourism campaign, those downstream business outcomes remain proposed measures rather than results we could claim.
‍

As a capability demonstration, we scoped this prototype to answer a specific question: could we build a functional adaptive experience inside Rise? Once the solution took shape, we developed the content library to support meaningful test combinations and confirm that the model was viable. A field deployment would expand that library and provide opportunities to validate and refine the tagging model using partner goals, live tourism information, and additional user data.

During usability testing, one of the clearest findings was preference-question fatigue. We originally included a question about treats and desserts, but testing showed that it asked users to make another decision about something that was not a major trip-planning priority. We removed it from the required flow and repositioned treats as bonus recommendations based on the traveler’s location. This allowed us to continue promoting local cider, maple, bakery, and dessert stops without making the user work harder to receive them.

We created test combinations across the saved preferences and reviewed the resulting itineraries for relevance, variety, and practicality. This included checking that firm requirements were consistently honored, preferred experiences rose appropriately, and the geographic logic produced days a traveler could reasonably follow.

Geographic testing was particularly important. If someone selected a mountain resort, for example, the engine needed to favor nearby activities or group farther destinations into a clearly defined day trip rather than repeatedly sending the traveler between the resort corridor and downtown Burlington.

Repeated testing also exposed areas where the content library needed greater depth. When the same recommendations began appearing after several reshuffles, we expanded the inventory and refined the tags to create more useful variation. We then added targeted shuffle controls so users could replace an individual activity without restarting the itinerary or losing the preferences they had already entered.

Finally, we tested what happened after the itinerary was generated. Users could add their own notes, make adjustments, and print the completed plan. These were not treated as extra features. They completed the experience by turning what the user had explored into something they could act on after leaving the page.

‍