A one-stop-shop to drive organiser repeat usage

The number of service requests per organiser was dwindling

Typically, the majority of organisers would find Add to Event organically online and submit an event request for a particular service. Once this organiser had received quotes and used the platform, only 21% of them would use the service again. Our repeat usage was low and the organiser experience hadn’t been updated for 4+ years. The goal was to increase user adoption with a newly refurbished organiser platform, driving interaction and subsequent submission of more service requests. As the sole product designer at the company, my role was all-encompassing and involved leading all sections of the design process and output.

A start at understanding organiser motives

In the midst of this ambitious goal, we also realised that we were fighting growing trends in the market. In a survey that I sent out, 72% of participants stated that they usually find suppliers through word of mouth referrals. In addition, 41% stated that social media platforms had been a useful avenue for finding and contacting suppliers. These two statistics go against the need for a Marketplace like Add to Event! However, in the same survey, 42% of organisers stated that they prefer to find new suppliers for their events. I hypothesised that the organiser inbox could be more of a one-stop-shop for managing event requests, viewing quotes, and chatting with suppliers. An easy management tool that helps you plan your perfect event and also highlights the thousands of professional event suppliers that partner with us.

Taking a step back to understand the current organiser experience

My first step involved conducting a UX audit of the current organiser experience. I discovered the following key issues:

1. The whole experience was generally uninspiring. Events are usually times for celebrating, why is this excitement and anticipation not embodied through our platform when organisers are choosing event suppliers?

2. Functionally the experience allowed an organiser to review quotes, chat to suppliers, and accept/decline them. But, it did nothing to keep the users from coming back. It wasn’t sticky, there were no benefits, no social proof, or no upsells to keep them there.

3. Navigational inconsistencies between the mobile and desktop experience were spotted. Important areas of the product were being held away from easy reach, such as easily getting back to the inbox on desktop. There was also a makeshift navigation on mobile to switch between profile and chat when reviewing a quote from a supplier.

4. Information regarding the status of the request was tough to dissect, given the poor information architecture. Request status text was unclear and bloated.

5. Inaccessible experience across the board. Various elements of the experience, including text colour contrast and text size didn’t conform to WCAG AA accessibility guidelines.

Focusing on the foundational aspects in Figma

It was prudent to kickstart the conceptual work in Figma considering the UX audit uncovered so many foundational aspects I knew how to address. I began with a primary focus on the mobile-first experience, ensuring core navigation and hierarchy was tackled first. Because this experience was a behemoth, it made sense to split it up into core Epics. These Epics would correspond to the way the product would be built; in an agile manner, using a two-week sprint format. It also meant that a refined Figma prototype could be created for each Epic, ensuring that the flow wasn’t too longwinded for future testing, as well as making it easier for developers to breakdown the experience.

Tags to communicate the status of service requests

The request overview screen was bloated with text and vague suggestions of what to do next. As a result, I designed a tagging system to align with specific event IDs in the backend. For example, when a request is submitted in the system, it has to go through a publication step. When a user accesses their dashboard they would see the status as ‘awaiting approval’. To provide more context, a refined explanation message accompanied each status to concisely tell the user what the current status of their service request is. Moreover, a dropdown progress checker was designed to provide further guidance. This element would be a feature of each individual service request and would update automatically based on certain factors such as an organiser receiving a quote, or an organiser accepting a quote.

Bringing consistency to the navigation

We didn’t want a repeat of the old experience, having to create a custom navigational element for one specific viewport, only to hide it on other viewports. These workarounds bloat the HTML and can seriously increase page-load speeds. The solution was to provide one point of navigation on mobile; the hamburger menu. Despite hiding important links, it also allows prime mobile real estate to be used for its intended purpose. When scaled up to desktop, this hamburger menu becomes a permanent fixture on the left-hand side of the experience. The use of this menu makes the experience more adaptable to a growing functionality further down the line. If we wanted to introduce a new section of the experience, or add in another external link, we could. The navigation was officially future-proofed.

Fixing a tedious accept/decline quote flow

The default accept/decline journey involved going through a long-winded form process to discover the reason behind their decision, and in the case of declining, who they chose instead and their reason for this choice. These superfluous and mandatory questions were a strong reason why this aspect of the experience wasn’t seeing much interaction. It was an important issue to fix as we’d often have suppliers complain about organisers not responding to their quotes at all. My solution was to flip the current flow; getting the organiser to accept or decline the quote first, and then encouraging them to provide their reasons why. This secondary step was optional. Additionally, as a way to better encourage organisers to respond to quotes, after accepting or declining one quote, the flow would cycle through any other quotes and give the organiser the option to accept or decline them too.

User Testing the various prototypes to gain rapid feedback

I tested the desktop and mobile prototypes with 8 participants per prototype. Participants were set specific tasks to complete so that we could assess task completion rates. The following key findings emerged:

1. When reviewing the awaiting approval/quotes screens, participants would like to have seen an estimate of how long it takes to get approval/quotes. Some form of average quote response time based on the service.

2. Participants also picked out the repetitive process of having to click through to get to specific quote chats. A solution to this would be a messaging/notification area so users can go directly to the specific request or quote in a reduced number of taps/clicks.

3. Multiple participants also stated that it might be easier to have an upcoming bookings area, with the ability to view and chat with the suppliers you've booked. Similar to the point above, reducing the number of taps/clicks to navigate to an important area of the experience.

From the user testing, I observed that the use of visuals and descriptive imagery was much appreciated. Users could easily distinguish between particular service requests and the presence of contextual images brought the experience to life. A minor but much-needed change from the old greyscale experience.

Reflections and learnings

A key learning from this project was that you don’t need to reinvent the wheel. As a designer, there’s a tendency to stick to the UX process, and go through all the steps without consideration of whether or not this is absolutely necessary. The UX audit, coupled with researching best practises when it came to dashboards, enabled me to be confident in my design solutions. It was also important from a business perspective that we started the design process quickly, in order to impress stakeholders, and allow the development team to build iteratively. We now have a live experience in our testing app. The next stage is to open this up as a beta to a closed group of users. From here, we can ramp up the testing and Hotjar recordings to gain further insights. It’s then on me to iterate and improve the experience based on this feedback.

Next steps

The next big iteration of the organiser experience is to attach service requests to an overarching event. This would empower an organiser to easily request multiple services for one event, without having to fill in multiple request forms with the same information. This also unlocks the ability to upsell recommended services for an organisers event, as well as other amenities, such as venues and insurance. There’s a great deal of potential here. A short-term enhancement of the experience would be introducing a dedicated notifications centre. From the feedback it was clear that users wanted a central place where they would get the latest request status change updates, messages from suppliers, as well as other important reminders. This would also act as another sticking point, and these notifications could be tied to email or SMS comms too, to bring users back into the experience.