Role: UX Designer, Workshop Facilitator & Researcher
Company: Briq
Year: 2022
The booking system of Briq was specifically made for the Kartfabrique, a multi-activity venue in the Netherlands that mainly sells go-karting along with other activities like laser tagging and an escape room. These needs were similar for comparable venues that sell similar activities in one venue. With a few changes or adding new features, Briq could grow in that market. However, at one point, Briq felt the limitation of these specific venues made it harder to grow. They needed to be more appealing to venues that sell different activities other than go-karting and laser tagging. After some market research, they decided that the bowling market was attractive because of the number of venues that sell that activity. Briq’s current product couldn’t sell the activity well due to a lack of market-specific features. One of them was week schema pricing.
Learn how to adapt Briq's funnel and back office system to handle multiple pricing options for a single activity, depending on the time and day of the week, to increase its appeal to the bowling market.
Briq’s clients, before bowling, were selling their activities for one price, no matter the circumstances. After talking to bowling venues and looking at current examples, we noticed that a bowling venue sells the activity for different prices depending on the time or day of the week. So, one game of bowling can have a price on a Monday morning (slow day) of, let’s say, 15 euros, and on a Saturday evening (popular moment), the same game can cost 25 euros. They do that simply because they can sell it for that price. You see a similar pattern in the hotel industry. This pattern also won’t change soon because we know that bowling venues look at each other to see how their pricing works and which rate is active. Some of them have a simple schema where they only have a rate for the week and one rate for the weekend. Others make it a bit more complex, with different rates during the day.
Besides investigating how merchants want to use this feature and how customers want to be informed, there was another challenge with this project. The team's goal was to implement a discovery phase with more research activities to understand what we needed to build. The ‘old way’ of doing the discovery phase relied on the customer service department to understand what they were hearing, do some competitor analysis, and use the knowledge within the company. The company originated from a leisure venue, so much knowledge was already there. This way of discovery took the company very far. Still, problems arose when new colleagues from other industries joined the company without the knowledge that the founding partners had, and increasingly, the lack of understanding of how different activities are operated and sold. This led to results that didn’t always match what the end-user had in mind. So we needed to do this correctly. A discovery team was created, and because a colleague and I had experience with this phase, we took the lead in this project. Meanwhile, we continuously educated the rest of the company on what discovery is and involved colleagues in the process so they could help us gather information.
We knew what the bowling merchants wanted, but how was something we needed to discover. So, we started by looking at competitors, investigating pricing structures of bowling venues, and gathering old data. This was a project that Briq had already worked on, and we had some old validated ideas that I was able to share. We combined the insights into a slide deck and shared them with the team. We wanted to see if we were able to understand what kind of questions we still had. After a discussion, we knew we had some questions about the bowling venues.
I took the lead in organizing the interviews with merchants. We collaborated with the customer service team to find merchants willing to talk with us about this topic. We quickly understood that there was a high interest among merchants in speaking with us about this. This was a feature that some merchants had been demanding for a long time and wanted to help us with it. So I needed to prepare this. First, I created a Calendly invite. This helped me hugely because it is linked to my Google Calendar, and merchants were just able to schedule something into my agenda without any back and forth. I also created an interview script that I wanted to use. After some feedback rounds, we ended up with a final version. Two people conducted these interviews: one was the moderator, mostly me, and a team member was the observer to collect insights. Because most of our interviews were done remotely, we could also record the sessions, which helped us immensely in the post-analysis. After five interviews, I was able to find patterns and communicated these in the insights slide deck that was created before.
After the analysis of the interviews with the merchants, we were still wondering how other industries, like hotels and airline tickets, handle these types of pricing. So, a team member focused on the airline ticket industry, and I investigated the hotel industry. We both realized that the insights were pretty similar. Both industries are more than okay with letting an algorithm determine the prices, with some input from the seller. Often, there is a base rate and the lowest rate that something can be sold for. But this led us to the conclusion that the leisure industry isn’t ready for something like that. E-commerce is already pretty new for some of them, let alone an algorithm that decides your rate. With that research, we could create a problem statement from the merchant's perspective, allowing the ideation to solve that problem. For the customer who buys an activity, we realized that the challenge is to inform them about the rate they will pay. After the ideation session, we could move to the next phase.
Because this solution lives in the two worlds of Briq, the customer-facing application (Funnel) and the merchant-facing application (Briq app), we needed to approach our design phase accordingly. First, we focused on the Funnel. A UX designer and I looked at competitors in the hotel and airline industries and saw patterns in when and how they were showing these rates. So we created a few flow diagrams of how this would work in our Funnel. We soon realized we needed to show a price somehow because we knew that not all activities a merchant sells have a week schema. So we decided we needed something similar to what Tripadvisor had. They always communicate a ‘from price.’ After the first sketch round, we understood that we needed to display pricing in the list, deal page, and time page. We discussed our findings with the team. We agreed that having a from price is a good solution, but this can change significantly when a customer decides to do this activity on a day/time at a high rate. Not an ideal experience. So we thought about how we could prevent this negative experience. Our conclusion was to make a banner at the top of the page so customers would be more inclined to leave the information we need to calculate the right price. After sketching, we went to a higher fidelity wireframe to gather feedback from the developers. Based on their opinions, we dropped some ideas and adjusted others to create a high-fidelity wireframe that we could test with users.
As straightforward as the design phase of the Funnel went, the design phase of the Briq app was a little bit different. In the ideation phase, we couldn’t decide at which level in the Briq app hierarchy this feature should be. The reason was that you want to reuse the schema as easily as possible, but you also want to have a clear idea of what the impact of that schema is on the deals connected to it. So without a clear decision, we couldn’t move to the design phase. I made a visualization of flows to show the impact of a feature on each level. But after discussing this with the team, we weren’t able to make a decision. We needed to talk to the developers to see what they thought. After a discussion with the back-end lead, we could determine the level where this feature needs to be. He also likes to think along with the front end and proposed a solution we could look into. His solution became the foundation of the solution we presented to the team. After a round of feedback from the discovery team, we also showed the solution to the developers. They were able to give us a few last pointers, enabling us to create a high-fidelity wireframe to be tested with the users.
Before we created the higher fidelity wireframes in Figma, we thought about what we wanted to validate and how. We often use Maze for this to have easy access to the customer base and gather fast feedback. So after creating the first setup of the test in Maze, I made the prototypes and the necessary images to help questions be answered. We tested our assumptions, and it was nice to see that most of our solutions were understood and used. Based on those conclusions, we created high-fidelity designs and handed them over to the development team.
Like most Medium articles say about the discovery process, this one was also not linear. Seeing how the team reacts and plans the following actions is always interesting. I often know that eventually, everything will be fine, but communicating this outside the team and to colleagues who have no experience in this process was a little bit harder. However, when we actively showed our approach and learnings, the company saw the value of this process, which was incredible to experience. Because this was the first time we did the discovery process like this, we decided to do this with the discovery team and not with any of the developers. In hindsight, we realized this wasn’t the best way to do this. It would have saved lots of time by including them in the process instead of excluding them. I would try to include the developers in the next project to help the discovery team find the best solution.