The Challenge

How might we encourage players to return to the platform between tournaments while strengthening their connection to the league, their academy and their personal progression?

The platform already solved tournament logistics, but it didn't provide enough reasons for players to stay engaged throughout the season.

We wanted to create an experience that would:

• Encourage repeat visits beyond tournament registration.
• Reinforce player identity and personal progression.
• Celebrate participation, not just tournament victories.
• Increase long-term engagement across the season.
• Strengthen the connection between players, academies and the league.
• Create new opportunities for future business initiatives without disrupting the existing experience.

What We Already Knew

Years of organizing tournaments had given us a deep understanding of its community.

Rather than starting with assumptions, we relied on recurring patterns observed by tournament organizers, coaches and academy owners.

We consistently observed that players valued:

• Collecting medals and trophies.
• Commemorative tournament merchandise.
• Recognition within their academy.
• Showing achievements to friends and teammates.
• Representing their gym with pride.
• Building a visible competitive history over time.

Instead of inventing entirely new behaviours, we focused on reinforcing motivations that already existed offline.

Design Principles

Every decision was guided by a small set of behavioural principles rather than individual features.

Make progression visible

Players should always understand where they are in their competitive journey.

Celebrate participation

Recognition shouldn't belong only to tournament winners.

Strengthen identity

Player profiles should become something competitors feel proud to share.

Encourage return visits

The platform should provide value even when players weren't actively registering for tournaments.

Promote healthy competition

Competition should motivate players while remaining appropriate for younger athletes and family-oriented events.

The Solution

Instead of designing isolated gamification features, we created an engagement ecosystem where every feature reinforced another.

Player Dashboard

A personalized home for each competitor.

The dashboard helped players:

• Track achievements and milestones.
• View tournament history.
• Display collectibles.
• Discover upcoming events.
• Understand their overall progression.

Achievement System

Achievements rewarded meaningful participation beyond winning medals.

Examples included:

• Tournament participation.
• Consecutive attendance.
• Milestone accomplishments.
• Community involvement.
• Progress across the season.

The objective wasn't simply rewarding activity, but reinforcing behaviours that strengthened long-term engagement.

Public Player Profile

The profile evolved into a public representation of a player's journey.

It combined:

• Tournament history.
• Achievement badges.
• Rush Card collections.
• Academy affiliation.
• Personal milestones.

The profile became something players could proudly share with others.

Academy Head-to-Head

An early concept explored direct player comparisons.

During stakeholder discussions, concerns emerged around encouraging excessive competition among younger athletes.

The concept evolved into:

• Academy versus academy comparisons.
• Community pride instead of individual pressure.
• Friendly competition between gyms.
• A healthier competitive environment.

This became one of the project's most interesting product decisions because it balanced engagement with community values.

Flexible Membership Concept

We also explored a subscription model allowing players to train across participating academies.

The concept aimed to:

• Increase flexibility for players.
• Encourage cross-academy participation.
• Create additional value beyond tournaments.
• Explore future recurring revenue opportunities.

Although never implemented, it highlighted the complexity of balancing player needs with the business interests of independent academy owners.

My Role

I contributed across both UX and UI design throughout the project.

My responsibilities included:

• UX Strategy
• Product Concept Development
• Information Architecture
• User Flows
• Interaction Design
• High-Fidelity UI
• Design System Contributions
• Stakeholder Workshops
• Cross-functional Collaboration

Key Design Decisions

One of the biggest lessons from this project was realizing that effective gamification isn't created by adding points or badges.

It's created by reinforcing behaviours that already matter to people.

Every concept was designed to strengthen one or more existing motivations:

• Recognition.
• Progression.
• Identity.
• Belonging.
• Community.
• Healthy competition.

Rather than inventing new behaviours, we amplified the ones players already valued offline.

Constraints

Several constraints influenced the final concepts.

We needed to balance:

• Children, teenagers and adult competitors.
• Player motivation without excessive competition.
• Business opportunities without disrupting academy relationships.
• Community identity across hundreds of participating gyms.
• Scalability for future platform growth.

If Implemented, What Would We Measure?

Since these concepts remained at the design stage, no behavioural data was collected.

Success would likely be measured through:

• Repeat platform visits.
• Tournament registrations.
• Returning competitors.
• Achievement acquisition.
• Rush Card collection.
• Public profile completion.
• Membership adoption.
• Player retention throughout the season.

Reflection

This project fundamentally changed how I think about gamification.

I no longer see gamification as points, badges or rewards.

I see it as designing systems that reinforce meaningful behaviours.

My biggest takeaways were:

• Start with existing player motivations.
• Design for long-term engagement, not short-term interaction.
• Recognition can be as powerful as competition.
• Product decisions should balance player experience, business goals and community values.
• The strongest engagement systems feel like a natural extension of the community rather than artificial game mechanics.

‍

Project challenges

Airline apps are often used in time-sensitive situations.

Passengers may open the app shortly before travelling because they need to:

• check their flight details,
• review a reservation,
• complete check-in,
• confirm baggage or terminal information,
• or make a last-minute change.

However, many of the reviews I analysed described users being unable to access these tasks because their account was blocked, their password had expired, or the recovery process had failed.

This creates a particularly stressful situation: the user already has a valid booking, but the application prevents them from reaching the information they need. Or the essential information is buried inside screens.

The main challenge was therefore finding a way to reduce the dependency between account authentication and access to an existing trip.

Because this was an independent project, I did not have access to Iberia’s internal analytics, support data, business rules, security requirements, or technical architecture. The direction was therefore based on public reviews, direct product observation, behavioural hypotheses, and assumptions that would need further validation.

Research approach

I began by reviewing a large number of recent App Store reviews and grouping the most repeated complaints into four broad themes:

Login and authentication

Users described:

• expired passwords,
• failed password recovery,
• blocked accounts,
• missing social sign-in options,
• delayed validation codes,
• and inconsistent behaviour between web and mobile.

Payment and reservations

Users reported:

• failed payments,
• bookings not appearing,
• difficulty changing flights,
• problems retrieving reservations,
• and uncertainty around prices and booking conditions.

Personal information

Several reviews mentioned:

• incorrect passenger details,
• difficulty changing names or account information,
• and account data that could not be corrected without support.

Flight transparency

Users also expressed frustration around:

• missing flight information,
• unexpected itinerary changes,
• unclear baggage conditions,
• and difficulty confirming whether the information displayed was accurate.

The research did not prove the scale of each issue, but it revealed a repeated pattern: users were often unable to complete high-priority travel tasks because access to their trip was tied too closely to account authentication.

Behavioural patterns

From the reviews, I identified several likely behavioural patterns.

When users cannot access their account, they often:

• try repeatedly to recover it,
• switch from the app to the website,
• contact customer support,
• attempt to retrieve the reservation through alternative channels,
• and repeatedly verify flight information because they do not fully trust what they see.

I also observed that most sessions in an airline app are likely driven by a small set of high-intent tasks:

• booking a flight,
• checking an existing trip,
• modifying a reservation,
• or reviewing time-sensitive flight information.

This suggested that access to an existing booking should be treated as a primary user intent, rather than as a secondary feature hidden behind login.

Pain points

The main pain points identified were:

• losing access to a booking because the account is blocked,
• having to use another device or channel,
• missing a deal or paying more after an app failure,
• discovering an error in the reservation too late,
• feeling misled by unclear booking conditions,
• and learning about itinerary changes without sufficient warning.

The most critical pain point was the combination of urgency and dependency:

Users may already have a valid reservation, but still be unable to reach it when they need it most.

Opportunity areas

Based on the research, I identified several possible opportunities:

• allow users to view an existing trip without logging in,
• make guest access more visible,
• create an account recovery wizard,
• notify users before account action becomes urgent,
• improve communication around flight changes,
• clarify booking conditions,
• and allow limited modifications within a defined grace period.

I decided to focus on guest trip access because it appeared to offer the clearest balance between user value and implementation effort.

The Iberia app already contained elements of guest access, but they were not prominent enough in the main experience.

This meant the opportunity was not necessarily to create a completely new capability, but to make an existing one easier to discover and use.

Problem framing

The problem was framed as follows:

Users are getting their accounts blocked, or discovering that their password has expired, shortly before travelling. At the moment they need their flight information most, they may be forced to recover their account, move to the website, or contact support.

This leads to frustration because:

• the user may feel that calling support is the only option,
• the app appears unusable without login,
• and the path to retrieve a booking is not sufficiently visible.

User objectives

The user needs to:

• access flight information quickly,
• review an existing booking,
• make urgent changes,
• and complete travel-related tasks with confidence.

Business objectives

The business could benefit from:

• reducing support requests related to login and authentication,
• reducing negative reviews,
• increasing successful self-service,
• and improving trust in the mobile experience.

Potential metrics

If this concept were implemented, I would evaluate:

• guest booking retrieval completion rate,
• reduction in login-related support contacts,
• number of users switching from app to web,
• failed booking retrieval attempts,
• task completion rate,
• and the proportion of negative reviews mentioning authentication.

Prioritisation

I explored four directions:

1. proactive account notifications,
2. a more visible support or chatbot entry point,
3. a full account reactivation wizard,
4. and guest access to existing trips from the home screen.

The account reactivation wizard could have a high impact, but it would also require greater technical and operational effort.

Guest trip access appeared to provide meaningful value with lower effort because it could build on an existing reservation retrieval mechanism.

For that reason, I selected it as the primary concept.

Design direction

The final concept reorganises the app home around two primary user intents:

• searching for a new flight,
• and accessing an existing trip.

Instead of forcing every traveller to begin with authentication, the home screen includes a visible Mis viajes section.

Users can retrieve a reservation using:

• surname,
• and booking code or flight number.

Once the booking is found, they can view the most important trip information without creating or recovering an account.

This includes:

• route,
• departure and arrival times,
• airport and terminal,
• cabin,
• fare,
• baggage,
• meal information,
• and seat conditions.

From the reservation detail, the user can access contextual actions such as:

• adding the trip to a calendar,
• changing dates,
• sharing flight information,
• personalising the trip,
• requesting an invoice,
• or managing the reservation.

Balancing access and security

A guest experience should not remove necessary security controls.

The concept therefore separates access into two levels.

Low-risk access

After entering surname and booking reference, the user can view essential trip information.

Sensitive actions

Actions such as cancellation, date changes, refunds, or personal-data updates may require an additional verification step.

This could include:

• a one-time code,
• email verification,
• confirmation through the original booking channel,
• or another form of identity validation.

The purpose of the concept is not to eliminate authentication, but to avoid making full account access a prerequisite for every travel-related task.

The final experience

1. Home screen

The first screen gives equal visibility to two important tasks:

• finding a new flight,
• and retrieving an existing trip.

By placing Mis viajes directly on the home screen, the guest flow becomes discoverable at the point where users already begin.

2. Reservation details

After entering the booking information, users reach a simplified trip view containing the information most likely to be needed in an urgent travel context.

The hierarchy prioritises:

• route,
• date,
• time,
• and the main reservation action.

Secondary details are presented below in a clear, scannable structure.

3. Reservation actions

A contextual action panel provides access to the tasks associated with the booking.

This avoids overwhelming the main detail screen while still making management options easy to reach.

Design decisions

Several design decisions shaped the final concept.

Make trip access a primary intent

The main conceptual change was to stop treating login as the default gateway to the application.

Users do not open an airline app because they want to authenticate. They open it because they need to do something related to a trip.

Reduce channel switching

The flow aims to reduce the need to move between:

• app,
• web,
• email,
• and support.

Prioritise urgent information

The reservation detail focuses on the information users are most likely to need shortly before a flight.

Preserve existing mental models

The interface uses familiar airline patterns and keeps Iberia’s visual language, rather than introducing an entirely new interaction model.

Use progressive disclosure

The first level shows essential information. More complex reservation actions appear only when the user requests them.

Limitations

This project is based on public feedback and product observation.

I did not have access to:

• internal support volumes,
• authentication failure rates,
• conversion or abandonment data,
• reservation security rules,
• technical feasibility,
• operational constraints,
• or legal requirements.

The public reviews also represent a self-selecting sample and may overrepresent users who experienced serious problems.

For that reason, the findings should be treated as directional rather than conclusive.

What I would validate next

The next step would be to test the concept with travellers who have previously experienced:

• blocked accounts,
• failed password recovery,
• missing bookings,
• or urgent access needs before a flight.

The research would focus on whether users:

• notice the guest entry point,
• understand what information is required,
• can retrieve a booking successfully,
• understand which tasks are available without login,
• and feel that the flow is both easy and secure.

I would also test edge cases such as:

• incorrect booking information,
• multiple passengers,
• cancelled flights,
• past reservations,
• code-share flights,
• and actions that require additional verification.

Project roundup

The project began with a large set of negative reviews that appeared to describe many different problems.

After grouping the feedback, one underlying issue became clearer:

Access to a trip was too dependent on successful account authentication.

The final concept does not attempt to redesign Iberia’s full authentication system.

Instead, it reframes the app around the task the user is actually trying to complete.

By making guest trip access visible from the home screen, the experience could help travellers retrieve essential information more quickly, reduce unnecessary channel switching, and create a more resilient path for users who cannot access their account.

The concept would require further validation with users, engineering, security, customer support, and business stakeholders.

However, it demonstrates how a focused change in information architecture and entry-point hierarchy could reduce friction in one of the most time-sensitive moments of the travel experience.

‍

TL;DR

Designed a multi-user authentication flow that allowed parents to manage multiple athletes from a single account while making it easy to switch between individual competitors without logging in and out.

Problem

JJWL serves a large number of youth athletes.

Parents typically register and manage multiple competitors under a single email account, while minors often don't have direct access to that email.

Traditional authentication models assume a 1:1 relationship between a user and an account, but JJWL required one account to manage multiple users, each with different permissions and responsibilities.

Why this mattered

Without a clear account model, users struggled to:

• Access the correct athlete profile
• Register the intended competitor
• Switch between family members
• Understand who was currently active
• Manage permissions across multiple users

Working assumptions

• Parents are the primary account owners.
• Most competitors are minors.
• One account may manage multiple athletes.
• Different user roles require different permissions.
• Switching between users should be quick and effortless.

Success criteria

Users should be able to:

• ✅ Sign in once.
• ✅ Clearly identify the active athlete.
• ✅ Switch between family members in a few taps.
• ✅ Add new family members to an account.
• ✅ Recover account access easily.
• ✅ Avoid performing actions on the wrong profile.

Design decisions

• Separated authentication from the active user.
• Introduced the concept of an Active User.
• Made family accounts the default account structure.
• Designed frictionless profile switching.
• Clearly surfaced the current active profile throughout the experience.

Outcome

The resulting flow allowed a single authenticated account to manage multiple athletes while keeping the active user explicit throughout the experience. This reduced ambiguity, simplified family account management, and created a foundation that could scale to additional roles such as coaches and academy administrators.

‍

TL;DR

The Canadian Housing Observatory is a web platform that brings together housing data from multiple sources.

It was designed for policymakers, researchers, community leaders, and non-technical audiences who needed to understand housing conditions across different regions, time periods, and indicators.

My role focused on turning a complex dataset into a clear product experience through:

• Map and table views
• Indicator comparison
• Time and geographic filters
• Progressive disclosure
• Shareable analysis states
• A reusable visual system

The main design challenge was balancing analytical depth with an interface that remained approachable.

The Challenge

Canadian housing data was distributed across different sources, formats, geographic scales, and time periods.

Users needed to:

• Explore individual indicators
• Compare two variables
• Inspect exact values
• Change time periods and regional scales
• Export data
• Share a specific analysis

The challenge was to support all of this without turning the product into an overwhelming analytics tool.

How might we make complex housing data useful to both technical and non-technical audiences?

My Role

Role: UX/UI Designer / Product Designer
Responsibilities: Information architecture, interaction design, prototyping, visual design, and component systems

Success Criteria

The product needed to help users:

• Understand geographic patterns
• Compare related indicators
• Move between visual and precise data
• Adjust time and geographic context
• Share and export findings
• Access advanced controls without unnecessary complexity

Working Insights

These insights came from the project requirements, data structure, and interaction challenges.

One view could not support every task

The map made geographic patterns easier to recognize.

The table made exact values easier to inspect and export.

The product needed both.

Comparison was more valuable than isolated data

Viewing one indicator at a time only showed part of the story.

Users needed to understand how two conditions related to one another across different regions.

Advanced functionality increased cognitive load

Indicators included secondary variables, geographic levels, and historical data.

The interface needed to reveal this complexity gradually.

Sharing needed to preserve context

A screenshot could show a map, but not the analysis behind it.

Shared links needed to preserve the selected indicators, year, scale, and location.

Core Insight

Users needed to move between patterns, relationships, and exact values without losing the context of their analysis.

This became the foundation of the product structure.

Design Principles

Key Design Decisions

‍

A matrix for comparing indicators

We created a color-coded matrix that represented the relationship between two variables.

For example:

• Both indicators low
• Both indicators high
• First high, second low
• First low, second high

These combinations were applied directly to the map.

This removed the need for users to mentally combine two separate datasets.

‍

Map and table views

The map supported pattern recognition.

The table supported exact values, comparison, and export.

Users could move between both views while keeping the same analysis active.

Progressive disclosure

The main controls remained visible, while secondary variables and advanced settings were grouped inside expandable sections.

This kept the product approachable without removing depth.

‍

‍

Collapsible sidebar

Once users had configured their analysis, they could collapse the sidebar and dedicate more space to the map.

Persistent sharing

The product stored the analysis state through URL parameters.

Shared links opened the same indicators, year, geographic scale, and map configuration.

The Final Experience

The final solution allowed users to:

• Explore housing indicators on a map
• Compare two variables through a visual matrix
• Switch between map and table views
• Filter by year and geographic scale
• Access advanced indicator controls
• Export maps and structured data
• Share the exact state of an analysis

The interface was supported by a reusable system of selectors, panels, sliders, tables, legends, and map controls.

Constraints

The project was shaped by:

• An existing data structure
• Limited formal user research
• Complex geographic information
• Multiple user types
• Limited access to post-launch analytics

Because the comparison matrix relied heavily on color, a future improvement would be to reinforce its meaning with labels, patterns, or symbols.

What I’d Validate Next

The next research phase would focus on:

• Whether users correctly understand the comparison matrix
• Whether non-technical users can configure an analysis
• Whether changing between map and table feels continuous
• Whether advanced controls are easy to discover
• Whether the color system is sufficiently accessible
• Whether shared links preserve the expected context

Outcome

The design established a unified way to explore, compare, export, and share Canadian housing data.

It also created an interface structure and component system that could support additional indicators and future product development.

I did not have access to post-launch usage metrics, so I do not claim a measured improvement in user performance.

Key Lesson

The main challenge was deciding how users could move between geographic patterns, indicator relationships, and exact values without losing their place.

The project reinforced a simple principle:

Complex products do not always need fewer features. They need clearer relationships between those features.

‍

The Challenge

The platform contained a rich scientific model describing how ecosystem services influence one another across Canada.

Researchers already understood these relationships.

Everyone else didn't.

Users often explored one ecosystem service at a time without understanding how changes affected the rest of the system. The challenge was to transform a complex scientific framework into an experience that people could navigate naturally.

‍

My Role

Product Design

UX/UI

Information Architecture

Interaction Design

Concept Exploration

Design Systems

Workshops

‍

Success Criteria

This project would be successful if users could:

The Core Insight

People needed a mental model before a map.

Initially we assumed the map would become the primary way users explored ecosystem services.

Instead, we realized that without understanding the relationships between services first, the map became little more than a collection of colorful layers.

Users needed context before exploration.

This insight shaped almost every design decision afterwards.

‍

Design Principles

Exploring alternatives

Start with the map.

Too much information at once

Guide users through the concept first.

Chosen because it balanced learning with exploration.

Designing the information architecture

Every ecosystem service connected to several others.

Each relationship opened additional model inputs.

Each model input unlocked spatial layers.

Without structure, users could easily lose track of where they were.

We designed a layered exploration model that kept users oriented while still allowing free exploration.

‍

Progressive disclosure

Rather than showing every scientific relationship immediately, information was introduced in layers.

‍

Key Design Decisions

The Final Experience

Complexity → Clarity

What made this difficult?

• Scientific frameworks
• Many interconnected systems
• Several user groups
• Spatial datasets
• Relationships between services

What became clearer?

• Simple entry points
• Layered exploration
• Context before data
• Relationship-based navigation
• Progressive disclosure

Constraints

• Desktop only.
• No backend ownership.
• Scientific model fixed.
• Concept phase.
• Limited user research.
• Need to maintain scientific credibility.

What I'd Validate Next

I'd test:

‍

• Can non-specialists explain ecosystem relationships after using the platform?
• Do users understand why two services are connected?
• Can users find the correct spatial layer?
• Is the framework easier to understand than the equation?
• Does progressive disclosure reduce confusion?

Lessons

This project changed the way I think about complexity.

Good UX is about helping people build the right mental model before asking them to make decisions.

The biggest design challenge isn't simplifying the interface.

It's deciding what people need to understand first.

‍

My thinking

One question guided every decision during this project:

"What does someone need to understand before the next screen makes sense?"

That question influenced where the map appeared.

It influenced why we kept the relationship graph.

It influenced how we presented the scientific framework.

It influenced how users moved through the product.

In the end, I realized I wasn't designing a dashboard.

I was designing a way for people to think about a complex ecological system.