Transforming Brella for large-scale events

Project - Change product structure to fit new market requirements

```
Project Type  - Product feature
```
```
Duration - 5 months (2024)
```

Role - Senior Product Designer & Feature Lead

Since its launch, Brella had been built around the assumption that networking would take place in a single designated area. Every feature related to meetings, locations, and logistics was designed with this core assumption in mind.

However, as Brella grew and began attracting larger events, this limitation became a major roadblock. These new events often had thousands of attendees, and one networking area simply wasn’t enough to accommodate them. Event organisers needed the flexibility to create multiple networking locations, each with its own rules, schedules, and capacity limits.

This was, without a doubt, one of the biggest structural changes in Brella’s history. The shift wouldn’t just affect meeting locations, it would impact scheduling, user flows, admin controls, and the entire networking experience within the platform.

Background

At the time, I had already designed and shipped two major features. The new Schedule and Group Meetings, which had successfully unlocked larger markets for Brella. These new clients were the ones who most urgently needed custom networking locations, making it clear that this was a top priority for the company.

Impact

making it possible to support much larger events.
with the new automatic slot suggestion.
solving a long-standing industry problem.
increasing Brella’s appeal to large event clients.

A comparison of the user flow for creating a meeting before and after the feature release. Post-release, the product handled all meeting logistics, allowing users to focus entirely on the event and networking.

Problem and research

Complexity

When this request landed on my desk, I immediately recognised the scale of the challenge. Before jumping into solutions, I took a step back to understand the full context. I wanted to make the most of it by including other related feature requests we had.

Digging into existing data

I started by going through our design backlog and Nolt (our customer feedback tool) to see if this request had come up before. Unsurprisingly, it had, many times. But what stood out was that these requests were often linked to another feature: Hosted Buyer Meetings.

Hosted Buyer

Hosted Buyer is a system where event organisers pre-arrange meetings on behalf of high-profile attendees. Unlike regular networking, where attendees schedule their own meetings, Hosted Buyer meetings require a higher level of organisation, and event planners often assign specific locations for these meetings.

This insight was crucial because it meant that custom locations couldn’t just be about adding more spaces. It also had to account for different meeting types and logistical needs.

Stakeholder research

To ensure I wasn’t missing any critical angles, I conducted workshops with our Customer Support and Sales teams. These teams worked closely with event organisers, so they had a deep understanding of recurring challenges.

Different Hosted Buyer setups required flexible configurations.
Crowd overflow issues arose when networking areas reached capacity.
Different locations needed unique schedules rather than a global one.
Attendees were overwhelmed by the sheer number of networking slots.

After the workshops concluded, I created a dedicated Slack channel to include all internal members interested in contributing further.

Client interviews

With the information I had in hand, I scheduled calls with existing and potential clients to test my assumptions. Rather than simply asking questions, I prepared visual sketches in FigJam to illustrate different concepts. This helped structure the conversations and ensured that feedback was focused and actionable.

These discussions confirmed that we were on the right track. Many event organizers expressed frustration with the current limitations, and they were excited about the possibility of more flexible networking setups.

Defining the scope

Prioritisation for first version

With a massive core change like this, scope control was crucial. After research, I:

Separated must-haves from future iterations.
Ensured that Hosted Buyer was included in the first version to maintain alignment with the actual problem and requests.

Collaboration

During planning, I identified an overlapping feature in another designer’s pipeline. She was working on how meetings and attendees were displayed in the Admin Panel. This had significant overlap with Custom Locations, so instead of designing in isolation, we decided to align our roadmaps.

Design workshop

To make sure we were keeping things simple and solving the right problems, we held a design workshop where we mapped out different approaches. The goal was to identify:

How to make the setup process as intuitive as possible for event organisers.
How to introduce new networking areas without disrupting existing user habits.
Whether there were any shortcuts that could help us implement the feature efficiently without adding unnecessary complexity.

Feature squad

Once I had the initial plan, I scheduled a meeting with the Feature Squad, which included Frontend and Backend Developers, QA, and a Product Manager.

Kick-off

The first meeting with the feature squad was what I call the “Ice Breaker” is a session where I present the problem, research findings and the proposed approach. I walked the team through the entire process, explaining:

Why this feature was crucial for Brella’s future growth.
What challenges we needed to solve.
How we could implement it efficiently without disrupting existing workflows.

This session was highly collaborative, and one of the biggest breakthroughs came from a developer’s suggestion.

Breakthrough idea

During our discussion, a developer mentioned that he had explored an automatic slot-picking system during a recent hackathon. Instead of making users choose from dozens of time slots, Brella could intelligently suggest the best available slot based on preferences and availability.

This idea aligned perfectly with our goals, and I decided to integrate this idea into my solution

Executing the design

Given the high-impact nature of this feature, I maintained close collaboration with stakeholders throughout to ensure feasibility. I scheduled frequent feedback sessions during the design phase, allowing me to refine my approach based on input.

Multiple prototypes

Because this feature modified one of our most-used workflows, I developed multiple prototypes and conducted internal UX A/B testing to find the most effective approach.

Visual diagrams and charts

The new design included many complex user flows. To communicate these clearly and enable detailed discussions, I created user flow diagrams. These diagrams served as valuable references for developers during implementation and QA engineers during testing.

Given the critical nature and complexity of this feature, I created prototypes for nearly every key scenario. These prototypes were quite useful for validating ideas with both internal teams and external stakeholders.

By simulating different workflows and edge cases, these prototypes allowed us to:

Test the user experience across multiple scenarios.
Gather actionable feedback early and often.
Ensure alignment between stakeholders, developers, and clients at every stage.

Challenges

Iterations

One of the challenges was the continuous iteration required to refine the design. As the feature evolved, I started getting feedback at every stage, from internal teams, stakeholders and clients. This iterative process ensured the solution met diverse needs, but it also meant revisiting and revising designs multiple times.

In each iteration I revised the designs and all supporting materials, including complex flow diagrams, charts, and prototypes. These updates were crucial for maintaining clarity and ensuring alignment across teams.

Testing

During QA testing, we discovered that my new design conflicted with a legacy feature that a small but important group of customers still relied on.

Since we were late in the process, I needed a quick yet effective solution. I came up with four possible fixes, presented them to the Feature Squad, and guided the team in choosing the best balance between user needs and development feasibility.

This experience reinforced the importance of early cross-team collaboration and rigorous testing in large-scale projects.

Key takeaways

End-to-end ownership: Led research, design, execution, and iteration.

Cross-functional collaboration: Worked with Sales, Support, Engineering, and clients.

Team player: Aligned with another designer to integrate overlapping features.

Project & stakeholder management: Balanced business goals, timelines, and technical constraints.

Driving business value: Designed a solution that helped Brella expand into new markets.

Iterative, feedback-driven design: Managed extensive feedback to refine the experience.

QA involvement: Ensured quality and solved late-stage challenges proactively.

This project was one of the most impactful at Brella, fundamentally reshaping the networking experience and expanding the product’s capabilities. The process reinforced my skills in product thinking, stakeholder collaboration, and problem-solving, all while delivering tangible business value.

Final thoughts

All materials and content related to the Brella platform presented in this case study are the exclusive property of Brella. As the designer, I am showcasing this work solely to illustrate my design contributions. All rights, including intellectual property rights, are fully reserved by Brella Oy.

Cover image template from Mockup-Design.