Design Leadership | UX Research
Clients need the ability create events, build offers, manage inventory, and run reports. AXS has many power tools, but many are separate standalone tools were only designed for one venue or instance a time. In order to access multiple venues, clients, or regions, they require multiple logins. For new clients, this can be incredibly daunting with a lot of training required to feel comfortable using these tools.
As we began creating a new suite of web-based tools, we noticed the teams working on each tool were each slowly becoming siloed. We foresaw a similar problem happening again, fragmented tools, so we saw the need to create a more centralized framework the manage all the tools and features.
This project provided an opportunity to to look at these older tools with a fresh set of eyes, and asking the questions just because we did it before, did we have to do it the same way again?
In preparing for interviews, we collaborated with product and business analyists to create an interview protocol. Through white boarding exercises we identified questions, worked to remove bias and make questions more open ended, and ordered them in such a way to proceed from broad topics to more specific use cases.
- We interviewed our primary stakeholders and strategists, understanding their goals for the project. What wasn’t working well today, and what was working well today.
- We interviewed company Subject Matter Experts and Clients who use our current tools. These included client services, client implementations, sports clients, festival, and music club
We conducted competitive and comparative analysis looking at successful examples of Saas applications, ticket systems, and other b2b examples where users sort through a heavy amount of information and quickly filter down to what they need.
We job shadowed client services, watching them as they conducted their daily tasks. We focused on understanding their triage process, how requests came through, how they were prioritized, and which paths they took in the system to find the information they were looking for. This allowed us to identify personas, both onsite and offsite, with their behaviors, needs, and painpoints.
Going deeper, we conducted nomenclature workshops to understand the terms internal and external clients were using and were familiar with. We saw how different sized clients had different ways of describing their organzation, venues, staff, and customers.
Through high level sitemaps, user flows, and wireframes, we outlined the new metaphors we were proposing. We developed sitemap diagrams similar to a subway map to illustrate the most common pathways users were traveling. We highlighted what information users had onhand or in a task ticket when they entered the system, and how the indicated the path they would take. Keeping these paths front of mind, we worked to optimize these paths to get users to their destination quicker.
The current model was workflow centric. The user would need to select a flow or program before making their way to the intended task. We saw that in most cases, users were thinking more in an object-centric model because their tasks and tickets were focused on those objects (for example … update an order, find a customer) and in order to find information, users often would jump between workflows.
We proposed flipping the model to allow the user to find those objects first, and then show the features attached to those objects. Instead of saying I wanted to sell and then finding the event, we changed the model first finding the event, then choosing to sell a ticket.
We built an array of prototypes to show how the system would adapt to different types of users with different levels of permissions and entitlements. Through validation interviews, stakeholders and subject matter experts ran through these prototypes themselves. We ran through the common tasks, watching to see if these new flows made sense.