Marc Gispert Saget
Digital Product Designer
PORTFOLIO

Room selector

Several usability problems was found on the old room selector component for the new price table matrix - as you can see described below on problems found. With the new design the user experience is noticeably increased making the customer able to compare between rooms, and their descriptions, prices (updated according the occupancy) and occupancy on the same list.

Note: A big difference if Sunweb is compared with other companies is that while competitors use to build the travel packages dynamically step by step, Sunweb comes from a non digital business model based on selling closed travel packages per catalog, were the customer/seller was able to compare between all the possible combinations (departure, duration, type of room, occupation...), during the digitalization this model was been migrated to a site were the user can easily find the perfect package, with the benefits of the web 2.0. This explains the complexity of this component that has to provide to the user the chance to compare between the details of all the closed packages.
Responsive image

  • Brand

    Sunweb

  • Timeline

    4 sprints of 2 weeks (research, wireframing, prototype)

  • Research

    Checking user behaviours and party compositions patterns

  • Prototyping

    Wireframes and digital prototypes

  • Testing

    Usability tests (not final users)

  • Strategy

    UX strategy

  • Visuals/UI

    Based on the room selector based on room types

  • Result

    As an assumption, user experience noticeably increased

  • URL

    room selector prototype

Challenge: have a single list of rooms where the user can compare rooms between description, allocation and price

How the actions taken helps the user choosing the perfect room?

Taking into consideration that on the Sunweb page is usually not required to fill the room distribution from the begining, with the new approach the users are able to easily compare and play between any room detail, such as price difference depending on how them occupe the rooms

Responsive image

Unstyled prototype to check functionalities
Check the interactive mockup

Main benefits of the new approach

  1. The rooms list will be shown only one time - No matter the number of rooms needed or how the occupancy between them is configured

  2. The user will be able to check the different prices according the allocation and the number of participants on each room

  3. All the prices will upgade in case the user change the number of participants

  4. The rooms that doesn’t fit with the allocation will automaticaly dissapear

  5. All the data will be preloaded so performance problems are not expected

  6. The room description can be checked by the user in any moment/stage

  7. The user will go step by step selecting rooms

  8. The overview of the selected rooms will be clearly understandable for the user

Faced issues

From the beginning it was thought to resolve the room selector such as the flight selector, with a list of rooms with radio buttons, but several functional problems was found.

Responsive image

  • If we use radiobuttons the items should be allways visible, so if we add a number stepper into it, whe should kep the list opened all the time and add the selected rooms close enough between them, to facilitate the user changing the allocation, all of this is confusing and also very difficult to implement.
  • Have to face a very long list of rooms on several accommodations.
  • Having a number picker in a radio button was very unusual.
  • Making the user click on CTA to add a new room after he already selected a radio button is weird, firstly because it is an action that you already know that user should do but also because the user already made the selection - a kind of redundant action-. But on the other hand, you can’t anticipate that action because you don’t know the participants' allocation.
  • Have more than 1 list with the same options one below the other is weird (and ugly)
  • In pre-packaging we don’t know the room allocation, but we know certain rules such as if they are kids, if them wants to go to the same room or different ones.

Responsive image

  • It was also thought to add and remove rooms list when the user changed the participants, but it was a not very friendly way to show the rooms list with a lot of rooms appearing and disappearing, also with the same problem of a list below the list with no chance of comparing rooms and allocations. But also a problem of performance. Recalculate constantly the prices could end in a slow site with things appearing and disappearing.

Responsive image

  • It was also thought to show the rooms list in an horizontal way. That way solved some things, and was more aesthetic and modern than the vertical list, but the same problem of adding/removing rooms and allocation was still there. A part from that at front end level the cost of the implementation, taking into consideration the front-end gap on the team, was so big and the expectation of time for the implementation was 4 sprints. Not only that, during the discussionit was challenged the fact that a lot of times the packages sold for summer are for 2 persons, so it means a big cost of implementation for something not tested and maybe not useful/necessary.

Marc Gispert Saget
Digital Product Designer

Web design and developement by: me :)