MTBS

As part of their curriculum every year, primary and secondary school teachers would book museum tours organised by National Heritage Board (NHB) for students to undergo learning journey programmes about Singapore.

The Problem

In order to book a tour, teachers would have to download, fill up and email forms to museum administrators to know if the selected dates are available. This results in multiple back and forth amendments and email exchanges.

The Goal

Hence, the objective was to build a Museum Tour Booking System (MTBS) where teachers and staffs can book museum tours instantly.

My Role

For this project, I was roped in to assist and guide another designer on user experience and user interface design. I also helped to conduct usability testing with external stakeholders at the latter stages of the project.

The Process

As qualitative research was done beforehand by another consultancy, we assessed these findings to understand who are involved and what takes place during the process.

Discovery

  • Stakeholders

  • Booking Process

  • Tour Types


Stakeholders
The booking process involves internal and external stakeholders from museums and schools respectively. Apart from MOE and private schools, museums also track bookings by corporate groups and travel agencies for inventory purpose.


Booking Process
Currently, museums would provide tour information to teachers through websites, brochures, EDMs and educators’ meetings. Teachers would then call the museum coordinators to enquire about availability of dates and receive booking forms from them, which they would have to fill and submit in order to confirm a booking.

Blocked dates would also occur for VIP visits or any other impediments, requiring for cancellation of booked tours.


Tour Types
Apart from tours with guided and self-guided options, there are workshops conducted by vendors or facilitators. There are also schools who plan their own programmes that align with their teaching objectives. These are the waiting periods for each tour type:

  • Guided Tour: 4 weeks to confirm a booking as they would need to schedule allocation of guides

  • Workshop: 1 week to confirm availability of vendors

  • Self-guided tours and workshops conducted by in-house facilitators: as soon as booking is made

Challenges

With the gathered information, we identified the existing pain points faced by teachers while making a booking.

  • Have to call or email museum to enquire availability of dates with waiting time of 3 working days for response

  • Unaware of blocked dates, will only be informed by museum coordinator if they attempt to book that date

  • Finds saving, filling, checking and sending form a hassle, especially if they have to book multiple tours across different dates

  • Post-booking: Unable to enquire about booking as the museum coordinator who has sole access to her booking record is uncontactable


While internal and external stakeholders are used to liaising directly with each other, they see potential in having an online booking system despite concerns of it being inflexible and less effective due to the perceived lack of human intervention when needed.

Hypothesis

As the online booking system is inevitable, we formed a hypothesis that teachers might be skeptical while making a booking via the system for the first time due to their existing communication method despite the trade-offs such as filling of booking forms for multiple tours and downloading of resources from websites.

Synthesis

We assessed the challenges to uncover insights that can potentially streamline the booking process.

With the hypothesis in mind, we developed the persona and journey map of a local school teacher and the stages where we perceive her interaction with the product.

We also developed a user journey map for the internal stakeholders as they would have to manage the teachers’ bookings in the portal. However, we won’t touch on her user journey for this case study.

Design

As I was not involved in the project from the start, initial wireframes had been developed during the proposal stage.

The primary screens were largely the base of the booking system, with features such as:

  • Museum Programme Finder

  • Calendar Booking form

  • Museum Programme page

Research

As we looked to improve the interface, I took a step back to study on similar booking portals and assessed features pertaining to museum tour/event pages, calendar and booking forms across different applications to discover their user flows. We also identified what was done well and what was not, so that we could minimise unnecessary interactions within the booking system.

User Flow

We then moved on to define the teacher’s flow of making a booking on the system.

Ideation

Using the initial wireframes as the core, we iterated the designs in order to improve the experience and user interface. On top of that, we assessed the opportunities and synthesised them into features.

Homepage

Museum Programme Finder:

This functions as a tool for teachers to search for programmes that cater to their preferences, such as time, date and number of students. Further requirements included a museum option and this led us to shift the tool to the bottom of the image slider. We also revised the hierarchy to such that it correlates with users who are used to the Z-shaped or F-shaped pattern.

Programme Filter:

We also revised the Programmes section to allow users to filter categories such as programme type, education level and museum. This feature is conducive for those who would like to view the type of programmes that a specific museum offers.

Programme Calendar

List of Programmes:

As one of the requirements is to let users view up to 2 programmes within the calendar space, we needed to take into consideration that more than 2 programmes would appear if users go via the Programme Finder route. Hence, we created a toggle function to allow users to modify the switches so they can view the slots of any 2 programmes in one sitting.

View Type/Legend:

Other features were the Calendar view type and legend to indicate the status of the programme slots. In the first draft, the legend was located on the top left hand side in the filter section but we realised it would be better to place it above the calendar so users can identify its meaning instantly.

My Selection:

Initially, My Selection was placed above the calendar, which should appear when the user selects a slot. However, we felt that the List of Programmes section should go above the calendar due to its law of proximity. This caused us to iterate and ultimately, we decided to place it as an overlaying box on the bottom of the screen.

Application

As the details for application expanded, we shifted from displaying the information in a modal to a full page within 3 sections, mainly Booking Details, Teacher Details and Summary. We initially wanted to display the application within the same page as the calendar for a seamless experience. However, we realised the amount of fields would be better off in a new page for users to focus on filling in the details. As this iteration was done concurrently while we were assessing the experience of checkout forms from e-commerce websites, we designed a cart summary section on the right side of the page to let users see their confirmed selection.

Mobile

Upon settling the desktop screens, we optimised for mobile devices and ideated on how it should be displayed on the respective pages.

Homepage:

Initially, the programmes were split according to its tour type and they could be browsed via horizontal scrolling. However, as we transited to the revised wireframe, we retained vertical scrolling for the programmes while making sure that there’s a sense of continuation for the filter function.

Programme Card:

As we did the programme card popup in the form of a modal in desktop mode, we opted for another approach in mobile where the programme card slides up and covers 80% of the screen. The primary action buttons are also fixed at the bottom of the screen so that users who might have already decided to book this programme prior to landing on this screen can proceed swiftly without having to scroll all the way down to do so.

Usability Testing

We conducted usability testing with 8x participants who are teachers from various primary and secondary schools remotely. The objective of this session was to:

  • Uncover insights on how teachers would perceive the new Museum Tour Booking System (MTBS) portal

  • Explore if portal and flow of booking are intuitive for teachers (desktop and mobile)

  • Assess feedback in order to improve MTBS portal

Current process of booking a museum tour

Here’s a rundown of the UT participants:


  • 2x find it easy to make booking within 2 to 3 email exchanges for time slot wanted

  • 1x feel it is complicated to book for multiple classes as additional backup time slots must be provided to museum staff

  • 4x find 3 working days to be quite long when it comes to finding out about available slots

Deciding factors on type of tours booked

  • All participants book based on availability of students’ timetable and content of the exhibition/museum

  • 5x book tours based on school curriculum

Protocols before booking

  • 4x will book based on discussed with committee or HOD in charge

  • 3x will research on the exhibit/museum content before booking

  • 3x will recce the museum 1 week to 1 month before trip

Flow of journey before and after museum tour

  • 7x mention that they go during school hours with Lower Primary students

  • 1x mention that tours for Upper Primary has to be done outside of curriculum hours

Rating of current booking system

  • 1x 9/10

  • 4x 7/10

  • 2x 6/10

  • 1x 5/10

Book a Museum-based Learning Tour (Desktop)

Amend A Tour (Desktop)

Book A Self-Guided Tour (Mobile)

General Suggestions

Key Takeaway

Upon feedback during the usability testing sessions, we synthesised our findings and revised some sections in the wireframes, which can be found in the following:

“No. of Accompanying Adults” field

  • Allocate field for each slot, change order of text fields and copywriting

  • Include option to allocate person as POC for all slots

Calendar Application

  • Booking of 2nd slot: to indicate that users can continue adding slots

  • Toggling of Programmes: revise copywriting in section to inform users that changes will be reflected

Amend Booking

  • “Edit Booking” button: to improve visibility of “Edit Booking” button and style of status

  • To improve visibility of “Tour dates/time slots cannot be amended. If a change is required,
    kindly cancel the slot(s) and create a new booking” and better inform user that no. of pax cannot be increased

  • Status: changed UI due to the preconceived notion of it being a button

Future

As changes for the booking portal are being implemented upon usability testing, we also developed a dashboard portal for museum staffs so they can keep track of the bookings made.