Michel van Heest — Product Designer

Learning about the contexts where people are deciding on performances

Based on industry knowledge, we worked out the various contexts in which people consider which performance to check out at the festival:

Before the festival: orientation

At the start and during the festival season, people decide whether or not to attend a certain festival by looking at line-ups and searching for artists they like. Knowing who plays, and for multi-day events, at what day, people make the decision whether or not they like to go.

When a festival is picked, people mostly orient on which artists they want to visit by viewing the line-up, because it presents performances in an artist-first approach, while a timetable presents performances in a stage-first approach and highlights possible overlapping performances.

During the festival: determination

Before the festival, many people create an indicative schedule. During the festival, people use this indicative schedule in the timetable to decide where to go next, taking into account factors such as their location, time, the people they are with, the weather, and of course one or more overlapping performances they marked as interesting in the orientation phase.

Designing intuitive and helpful tools to decide on performances

Line-up: showing all artist alphabetically

I designed a simple list view for the line-up with all artists sorted alphabetically by default so people could easily find a specific artist. I added section index headers and a section index to help users quickly navigate through the long lists.

We also added an alternative ‘by day’ sorting, which allowed people to get a clear overview of which artists were playing on a given day. This made it easier for them to decide which days looked interesting.

Timetable: identifying needs

I researched calendars, various planning and roadmapping tools and timetables to learn about what’s important when designing a mobile-first timetable:

Performances are grouped by stage to facilitate location-based planning. It is therefore important to be able to view all stages and the times of their performances.
The horizontal Gantt chart format, where each swimline displays the performances of a specific stage, makes it easier to decide which performance to attend and identify any overlapping performances. It allows for comparison of more stages on portrait-oriented phones than a layout like Google Calendar would.
Since there is a lot of data to display on a small surface, reducing the need for scrolling is important to make it easy to take in the data.

Helping people compare stages and pick performances

Based on industry knowledge, we learned that performances could range from 30 minutes to 2.5 hours, and sometimes even 8 hours. To accommodate for shorter performances and make it easy to see when they start and end, I decided to create a grid structure of vertical lines per time unit where the blocks with performances could sit on top of that shows time-blocks of 30 minutes to group performances on.

Showing a fixed number of hours and calculating the width of a time block felt easier and more scalable to develop, test, and maintain than making hours a fixed width. Fixed widths would cause the timetable to look different on each device, making it harder to QA and not optimized for any device at all.

After exploring with short and long artist names and performance durations, we settled on showing 1.5 hours within the horizontal viewport. This worked well on devices that are <375px and of course even better on larger devices: artist names almost never got truncated and we had enough space to show multiple performances at the same time.

Using dummy data, I prototyped the horizontal scrollview of the timetable with performances and worked on showing multiple stages with performances on the y-axis, creating a bi-directional scrollview for when not all stages could fit on the screen. When scrolling vertically, I decided to always pin the time indication at the top. Scrolling horizontally would always show all stages with their performances. This ensured that the factors on which choices were mapped were always visible.

As showing more stages vertically in the viewport meant more data to compare without scrolling, we ended up giving the performances a fixed height and showing ±6 stages on the iPhone X (which is nowadays seen as a small device), and even more on larger devices. For smaller festivals with fewer stages, this meant no scrolling on the y-axis was necessary, and for larger festivals more data was visible at once. Only needing to scroll on the x-axis made it easier to compare stages and pick performances.

With the basic timetable components in place, I began incorporating the visual branding of different festivals into the design elements. This was important as the styling editor we developed heavily influenced the overall look of the timetable.

We created a date indicator with left and right chevrons to make navigating multi-day festival timetables easier. Tapping the chevrons scrolls to the start of the specific day. We also enabled horizontal scrolling across days, as we found this to be more intuitive than having to tap to the next or previous day at the end of the current day in the scrollview.

By liking performances within an event, users could create their own personal timetable. This timetable only displayed stages with liked performances, while still showing the time-gaps between performances, making it easy to identify overlap between performances and available time for other activities.

Designing the editors environment for managing the data of all line-ups and timetables.

We created a "Performances" part in the CMS environment we built to manage all performances in the line-up and timetable of specific festivals. The view has a big table with all performances, where all data can be added, and partially pulls out data of a separate part of our database where all artists are managed globally so they don’t have to be created for every festival individual.

We built a feature that enabled editors to publish or unpublish specific features for festivals. This allowed users to only see and use the features that were published for the specific festival. This feature enabled editors to fill in the lineup early before the festival, supporting "before the festival" scenarios. When the stages and times were released (often just before the start of the festival), the meta-data could be added automatically to create a timetable.

Making it less cumbersome to add large sets of performances to the CMS

For the MVP of the CMS, we had to work with a limited budget, so we decided to not build a full-featured spreadsheet-like application that would enable copying and pasting large amounts of data for performances from elsewhere. As all festivals would pay to use the application and we had editors, manually entering the data for each performance was a reasonable trade-off.

However, this trade-off changed during the process. Initially, the vision was that only paying festivals could be used in the application. Later on, for retention and growth purposes, we learned that it would be better to show all Dutch festivals with basic information and mark paying festivals as “affiliated”, granting them extra features. As most festivals were not affiliated yet, but we still wanted to show them a line-up with at least artists (without dates, times, and stages), this manual approach was no longer viable.

We designed and developed an importer to make creating line-ups quicker. It allowed editors to paste a list of artists, which would be matched with our global artist database. If the spelling of the entered artist name matched the name in our database, they would be added to the timetable. Unmatched input could be manually linked if there were typos made or they could be added as a new artist to the festival and global database. This addition to the CMS made it exponentially faster to enter line-ups for affiliated and non affiliated festivals.

Improving ‘the use of the timetable at night’ based on user feedback

After shipping the first version of the timetable as part of the MVP of the app, and beta-testing it for a while, we noticed multiple areas in which the timetable wasn’t as clear as we wanted it to be, and it had some issues we didn’t think of before.

Showing more data at the same time

When designing the first version of the timetable, we wanted to avoid truncating artist names as much as possible, so we chose to display 1.5 hours in the device's viewport. However, since performances turned out to last an hour on average, the timetable was less clear than we had hoped. Users had to scroll a lot, which felt tedious, and the experience of going over the complete timetable was worse than using a large paper timetable, even tho we had fancy features such as liking performances and creating a personal timetable.

To solve this, we prototyped different layouts showing 1.5, 2, 2.5, and 3 hours. We eventually settled on showing 2 hours in the viewport, as this displayed more performances on the same stage without truncating artist names too often. However, users still had to scroll a lot. Showing 2.5 or even 3 hours at the same time would have solved this, but this would have meant that for performances with a duration of 45 minutes, artist names would get truncated after three characters, and reducing padding didn't solve this enough. It would have made most of the data unreadable.

I worked on different solutions, such as zooming out the timetable to show a smaller but more readable version of the timetable, but this turned out to be too complex to build within the limited time we had. For the time being, we decided that showing a maximum of 2 hours at the same time solved most issues without making text unreadable small, ship the change, and live on it for a while.

Improving showing performances after midnight

For multi-day festivals, we were displaying all the down-time hours, which turned out to be something that was unnecessary. For example, festivals often finish their last performance around 2 or 3AM and start up again at around 10 or 11AM, creating a 9-hour time block that users have to scroll past to see the next day.

We also found that for festivals that take place on, for example, Friday, Saturday and Sunday, performances that take place on Saturday 2AM of 3AM were seen as “Friday night”, even though they technically occurred on Saturday. People referred to the change from one day to the next as after they slept. Showing the actual day made the timetable confusing to use in practice.

I solved this by creating rules that any empty space of 3 hours or more at night would be hidden, and performances between 0 and 9AM on multi-day festivals would be displayed as if they belonged to the previous day. For example, "Saturday 2AM" became "Friday night 2 o’clock". We also added a divider to better indicate a change of day.

This created various edge cases where this could go wrong, such as automatically adding an extra day before the original starting day of the festival when there was, for example, a short yoga session at 8AM on the first day. We listed all possible edge cases and created solutions for them.

Wrapping up

After discussing these changes with our client and testing them, we found that they solved the issues, made the timetable more enjoyable and organized, and ultimately performed better.

The project was successful in creating an organized and clear overview of all the performance data. The features were intuitive to use and helped people choose the best performances before and during the festival. Our improvements to the timetable made it even easier to compare stages and pick performances, and to distinguish between days. All of these improvements ensured a successful festival experience.

One of the things I still want to explore are ways to show even more data at the same time. The zoom feature is still something that could work, especially when combined with enabling a landscape mode.