The Process
To solve the problem we implemented bi-weekly sprints, with LeanUX principles and iterative design thinking. This meant working on smaller chunks and ensuring that I had the opportunity to explore multiple paths, validate them, and then push them to implementation.
With clients eager to see the results as soon as possible, it became critical to manage expectations, prioritize solutions, and exclude some nice-to-have functionality.
Interviews:
I conducted interviews with TIC employees to understand current workflows, tourist needs, and staff pain points. I learned that TICs already had most of the necessary data (location, images, descriptions, opening hours, etc.), but were limited by the need to present this via printed materials with short lifespans and limited reach.In parallel, I researched tourist behavior using insights from the Slovenian Tourist Board, discovering that most tourists plan trips online, rarely visit TICs, and are influenced primarily by photos, reviews, and personal interests.
User personas:
With this knowledge, I identified three core user personas:
1. TIC editors with limited digital skills who needed a simple, guided content-entry flow (target clients),
2. family-oriented independent tourists with a hands-on approach (usual guests at a TIC; target end users),
3. curious, mobile-first tourists looking for authentic and relevant experiences (ideal target users for the PWA application).
Designing a prototype:
Knowing the content requirements, I first designed a rough map of the platform in Whimsical. This allowed me to keep in mind all of the various components of the platform, and how they connect, while the project was growing.
Various parts of the map grew into a low-fidelity prototype that allowed me to start planning out key features in detail. This approach granted the possibility of making multiple potential solutions and validating them, with the team.
Solution #1:
The first solution was to let the customer browse the map, pick a location, and be presented with one of two choices: create a POI (point of interest) or a graphic element (visual interest for the map). Users would then be guided through a series of questions in the form of input fields, drop-down menus, sliders, and checkmark buttons, to fill in the information. The form would warn the user of missed or incorrectly filled information. I decided to simplify the form by making some fields collapsed, and only showing them when the user needed the additional information (for example event details, or categories).
With internal testing of Whimsical wireframes completed, I moved to a Figma prototype, designed from simple working blocks, prepared by our visual designer.
The goal of the Figma prototype was an easier (and aesthetically more pleasing) presentation to the clients.
Client testing revealed overlooked issues, such as a lack of user roles, simultaneous editing, data publishing, and data overlap, but the overall reaction to the process was positive.
Testing the web based prototype:
Based on client testing I added missing features to the prototype and pushed it for development. This meant that the prototype was polished in Figma and a working web-based MVP was developed for further testing with customers (TIC staff).
At this point I observed users successfully adding basic point attractions, adding simple data, such as location, opening hours, description texts, and photos, as well as platform-specific data (such as categories). All of the data was also securely stored on our cloud and could be retrieved for further use.
However, the system lacked support for multi-point attractions like trails or paths, and the users found the form to be too long, and would occasionally skip some input fields, to shorten the process.
Users also requested a way to import their existing content, and not be required to duplicate work.
Solution #2:
Based on the issue of the form being too long and users skipping some steps, the Product Manager decided to split the form into tabs based on subgroups of information (general info, categories, presentation, events).I redesigned the editor to support multi-point attractions using either manual waypoint entry or .GPX file uploads—developed in collaboration with our backend engineer due to some edge cases that needed to be accounted for (like designing a path from already existing POIs). We also added a content import feature that pulled data from existing TIC websites. I was adamant that we needed a solution that would flag missing fields (like categories and subcategories) for easy completion after import.
I lead a push to figure out how to show relevant attractions to each user rather than overwhelming them with all available data. This meant reworking our preexisting category system.
We started with an open-ended category system based on TIC staff input, but it quickly became unmanageable. In response, we created a structured model with 5 categories and 19 subcategories for more effective filtering (e.g., "Nature" > "Hiking").
To further personalize results, I added free-form tags (e.g., “Halloween”) and platform-specific tags (e.g., pet-friendly, disability-friendly, indoor/outdoor), helping surface the most relevant content for each visitor.
