VenueNext integrates services like wayfinding, POS and ticketing to transform how guests experience venues, from arenas and concert halls to hotels and hospitals.
At VenueNext, I actively sought to uncover problems that would negatively affect our product in the long term. In order to do that, I needed to look holistically at VenueNext, its operations, and its business goals. Canopy stuck out to me as overlooked yet extremely vital, like reliable wi-fi. I took initiative to investigate the situation.
Interviews with employees, customers, and stakeholders validated my suspicions and I took on the role of the project’s sole designer. Based on learnings from my interviews, my next steps were clear. I conducted a comprehensive product audit which led me to restructure the product’s broken information architecture and introduce logical and scalable UX patterns. Canopy power users and casual user tests guided me in making informed product decisions. From there I defined a more appropriate visual design system to enhance usability and solidify VenueNext brand integrity.
VenueNext employees use Canopy to set up, maintain, and test systems, while venue managers use it to customize and control their organization. The redesign aimed to increase usability for both user groups. The reorganization led to discovery and removal of obsolete features and streamlining of others.
User interviews and observations of operations revealed that despite how powerful Canopy was, the customers didn’t know how to use it. This was burdensome for VenueNext employees because the job fell to them to not only build the tool, but also manage it. As a startup, this was unsustainable. Further investigation showed the issue boiled down to the following:
A content audit revealed a whopping 118 unique pages, many of which were either forgotten or whose purpose was forgotten.
Features were built based on the convenience of engineering timelines, which meant usability took a huge hit.
Integrating multiple services from various third parties left our platform spread thin across disparate goals.
The interviews and product audit made it clear to me that the entire product needed to be re-architected. While unique customer needs were taken into account, decisions were made based on goals common across all customers for purposes of scalability.
My approach was simple but comprehensive. The audit revealed that Canopy consisted of many objects, each with actionable or editable attributes. Having all the objects at a surface level was unsustainable, so to identify a hierarchy, I conducted a card sorting exercise with Canopy power users and customers.
From there it was a matter of taking each object and attribute and putting it into its rightful category. For every object and attribute, I carefully considered, “Do we need this? Why?” and if it proved any less than necessary I would either discard it or take it apart and reallocate its pieces. Canopy took on a very modular form with this exercise. The product became lists of objects, each with a bundle of corresponding attributes that were grouped by category.
This form embodied itself into listings pages and details pages. The listings pages tabularized all the objects of a single type. The details pages contained all the attributes pertaining to an object, grouped by subcategory.
With Canopy’s reputation of slow load times, confusing navigation, and “dangerous” buttons, users were hesitant to dive deep. At the same time, they also needed to access attributes over many objects. While the new architecture would still require users to navigate to each object’s details page to change a single attribute, to reduce the anxiety and tedium associated with the task, I defined a new UX pattern. By selecting an object from a table, users could preview its associated attributes.
With these updates, Canopy became increasingly reliant on tables. Existing layouts were riddled with hard-to-find data in tables that forced horizontal scrolling, a major pain point for our majority Internet Explorer users. To address runoff data and horizontal scrolling, I introduced a filtering system allowing users to hide and show columns with the data they want.
To address hard-to-find data, I decided to go with a “smart” table pattern. While global search would be available, each column could be filtered and sorted based on the type of data it hosts.
I wanted Canopy to be known as a low-friction product, a complete 180 from its previous reputation. To achieve this, I refreshed the visual design and laid out a basic design system. Working in parallel with another enterprise tool, App Builder, I aligned the two visual systems to establish brand consistency.
The existing typeface, Proxima Nova, was inappropriate for displaying large amounts of tabular data. With it’s geometric and modern influences, the typeface is wide with low scorings in legibility, making it a weak candidate for body text. I replaced it with Google Fonts Open Sans, a versatile, humanist sans-serif.
Canopy used a bright orange as its accent color and color for signifiers. By using a relatively low contrast color for all buttons and links, it was difficult to identify what on a page was important. Maintaining the previous blue-orange color scheme for brand consistency, I introduced more blue tints, increase the contrast of accent orange, and limited the use of the orange.
Additionally, rather than using the accent orange as the sole call-to-action color, a new set of more subtle buttons were introduced.
A complete Canopy redesign release was not feasible given our limited resources. Our team also ran into the engineering bottleneck of needing to switch our project from a Ruby on Rails app to a React project. We decided to divide our releases into smaller, more manageable segments. Using our analytics data, we prioritized features that showed higher traffic. Releases first focused on re-organization of the tool, which required a back end re-architecture. Each additional release will introduce some visual renewal.