January 2016- present
Blane Cordes (Manager, Front End Web)
Ryan Ploetz (Engineer, Full Stack)
Bryan Rehbein (Engineer, Back End)
Chris Mihalyi (Engineer, Front End)
VenueNext integrates services like wayfinding, POS and ticketing to transform how guests experience venues, from arenas and concert halls to hotels and hospitals.
I was hired to design App Builder, a WYSIWYG web tool. By harnessing the internal front-end mobile framework, App Builder could control the UI of an application based on time and location. To understand the system, I self-taught myself and documented the front-end framework (kickstarting a documentation culture and practice at my company). I started the project with research, gaining firsthand experience of customer pain points. My research helped me to define user groups and use cases, from which I outlined a preliminary feature set. I used storyboards and guerilla user testing to iterate on the experience flow. When the product solidified, I drafted plans for scaling the product and defined a visual system.
For each mobile app, App Builder keeps track of a series of Looks. A Look is a UI instance that corresponds to a specific time and/or location. In each Look, a venue manager can choose from a library of pre-made UI building blocks, called widgets, to put in their application. Each widget comes with unique customization options like text display or color. Venue managers can also delete and rearrange widgets. Once happy with their changes, a client can preview on a mobile device, save, or publish their Look.
App Builder is used both internally by VenueNext employees and externally by venue managers. To understand the full picture, I temporarily took on various roles: learning the front-end framework, maintaining our mobile front-end, and working with the client services team to understand their pain points. Based on learnings, App Builder was designed with these goals in mind:
Each client has their own set of visual needs. Clients should feel ownership of their applications and be able to make changes on their own.
Manually editing the front-end was prone to human error and inefficiency. Changes were not tracked, making error correction difficult.
With a growing number of clients, VenueNext did not have the resources to manage every client’s app UI.
With no defined release process, clients hear of new features only when told by their respective liaison.
I worked together with a specialized team of engineers to define product requirements. As we had little insight on company priorities, overarching timelines, and stakeholder goals, we designed blue sky. We iterated through high level product flows, hand sketches, low fidelity wireframes, high fidelity wireframes and visual designs, all while conducting guerilla user testing to gather feedback for iterations.
Our goal was to build a visual representation of our front end framework. The task at hand could be equated to building a tool that outputs HTML/CSS based off some visual composition. Realizing that this type of project was both a technical overcommitment and that our clients didn’t necessarily have need for such a robust tool, we knew we needed to prioritize our releases.
We decided our first release would allow limited customization of our most basic widgets with real-time rendering of the mobile UI. While the complexity of the framework set constraints on the design, the team believed that defining a single visual system would help set some precedence.
After 9 months of working on the tool, the company shifted from an agency approach to a product-as-a-platform approach that was more scalable and sustainable. Equipped with a new product team, the company had a renewed and immediate focus on App Builder.
The team needed to make serious adjustments and simplifications to meet an earlier release date. We had to cut the tool down to the bare bones: what does it need to just be useful? We removed the real-time rendering, replacing it with representational UI, and removed widgets, replacing it with widget templates. Widget templates were essentially sets of widgets with a very constrained set of customizable options. While the idea of widget templates existed in the original product design, it was now put at the forefront.
Since VenueNext lacked both a strong brand voice and an established visual system, the design of this enterprise tool began on a blank slate. Working in parallel with another enterprise tool, Canopy, I aligned the two visual systems to establish brand consistency.
Given the complexity of the tool, it was important to make the visuals clean and simple. I decided to use a dark UI over a light UI to give the app the “sandbox feeling” that is often associated with customization focused web tools.
To resolve the dichotomy between actions that can be performed on App Builder versus actions that can be performed on the mobile app, I devised a color hierarchy. In the example of buttons, while primary and secondary buttons have similar styling, blue indicate actions performed on App Builder, while green indicated actions performed on the venue’s app.
For a visual affirmation of brand consistency, I designed a set of line icons. By using a similar motif, I could establish a relationship between different widgets, a concept unfamiliar to our users.
A beta version of App Builder has been released to a few customers. As we onboard our customers and gather data about how they are using the tool, we will continue to iterate and improve the product. We plan for monthly releases of features based on customer need.