Context

Who was booking, and what they found

Tourist offers experiences across adventure, nature, gastronomy, culture and excursions. The catalogue had grown over time, but no one had looked at who was booking or what they needed to decide.

The travelers. Mostly 25 to 34 (54%), traveling with friends (49%), solo (46%) or as a couple (43%), and half of them several times a year.

The site. What they found didn't answer the first question anyone asks before booking: how much? The basics needed to decide were missing or broken:

No sense of one product. Each page looked like it belonged to a different site: a dark homepage with condensed all-caps titles, a light generic catalogue with other buttons, and a menu that never showed where you were. What was missing was a shared system.

Research

Price and trust, not inspiration, were stopping people

The site had grown without any research behind it, so before changing a single screen I wanted to know what made travelers hesitate. I used three methods, each answering a different question:

• Everyone is watching the budget. No one described their budget as premium: 60% look for good value and 40% prioritize low cost.
• Trust comes from clear, current information. 49% said information on travel platforms is unclear or out of date. Some respondents prefer to skip booking online and buy at the destination.
• The gap in the market. Viator and GetYourGuide set the standard for filters and reviews. The local players knew the region but felt dated. Tourist could offer both: local experiences with the clarity of a global platform.

Design decisions

Five decisions that shaped the site

The first plan was a visual fix. Research showed the problem went deeper: travelers didn't need a prettier site, they needed reasons to trust it. So the goal became showing what an activity is and what it costs in as few clicks as possible, with the details people need to decide right there.

Iteration

Getting there became part of the booking

Many experiences sit outside the city and transport isn't included, so getting there was a gap in the booking that also came up in the survey's open answers. I split the answer into two versions:

"I'll get there on my own" comes first and selected, so no one pays for transport by accident. Groups bigger than 4 see the private transfer disabled, with the reason and a way to contact Tourist.

Edge cases

When the booking doesn't go to plan

Beyond the path where everything works, I designed what happens when it doesn't, using the same components as the rest of the booking.

1. Date and timeFew or no spots? The calendar shows it before you pick.
2. TravelersGroup too big for the slot? Other times that day with room.
3. TransportMore than 4 people? The transfer is disabled, with a way to get help.
4. PaymentSold out while paying? No charge, pick a new time.
5. ConfirmedCode, meeting point, directions and calendar.

Names, codes and prices are sample content.

Mobile

The same booking, on a phone

On a small screen, the side-by-side booking panel became two short steps with a progress bar: first the date and time, then travelers and transport. The price and the next action stay pinned to the bottom, so the traveler always knows what it costs and what comes next. Every screen uses the same components as desktop.

Swipe to see all three screens →

Design system

One system, so every page feels like the same product

Before rebuilding the screens, I defined a shared system in Figma: a teal primary scale with semantic colors, Montserrat and Roboto on a fixed type scale, an 8 px spacing grid, and components in every state, from buttons and fields to cards, the calendar and the booking panel.

Accessibility was part of the system, not a final check. Text meets WCAG AA contrast (4.5:1) and controls meet 3:1. I darkened the main teal for small text, and no state relies on color alone.

Why: consistency is a trust signal. When every page behaves the same, the site feels reliable, and the two developers had one set of components to build from.

Working with developers

Designing for the two people who would build it

A static screen doesn't say what happens on hover, on error or on a small screen, so I annotated the Figma file with spacing, states and interactions, and we met to review each build against the design.

One gap came up during handoff: the homepage showed destination cards for places like Buenos Aires and Córdoba, but Tourist didn't have activities there yet. So I added a "Coming soon" state to the card component. The card stays on the homepage, dimmed and labeled, but it can't be clicked.

Search follows the same rule: typing a destination that isn't ready says it's coming soon and suggests the places that do have experiences.

Outcome

What happened next

The new design started being implemented. Before it was finished, the business was sold and the new owners took the site in a different direction, so I don't have launch metrics to share.

If it had launched, I'd have tracked booking completion from experience page to confirmation, use of search and filters, and how often transport is added to a booking.

Version 1 was about earning trust on the first visit. The planned Version 2 was about bringing travelers back: an automatic review request after each activity, while the experience is fresh, and a membership with rewards for booking and reviewing, since everyone in the survey was watching their budget.

Reflection

What I'd take into my next project

• Research changes the brief. I expected a visual redesign. The data showed the real problem was trust, which moved my priorities from visuals to information.
• Plan for what can go wrong from the start. A booking flow is defined as much by its errors as by its happy path: no spots left, a group that doesn't fit, a payment that fails. From now on I map those states alongside the main flow, so they shape the design instead of being patched in later.
• Make the most of the research there's time for. The client wanted to start the redesign quickly, so there was no room for interviews or usability testing. I worked from the survey, the benchmark and the site audit. A survey shows what people feel, but not always why, so in my next project I'd push for a few interviews and a quick usability test of the main flow, even with a tight timeline.

Problem

Booking a room meant sending an email and waiting

The project started with one real place: a family coworking space in the U.S., where parents work while their young children are cared for on site. The course required the project to be delivered in Spanish, which made it hard to keep designing for an English-speaking space. So I moved the research to Argentina and opened the concept to coworking spaces in general, where each space can add the services it offers.

I interviewed 5 members of family coworking spaces over video call. All of them had been part of this type of space for about two years and worked from it 3 to 5 days a week.

Their space ran on four tools: Google Photos for pictures, Google Chat for messages, a Google Sheet for room bookings, and Bloomz for the childcare room. Several members weren't sure how some of them worked, so they skipped them and asked in person instead.

Research

The problem wasn't a lack of tools. It was not being able to count on them.

I combined desk research on the coworking market in Argentina (data from December 2017 to June 2019), a benchmark of five apps (WeWork, Bloomz and Procare, later Regus and LiquidSpace), semi-structured interviews with 5 members over video call, and an open card sort with 10 participants.

• No way to book on your own. Members couldn't see availability. To add a day or book a room, they emailed or called and waited for an answer. They asked to see it online.
• Bookings overlapped. Private offices and meeting rooms were sometimes double-booked. Members always found a fix, but they described the space as disorganized.

Scope shift

From parents who cowork to any coworking member

Halfway through research, two findings pointed the same way:

Structure

Letting members sort the app

Before drawing screens, I ran an open card sort in Optimal Workshop with 10 participants. They grouped the app's features into piles and named each pile. I read the results in two ways: the dendrogram, which suggests groups automatically, and the similarity matrix, which shows how often each pair of cards ended up together.

Booking flow

One decision per screen

A review step to catch mistakes

The review screen lets members edit any detail before confirming. That answers the two problems from research: booking without waiting, and fixing a mistake before it turns into a double booking.

Small details, inclusive by default. "Te damos la bienvenida" welcomes anyone without assuming a gender, every tab icon keeps a text label so color isn't the only cue, and closed days are marked on the calendar so no one picks a day they can't book.

Testing and iteration

Everyone finished. Not everyone finished smoothly.

I ran moderated sessions over Zoom with 5 participants who thought aloud. The scenario: you work remotely and need a private office for an in-person client meeting. The tasks were creating an account and booking that office in the Adobe XD prototype.

The gap in steps was the clue. The participants with the longest routes went back a step or opened "Ver más" before booking. These are the patterns I changed:

UI & accessibility

A UI kit built around three words

Coworking members can work from home for free. What they pay for is a professional place and people to share it with. So the moodboard was built around three words: professional, community and simple. Orange came from that moodboard: warm and energetic, without feeling corporate.

Heuristic review

What my own review missed

After iterating, I reviewed the prototype against Nielsen's 10 heuristics. Progress bars, a review step and a way back from every action covered the booking flow. But a self-review is a checklist, not proof:

Final design

The final prototype

The finished app brings booking, services, messaging between members, and profile and membership settings together in four tabs, built on the UI kit above. Motion is used only as feedback, like a loader that fills while the SMS code is verified and grows into the success screen.

Reflection

What I'd take into my next project

CoJuntos was my first UX/UI project, and I did a bit of everything: interviews, information architecture, UI, prototyping and testing. Listening to people came naturally. What I had to learn was turning what I heard into design decisions.

• Let research change the brief. I set out to design for one family coworking space. The interviews showed that the real pain, booking and communication, was shared by every member. What users needed mattered more than what I had planned, and widening the scope made the product stronger, not weaker.
• Faster isn't always easier. Putting everything on one screen looks quicker, but testing showed it overwhelmed people. More steps with one task each, and a progress bar showing how much is left, made booking easier to finish.
• Test while iterating, not only at the end. Working alone on a fixed timeline, I tested once. Next time I'd plan smaller rounds of testing between iterations, so each change gets checked with real people.