Defining the case

Learning about business needs from festivals

Based on research and industry knowledge, we learned that there are a lot of reasons festivals want to contact their audience.

Enabling efficient communication

Direct and real-time communication seemed crucial to enhancing the festival experience. We decided that a chat messaging system within the application would be the most effective medium as its brevity and immediacy would increase the likelihood of messages being read, and our target audience was already using the app. Additionally, we developed a push notification service to ensure that users were alerted to new messages. With these two features combined, we expected to build the best communication tool for festivals and their audiences.

Driving app adoption

A bonus of building the chat service was that if the festivals started using this as their primary communication method, it acted as an extra incentive for them to push the adoption of our clients’ app at their festival because they want to reach their audience. More adoption wouldn’t only benefit the festivals, but could also drive the user-acquisition and engagement metrics of our client forward.

Defining the scope

Deciding on building a custom chat

During a strategy and design session with our client, we discussed the advantages and disadvantages of building a custom chat service versus using existing customer service and communication tools such as Intercom, Messagebird, and Zendesk. We evaluated the defined use case of the chat and concluded that deep integration with all the features of the app, like maps and timetables, was necessary. Adding and integrating a third-party service would require redactions to use an additional tool, or we would need to build an expensive integration into the existing CMS. As this sounded less scalable, we decided on building a basic custom chat we could iterate on with the exact business and user needs we would learn about after launch.

Defining message types based on communication needs

Based on the communication needs of festivals, we defined a set of message types we wanted to support. We ended up with five types that made it possible to do most of the things needed:

Designing a system for festivals to compose, plan and send messages

Defining the needs of festivals

Based on the needs, as illustrated below, we decided that a web-based direct chat interface like normal messenger apps wouldn’t do the job. As replying wasn’t possible yet for users, we needed something that worked more like composers for writing and publishing blog posts as this model seemed more optimized for our goal.

Working out the composing flow

We expected messages to be written based on a certain order and content strategy. This meant that when composing messages, although the specific content might not yet be thought through, the type of message (poll, default message with basic visual styling, shop carousel links, etc.) would already be defined when composing the message. We decided to split up the earlier defined message types and designed a flow that supported the composing workflow and help the writer by creating a focused UI around a specific message type:

After designing this flow using the components of the design system of our CMS and going over it extensively with our client, we noticed that this setup wasn’t flexible enough for real-life needs. I focused too much on the technical approach of classifying messages as types, and not enough on the actual workflow of users. As we decided that not all message types would have the same properties like support for images and a WYSIWYG editor with bold/italic text, hyperlinks, buttons, etc, and people had to pick one message type before composing a message, it wouldn’t be possible to create a message that for example included styled body-content and a link to an external merch store, while highlighting certain items in an image-carousel with links.

Switching around the flow to support more free-flow writing

To solve the issue I created, we decided to switch around the flow to something that would be more versatile when composing and drafting messages, and that would make it possible to mix and match the properties of message types while still being intuitive to use:

Designing a modular composing window

Based on a set of example messages festivals were looking to send to their audience, we learned that most messages would start with or include body content with the main point of the message. To help in this composing workflow, I designed the UI so that all new messages started with an empty input for body content so editors could start typing their messages right away. I combined the body content with a tool tray with various properties that could be added to the main message, like a header, an image with or without a link, buttons, etc.

Based on the new flow, editors most often would start with their basic message, and start adding other blocks to it after that. To make this possible, I designed a Notion Blocks-ike picker that could be used to add blocks to the basic message, like a carousel, contact options, or multiple-choice answers. For the carousel, I designed a simple set of image inputs with hyperlinks. The contact message block could be filled by checking boxes from the available contact methods set up in a different part of the CMS.

The hardest part of designing the composer were the multiple-choice questions, especially the part where we wanted to add logic jumps in order to send a follow-up message based on user input. After doing some research into how tools like Typeform handle logic building when composing a survey and how tools like Notion and Airtable handle complex filtering systems with nested boolean operators, we decided that building logic jumps was too complex for the needs of our MVP. We decided that all multiple-choice answers could only get one follow-up message.

After exploring and experimenting with various layouts, I ended up with a nesting structure that supported one level of ‘logic’ while still giving focus to a certain job to be done.

In various iterations, I ended up with this layout where answers and follow-up messages could get composed and connected independently from each other. As the long view could get cluttered quickly, I experimented with options to collapse certain parts of the multiple-choice editor, but after verifying these layouts, it turned out that collapsing content hid important parts of the context an editor was working on. To make the view less cluttered, I used whitespace to group certain parts together or to make certain parts stand out.

Scheduling messages

To schedule a composed message, we created a date- and time picker and listed all scheduled messages in a data table that could be sorted based on content, ID, or sending date, and that could be searched through.

Integrating the chat in the mobile app

Leading the mobile design

As we were on a tight deadline before our engineering team had to start working on the implementation of the chat, and there was a lot of back-and-forth between them and me needed, I didn’t have the time to design the chat feature and all message types for the mobile application myself.

To speed up the design process, I worked out the needed features and issues in Jira, did some high-level interaction design, and lead the design efforts while Dennis, one of my more junior design colleagues, was creating the actual mocks using the component and style library for the apps I created for other parts of the mobile app. In this way, I could focus most of my time on the chat builder in the CMS, aligning design and development, and doing client communication.

Designing the chat view and message types

The first versions of the chat MVP would be read-only for festival visitors, so besides setting up a grid to show messages in, most of the design efforts for mobile were focused on designing the various message types and speccing out all the ways a message could appear for our mobile engineers to implement, which Dennis did a great job at.

At the same time that Dennis is working on the message types, I designed and worked out other important parts of the chat, like:

• Spacing and grid of UI components in the view
• Starting point in the scrollview when having one or multiple unread messages
• Showing notification dots in the tabbar and marking unread messages as read
• Interaction with multiple-choice messages
• etc.

Designing push notification support

In addition to developing the chat system, we designed a push notification service. The service provided content managers with the ability to assign a push-notification:true flag to specific messages, enabling urgent or time-sensitive notifications to be delivered directly to users.

As users can receive messages of multiple festivals at the same time, and not all content that festivals can send within the chat isn’t natively supported for push notifications, we worked out rules for the way the content of a chat message should be displayed within a notification.

Results & reflection

The chat is currently not in use yet by all festivals, which means there isn’t a lot of data like a percentage of the impact the chat makes on retention yet, but from the initial testing we already heard great results: it’s easier for festivals to communicate and be in contact with their audience before the festival, and during the festival it’s way easier to act on what’s happening.

A couple of things that stand out that need improvement:

• The composer in the CMS needs to be way more dense. Inputs and text are too large and take up way too much space, which means that users have to scroll a lot, even when setting up a single message
• The chat should get a deeper integration with other features of the app, like an integration with app to easier point towards places on the terrain, and an integration with the line-up to highlight and push certain artist

The chat will be a premium feature of the app, and we’re currently also looking into the possibility to automate certain parts of the communication for festivals so the chat can also be offered to freemium festivals and possibly still increase retention.

Credits

This project couldn’t exist without these wonderful people I collaborated with over the course of the project:

Casper

PM

Roland

Lead engineer

Lars

Flutter engineer

Louis

Backend engineer

Dennis

Product designer

Iris

Design intern