Case study: how we designed a complex event management app

A talent management agency came to us needing a better way to plan, organize and oversee musical events. Their business model wasn’t something we’d worked with before - managing artists, clients, contracts, invoices and their associated events - it didn’t seem too complex on the surface. But the deeper we went, the more challenging it became.

This ended up being one of the most complex projects we’ve worked on. A true test for our UI/UX and user flow creating skills. And why? Well, in UI/UX design you usually solve an issue. But in this situation, it took some time to truly understand the context of the client’s issue, and a bit more so to find solutions.

So in this article, we’re going to tell you the story of how this project came to life and how we navigated some of our biggest UI/UX challenges yet.

The first discussions and iterations

When we first met the client’s team, we were excited to finally work with a local company handling musical events. They casually name-dropped artists we’ve known most of our lives. After being starstruck, we were eventually struck by the complexity of their process.

The client is a Romanian agency that signs artists and books events for them. They handle deals, contracts, invoices, and every little detail that goes into managing musical events.

The biggest issue they were dealing with was needing to spread their entire event planning process over several different apps. They’d contact clients and artists through Whatsapp, manage contracts and invoices in dedicated software, write contracts in Word and then email them and track all updates manually, while keeping a mental track of events and their statuses.

The employees themselves were their database: they knew the clients, their details, who had to get an invoice or sign a contract, which event was finalized, which one was still in discussions, which artist needed to get paid and who needed to pay them, and so on. 

This was in itself a big issue. It was hard for them to organize all their different data points, and if one such employee left the company, it meant spending a lot of time onboarding new employees. They were handling a lot of information manually or across different pieces of software.

The first need we detected from our discussions with them was a need for a kanban board. It was clear they needed a better way to oversee events and their different statuses, so we knew that’s the first thing we can build. 

They explained to us that each event goes through a specific sequence that matches their company departments. They start out as offers, once they’re booked they become events in the booking stage (setting them up), then they go to the legal department (where contracts are made and signed), purchasing (where the agency or the client booking the event organize who needs to get paid and for what), invoicing (which brings back all purchasing info but attaches invoices as well), and finalized (events that took place and everything is wrapped up).

You’d think that makes it simple and clear, but each of these major stages have their own individual states. Offers can be proposals, sent proposals, confirmed or lost. Contracts can be sent, signed, modified, postponed, and so on.

The best logical solution was to put the major stages in tabs and use their individual states as kanban board columns. We also created a summary board that would allow management to oversee events across all big stages, all at once.

The first Offers board, featuring the following columns: being offered, offered, in discussion and lost. The page included a switch between the board and a list version, filters and a date picker.

This first iteration involved a sleek, minimalistic UI using a neon green as the highlight color. Each card represented an event (or offer) and contained its more specific state, a title, participating artists, event date, place, price and a section for attachments and comments.

Editing an event appeared to be complicated right off the bat. As each event had to go through multiple stages, the edit section had to account for each and every one, and somehow include all required information.

We split everything into tabs and also included a progress bar at the top, to reflect where the event is at a given time. All information was divided by department, however this is when things got tricky. As we had more discussions with the client, it became more and more difficult to picture the legal and financial tabs.

Figuring out user flows in face to face meetings

When you’re a software outsourcing company, working mostly with foreign clients, you’re used to only meeting them through video calls. But with this client, we ended up having long meetings at their offices in order to figure out user flows together. And to understand their process better.

This was a new experience for us, as we’ve been working remotely for the past few years. But getting to meet the whole team and listen to their input was very valuable. We came up with ideas together, made handwritten notes and sketches, edited the design real-time, and discussed each important page in detail.

We quickly realized how truly complex this client’s process was: different employees could book multiple artists per event, each event had a client and multiple contracts, each event involved accommodation, food or transport costs that needed to be accounted for very specifically, each artist’s contract type influenced what they get paid and from whom, and each contract will derive invoices that need to be paid by certain deadlines and can go through multiple statuses of their own.

It sounds like a whole lot, right? This was all information we gathered over the course of several weeks of face to face meetings and design iterations, which goes to show that building complex software cannot happen overnight and without proper brainstorming sessions.

The more discussions we had, the more ideas the client’s team had. Which meant squeezing in more and more features into an already feature-heavy app. This is when we had to step in and remind them how clunky an app can become when you add too many things at once. It’s like stuffing your closet.

When discussing app flows with stakeholders, it’s easy to fall in and say yes to everything they ask for. But it’s important to stick to your guns and say no when you know they’re making the wrong choice. This way, we managed to move certain edit portions into modals instead of putting them into the page, or splitting content into tabs where possible.

One of the biggest challenges this project had was its purchasing section: this is where the client’s team calculates who needs to get paid how much and by whom. Except here, you have to involve taxes and commissions, and the client’s team also needed to see estimates vs final costs both in view form and edit form. We had them explain and draw it out for us until we finally managed to design the page.

At the beginning of the project, given all the departments and their different roles, we initially wanted to create separate user roles for each, giving them separate permissions. This way, booking agents wouldn’t have been able to edit what the financial team is working on.

But as our discussions went on, we realised that it was overkill. And that agents sometimes needed to see financial data for their events as well.

Important UI/UX takeaways

As one of our most complex undertakings, this project was a great way to learn and grow in terms of our UI/UX and user research skills. We talked to each department, identified their issues and together tried to find the best solutions that would not only solve their problems but also work well in a piece of software.

Here are a few important lessons we learned through this project:

• Listen to clients but always share your input. We were well aware of how complex our client’s process was. But after many discussions, we realized that you can’t possibly automate everything. Their invoicing process was too complex and had to be done through an integration, thus they still had to use a separate piece of software.

• Don’t be afraid to ask questions. We had a lot of trouble understanding the event management process, the way they book events, organize contracts and handle all different entities they interact with. Every step of the way, we didn’t shy away from asking detailed questions.

• Ask the intended users what their problems are. A great way to come up with useful UI/UX solutions is to always ask users, “what problem do you want to solve?”. This came up so much while we worked on this project. For instance, after they asked for lots of contract-related fields to be added to events, by chatting more personally with the intended user (their legal department), we found out they needed to automate contract exports, which they were doing manually in Word.

• When dealing with a lot of data, use tabs and collapsible sections. Our client needed to input so many different types of data for their artists, clients, events and so on. Instead of creating long forms, we divided content into tabs that made sense. For instance, all artists had a crew attached to them, and the crew members were split into different categories. Under the edit artist page, we created a tab for the artist’s info and another for their crew. Otherwise, the page would have been long and stuffy.

• Make sure your user flows make sense. Some flows make sense to UI/UX designers and developers because they see them often and they work with software for a living. But make sure to test any unique flows you come up with with the intended users. Ask them if these flows make sense to them and if they fix their issues.

• Take complex apps one step at a time. App stakeholders might get excited and explain their process subconsciously expecting you to know all the ins and outs already. They might omit some details or only scratch the surface, and when you get to specifics you’ll find out how much information you were missing and you’d end up with 5 different design iterations. Our advice? Go by section. Discuss key parts of the app in different sessions so you can cover all key details and not mix up different parts of the app.

Overall, complex software is complex for a reason. It’s no surprise to be met with challenges when working on a piece of software that needs to compile what a business does across different apps. But the trick is listening to the users and finding their root issues. 

All in all, sitting down with the intended users (in this case, the client’s team), discussing flows and processes and coming up with ideas together is invaluable.

Looking to build a complex piece of software yourself? Let’s chat and find the best solutions. Alternatively, we also offer a free product roadmap so you can get an idea of what it would mean to build your software.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.