Maiteego AI: from trip planner to travel companion

The problem

Planning a trip usually means juggling several tools at once: notes, maps, screenshots, booking emails and recommendation apps. That fragmentation raises cognitive load and makes it hard to get a clear picture of the trip.

Many existing apps focus either on inspiration or on rigid planning, forcing people into predefined structures that reflect neither their preferences nor how plans change over time.

The challenge: a solution for building personalised itineraries, with all the relevant information at hand, flexible and easy to update, both before and during the trip.

My role and the constraints

I worked as co-founder and sole UX/UI designer, owning the whole process: product definition, flows, information architecture, visual system and prototypes. I collaborated with the CTO and co-founder, which meant frequent iterations and decisions balancing user needs, business goals and technical feasibility, with limited time and a constantly shifting roadmap.

Research: competitors and beta users

Direct competitor benchmark

I analysed four direct competitors (Mindtrip, Layla, Wonderplan and Wanderlog). The market is made of specialised solutions: each one solves one phase of the trip, but none covers in-trip support with AI at its core. That gap is what defines Maiteego.

That led to the product principles: prioritise clarity over the core function, allow flexibility when building itineraries, and support the traveller before and during the trip.

Observation in the beta (April 2026): why new users weren't creating their first trip

With the app in beta, I observed new users on the first step of creating a trip, where you add stops, stays and transport. There was no quantitative data for that flow, so the research was qualitative, and what I saw was clear: people didn't know where to start.

I turned those observations into five questions and checked them against six references (Wanderlog, TripIt, Roadtrippers, TripAdvisor, Sygic Travel and Google My Maps). The conclusion: apps that work either remove the blank screen or make the first action so obvious it needs no instructions. From there I explored three directions (a step-by-step wizard, a single screen with inline actions and a hybrid) and recommended the hybrid: a guided question, «Where do you want to go?», that places the first stop and then gives users freedom to continue. It's the biggest change for new users with the smallest change to the flow's structure.

Information architecture and first version

Before drawing any screens I defined the main sections in Miro (itinerary creation, destination information, explore) and simple, flexible flows for creating, editing and adapting itineraries without rigid structures.

Key screens of the first version (2025)

Designed to balance information density and visual clarity in a mobile context: hierarchy, legibility, spacing and clear CTAs to reduce cognitive load while planning and while travelling.

The design system today

With the app in production, the system settled like this: neutrals on the Zinc scale, a single brand blue, three semantic colours (warning, avoid, success), eight text styles in Geist, a 4 pt grid, and hierarchy through borders and surfaces instead of shadows. Fifteen components cover 90% of the screens.

Iteration: creating an itinerary, from 4 screens to 2

Iteration was constant: several solutions were redesigned as goals evolved and feedback revealed gaps between the initial ideas and real needs. Working so closely with my co-founder pushed me to take feedback, step back from my first decisions and iterate towards clearer solutions.

The clearest example: the «create itinerary» flow went from four screens to two. I reduced the number of screens and the elements on each one so users wouldn't feel overwhelmed, without dropping any preference or data needed to personalise the trip.

Product evolution in beta (2025 → 2026): from planner to travel companion

With real users, the design evolved in three directions: putting AI at the centre of the interaction (a chat where everything mentioned is actionable), turning the destination into a guide that answers questions instead of a static card, and bringing live information (local time, weather, alerts) into the explore screens. The screens are real production captures.

1 · Home: from a stats dashboard to a question

Before: greeting, stats and «continue planning». After: the question to the AI is the hero.

Decision: the first home summarised the user's activity but didn't show what makes the app different. Now the first action is to ask: the field fills the hero, a rotating example shows what you can ask for without a tutorial, and planning and exploring become secondary actions.

‹ ›

20252026

2 · Chat: every place the AI mentions is a card you can add to the plan

Inline chips inside the answer and, at the end, the «Mentioned in this answer» cards with a «+» to add them to the itinerary.

Decision: the problem with travel chats is that the answer is plain text, so users have to copy, search and come back. Here every place is recognised inside the text as a verified chip linked to the map, and at the end they're grouped as cards with a «+». One tap and it's in the plan: the answer stops being something to read and becomes something to work with.

3 · Explore: from a city gallery to a live map

Before: photo collections of cities. After: a map with places by type and a bottom sheet with local time, weather and lists.

Decision: the gallery looked nice but was static and useless during the trip. The new Explore is a map with a draggable sheet: local time and weather, a practical tip and lists by category. Users choose where to look; the app tells them what's there right now.

‹ ›

20252026

4 · Destination guide: from a fact sheet to an editorial guide

Before: photo, a generic paragraph and six facts. After: a hero with character tags, tabs by intent and «Why Kyoto».

Decision: the guide is organised around the questions travellers ask, each with its own visual pattern: is it for me? (scores by profile), when should I go? (traffic-light calendar), what should I know? (alerts in warning colour) and what do I need? (fact sheet). Progressive disclosure, plus a field to ask the AI about that destination.

‹ ›

20252026

5 · Itinerary: from a list of activities to a plan that reacts

Before: today's destination and featured activities. After: flexible dates, the day's weather, accommodation, a numbered route and travel times between stops.

Decision: the itinerary is used phone in hand, so everything added answers a question of that moment: what's the weather like? how long will it take? where am I sleeping? On the place card, when opening hours are missing there's a shortcut: «Ask if it's open». When the trip ends, the app turns it into a memory («Time since your adventure»).

‹ ›

20252026

6 · My trips and profile: the traveller's memory and transparency about AI

Trip history, saved itineraries with a day bar per destination, and AI usage visible in the profile.

Decision: in saved itineraries, a proportional bar with one colour per city lets you read the structure of the trip without opening it. In the profile, AI usage is shown as two windows with their percentage and reset date: the limit is communicated in advance, not as an error once it runs out.

Results and learnings

Maiteego resulted in a solid design foundation: a clear structure, a consistent visual system and a user-centred approach aligned with the travel companion concept. The evolution in beta (chat, guides, live map) proved that foundation could scale: the system and architecture of the first version supported far more complex features without redoing the navigation.

Beyond the screens, this project consolidated my understanding of the full UX/Product flow, from discovery to iteration, and my ability to design with intent, justify decisions and work within real constraints. I keep iterating based on real usage.

What I'd do differently