HandiSport Mallorca

From an informational website to an experience designed to find and manage adapted activities

HandiSport Mallorca connects people with specific accessibility needs to adapted sports and tourism activities. The project involved rethinking a very outdated website and turning it into a responsive experience that would guide the user from discovering an activity through to requesting and managing their booking.

Product screens are shown in their original Spanish.

Before and after of the Activities section. On the left, the old page recovered from the Wayback Machine: a gray header with «Actividades» (Activities) and a long column of text with no images or filters. On the right, the new one: a header with a photo, activity filters by accessibility need, activity cards with a Book button, the three steps Auto-filter, Booking, and Request, and Other activities.

Role: Product Designer UX/UI
Type: Freelance project
Product: Responsive web app
Platforms: Desktop + Mobile

01 The starting point

A website with information, but no clear journey

When I joined the project, the HandiSport website worked mainly as an informational repository. The activities section was especially long: each offering appeared one after another, with large blocks of text, little visual hierarchy, and no tools to help find an activity based on each person’s needs.

The full old Activities page, very long: a gray header, a list of activities (Sailing, Blokart, Water skiing, Kayaking, Golf, Hiking, Diving) with blocks of text and no images, and at the end, the phrase «Puedes registrarte a través de el siguiente formulario» (You can register through the following form). Three callouts: Flat content that's hard to scan; No filters by activity or need; The CTA to book is at the end and isn't clearly a button.

Booking wasn’t part of an obvious flow either. The CTA appeared at the bottom of the page and it wasn’t clear that it was a booking action; from there, the journey ended up routing to a generic contact form. Other areas of the site followed a similar structure, with a lot of empty space, information that was hard to scan, and little consistency between sections.

Two pages from the old website: the old Home, with a header photo, welcome text, a video that wasn't archived, and a text list of activities; and the old Contact page, with a basic form, lots of empty space, and large Facebook and Twitter icons.

The challenge wasn’t just updating the look. An informational website had to become an understandable journey, from “I want to find an activity” to “I want to request my spot”.

02 Building a clearer foundation

Carrying HandiSport's identity into a coherent interface

We didn’t need to create a new identity. HandiSport already had a recognizable brand built around orange; the work consisted of carrying that identity into a more consistent, easier-to-maintain interface.

I worked from a Material Design base and a Flutter theme to define a tonal palette, color roles, and a shared typographic hierarchy. Montserrat was used mainly for headlines and higher-hierarchy elements, while Roboto was applied to content, labels, and functional text.

More than creating a new system, we needed a foundation solid enough for the whole experience to speak the same language.

Visual foundations: Color Guidance, with the tonal palettes (Primary, Secondary, Tertiary, Error, Neutral, and Neutral Variant) and the color roles for light and dark themes; and Typography, with Montserrat as the primary font for headlines and Roboto as the secondary font, and the Display, Headline, Title, Label, and Body style scale.

I didn’t build a full Design System. The goal was to establish enough shared rules so that forms, filters, cards, states, galleries, and management tools would feel like part of the same product.

The Welcome section applied on desktop and mobile: header «Disfruta de tus capacidades» (Enjoy your abilities), welcome text, «¿Por qué elegirnos?» (Why choose us?) with a video, the Activities carousel on an orange background, Articles, and Reviews.

I also worked on standardizing text and copy to reduce inconsistencies and make working alongside development easier.

03 Finding activities based on each need

Turning accessibility into part of discovery

One of my main UX contributions was proposing that accessibility needs shouldn’t appear only as information within an activity’s page, but could also be used to find compatible activities.

Together with Samuel, we defined the categories the platform would include:

Hearing access · Cognitive support · Visual access · Mobility access · Sensory access.

From the Profile, the user can add the needs that apply to them or indicate that they have no disability. Based on that information, I designed the auto-filter option, meant to reduce the effort of reselecting the same filters every time the catalog is checked.

Auto-filtering came with an accessible explanation right inside the interface. The goal was for the user to understand that the platform would use the needs saved in their Profile to show them activities adapted to those needs, and to be able to go straight to configuring them if they hadn’t done so yet.

In the Activities section, I also added a small journey guide to reduce doubts:

Auto-filter , Booking , Request.

The Activities page on desktop and mobile: «Filtros de Actividades» (Activity filters) with chips by need (See all, Hearing Access, Cognitive Support, Visual Access, Mobility Access, Sensory Access) and the «Auto filtrado desactivado» (Auto-filtering off) toggle; activity cards with Book and Read more; and the «Considera estos pasos» (Consider these steps) block: Auto-filter, Booking, and Request.

The same logic continues inside each activity. The chips show again which needs it’s adapted to before the user reaches the “Reservar mi plaza” (Book my place) CTA. That way, the activity’s compatibility stays visible throughout the journey and doesn’t depend on remembering the filter applied earlier.

Detail of the Sailing activity on desktop and mobile, with three callouts: Activity detail; Accessibility chips (Hearing Access, Cognitive Support, Visual Access, Mobility Access) under the title «Iníciate en vela adaptada» (Get started in adapted sailing); and the «Reservar mi plaza» (Book my place) CTA. Below, a photo gallery, a note, and other activities.

Accessibility stopped being just a feature of the activity page and became part of how content is discovered.

04 From booking to management

Designing the journey after finding the activity

Requesting a spot didn’t always mean booking for a single person. The form also had to adapt to groups and allow each participant’s needs to be registered independently.

As the number of attendees increases, per-person blocks appear. Each one allows indicating who’s participating and what accessibility needs they have. Accordions help keep the form manageable even when the booking includes several people.

Needs don't belong only to the booking: they belong to each person taking part in it.

From the individual booking form to the group one. Individual booking: the Sailing form with personal details, date, total people (1), and language, on desktop and mobile. Group booking: with 5 people, accordions appear from Person 1 to Person 5; Person 1 «soy yo» (that's me) with their disabilities added, Person 2 with their own disability selector, and the rest collapsed. Callout: Needs per participant.

Once the request is submitted, the user can track its progress from My bookings. I designed a distinct visual hierarchy for states like Pending, Confirmed, and Expired, plus filters to access other states like Rejected or Cancelled.

The same request has a complementary view for the HandiSport team. From internal management, a pending request shows the information needed to review it and allows accepting or rejecting it.

A request seen from both sides. User · My bookings: booking cards with Pending, Confirmed, and Expired status, and filters by status. HandiSport · Management: «Solicitudes» (Requests) with the same pending booking expanded, the requester's details, and the Reject request and Accept request buttons. At the bottom: Check the status → Manage the request.

05 Giving the team autonomy to maintain content

Designing for those who manage the platform too

The experience didn’t end on the public side. HandiSport needed tools to maintain activities, requests, and content from within the platform itself.

When creating an activity, the administrator can define a title, subtitle, description, content, compatible accessibility needs, notes, and gallery. Associating those needs at the moment the activity is created is what later allows them to appear as chips, filters, and auto-filtering criteria.

Activity management: the «Nueva actividad» (New activity) form on desktop, with title, subtitle, short description, content, the disability selector with chips for the five needs, note, and gallery, and the «Publicar actividad» (Publish activity) button; and the same screen on mobile. Callouts: Activity management and Accessibility needs.

I also designed the article creation flow so the team could maintain editorial content from the platform. The form allows preparing a title, subtitle, short description, content, and gallery, as well as selecting a cover image and describing the pictures.

Create article → Published result. On the left, the «Artículo nuevo» (New article) form with title, subtitle, short description, content, and gallery with a description for each photo and the option to choose a cover image. On the right, the published article on desktop and mobile, with title, images, «Más fotos del artículo» (More photos from the article), and related articles.

So publishing wouldn’t depend on always having the same amount of visual material, I designed four layout variants based on the number of available photographs:

3 photos · 4 photos · 5 photos · +5 photos.

Each variant reorganizes the content and keeps its mobile adaptation, so the team can publish different pieces without breaking the site’s overall consistency.

The four layout variants for an article, each on desktop and mobile: Layout 3 photos, Layout 4 photos, Layout 5 photos, and Layout +5 photos, which reorganize images and text based on the number of photographs; the +5 one adds a «Más fotos del artículo» (More photos from the article) carousel.

The product had to be clear for the person booking, but also easy to maintain for whoever publishes and manages the content.

06 Outcome + scope

An experience connecting users and internal management

The final design expanded the old website’s scope to cover much of the full journey: discovering activities, checking their accessibility needs, requesting spots, checking statuses, managing bookings, and maintaining activities and articles from within the platform itself.

The work was approached responsively for desktop and mobile and was developed in close collaboration with the technical team. Samuel centralized communication with HandiSport, and I worked especially closely with Daniela, on the frontend, sharing designs, visual assets, photographs, copy, and the criteria needed to turn the screens into product.

My involvement ended with the handoff of the designs. I didn’t conduct interviews or tests with real users, and I don’t have any later metrics that would let me attribute quantitative results to the redesign.

Closing composition. User experience: the Activities page on desktop and mobile. Internal management: the user's My bookings on desktop and the team's request management on mobile, with the Accept and Reject buttons.

The main shift was moving from displaying information to building a journey: finding a suitable activity, requesting it, and being able to track its management within the same product.

Ready to join your product team.