At an on-ground event, all staff must have badges to ensure they have access to only the areas they need. For an organiser managing vendors across security, F&B and more, this could mean hundreds of staff, each with unique access requirements.
Managing staff at a live event can be an intimidating prospect. A concert or sporting event could have hundreds of staff members, each requiring their own level of access to different areas within the venue. In addition, different roles may be fulfilled by multiple vendors—for example, security, food & beverage, backstage crew, etc.
We built a web app that organisers used to receive applications from vendors, organised them by role and access area, and produced printable PDF files to be sent to printers to create the final badge.
The entire web app is complex and covers dashboards and forms for vendors, organisers and administators. As a designer my first goal was to understand the journey of an approval, and find key areas to focus on.
These four primary steps are handled by four different groups of people, so we created flows for each of the segments of the journey helping get an overview of how well applications were proceeding through the pipeline.
Application, verification and printing each dealt with a specific repeated problem, however manager approvals slowed the whole process down. Managers had to analyse a table of data listing every current staff application, all related data, and had to confirm they were being given the appropriate badge.
Additionally, because of the size of the table, users felt the need to use a laptop since it was unweildy to manage on a phone.
Watching people use the system and talking to users about their thought-process we discovered the table itself was only a means to an end. When actually reading data, users hardly ever looked at more than one row at a time. They would look through one person’s data, make a decision to approve or reject, and then move to the next.
An important learning was that we had modelled the interface on the shape of the content, rather than the way users were interacting with it.
The size of the data-table also missed a huge opportunity for users—travel time. Many users spent a lot of time in transit, and wanted to be able to complete this task during that time. The large screen requirement restricted their ability to do that.
To improve this, we created two new views for the table. Each to handle a different use case:
We switched the table for a simpler list, and focused on the tools for filtering. This gave managers more granular control over the list they needed to tackle, and a much easier time dividing their work into manageable chunks.
When assessing and approving, users see one profile at a time, with the information broken into 3 key sections. This meant fewer distractions, and a fluid way to go through the list.
Users reported getting through lists quicker, and drastically lower fatigue when compared to parsing through a full table.
