Role Workshop facilitator, UX/UI Designer, and UX Researcher
The booking system of Briq was specifically made for the Kartfabrique, a multi-activity venue in the Netherlands that mainly sells go-karting 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. But at one point, Briq felt the limitation of these specific venues became harder to grow. They needed to be more appealing for venues that sell different activities than go-karting and laser tagging. After some market research, they decided that the bowling market is attractive because of the number of venues that sells that activity. Briq’s current product couldn’t sell the activity well because of a lack of market-specific features. One of them was week schema pricing.
Briq’s clients, before bowling, were selling their activities for one price, no matter what the circumstances were. 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 thing 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. But others make it a bit more complex, where you have different rates during the day.
Besides investigating this feature on how merchants want to use it and how customers want to be informed. But 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 was relying 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 of this way showed 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 weren’t always matching 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, continuously educate the rest of the company on what discovery is and involve colleagues in the process so they can help us gather information.
We knew what the bowling merchant 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 idea’s 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. So after a discussion, we knew we had some questions about the bowling venues.
I took the lead in organizing the interviews with merchants. So 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 of 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 this 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. With some feedback rounds, we ended up with a final version. Two people did 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 session, which helped us immensely in the post-analysis. After five interviews, I was able to find patterns and communicated this 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, hotels and airplane tickets, do these types of pricing. So a team member focused on the airplane ticket industry, and I was investigating 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 selling. Often a base rate and the lowest rate that something can be sold. But this leads 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. I allow 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 like that. First, we focussed on the Funnel. A UX designer and I looked at competitors in the hotel and airplane industry 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 hugely when a customer decides to do this activity on a day/time at a high rate. Not an ideal experience. So we were thinking 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 the 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 seemingly straightforward, the design phase of the Funnel went, did the design phase of the Briq.app a little bit differently. In the ideation phase, we couldn’t decide on with level in Briq.app hierarchy this feature should be. The reason was that you want to re-use the scheme as easily as possible, but you also want to have a clear idea of what the impact of that scheme 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 the round of feedback from the discovery team, we also showed the solution to the developers. They were able to give us some last few pointers to make us able 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 a first set-up of the test in Maze. I made the prototypes and the necessary images to help questions answered. We tested our assumptions, and it was nice to see that most of our solutions were seen 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. But when we actively showed our approach and learnings, you noticed that the company saw the value of this process. What 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.