Enterprise Web App
How might we design for value over daily use?
Rockbot is a subscription background music service for businesses that also has an app for customers to request songs. The Rockbot background music dashboard web and native app is what customers use to set up and maintain their background music stream.
Rockbot's approach to managing music is more complicated than other services. Especially because owners, staff, and customers all have different ways to control the music at a business. As we built new features to control the music, staff & owners were spending more and more time in the app to manage the music stream. We focused on this outcome and continued to add features and updates as time in app increased accordingly.
In hindsight, this was probably the wrong approach. It turned out that our most engaged customers were the least satisfied and were quitting the service. Just because our customers were spending more time in the app to manage the music, didn't mean it was time well spent. How might we design for value over use?
Rockbot, 2017
The Problem
To design an enterprise version of the app while increasing the value of the core experience.
The team knew that it wasn't enough to build shiny, new features. We wanted to better understand real customer's business problems and build tools to solve them.
Our first problem was that the growing feature list of our tool suite was good at helping the sales team sell the product and sign more deals. But the complicated toolset was creating more problems for our customers than solving them.
The other problem was that the product team didn't have time to redesign the core tools. The current plan was to build new features on top of the core app that were designed for multi-location franchises and corporate chains. With more and more of these types of deals in the sales pipeline, this work took on new urgency.
At the very least, we needed new tools that admins could use to setup new locations and provision new accounts. Beyond that, we weren't sure where most corporate admins would want to draw the line between centralized oversight and local management.
Adding new features on top of tools that were already too complicated, would only make things worse for our core customers. The team was reluctant to rush out new features when the core experience was already a mess.
I thought it might be possible to improve the core app— designing for better outcomes— while building up new enterprise features at the same time. The team and CTO were on board with the idea, but we weren't sure where to start or whether we could figure it all out at the same time.
Scope: 8 weeks to redesign web app and native admin app for iOS and android.
Role: I led product design as an individual contributor.
Team: I worked as designer with a PM and 3 developers.
Type: mockups, prototyping, wireframes, motion design, design for behavior.
Tools: Sketch, Keynote, front end frameworks, InVision, Zeplin.
The Solution
To better balance central oversight and local control for all of our customers.
Enterprise customers would need new tools & permission settings so that admins for mutli-location chains could setup the right music settings and also allow for a modest amount of local control.
For instance— one of our enterprise customer leads had a requirement for volume controls. A central admin would set a default volume for a given location that could be programed to increase and decrease at obvious times such as peak lunch hour or closing time. At the same time there would be a web and native app for staff that allowed for temporary overrides to the volume in case the reality on the ground at that moment didn't match the assumptions during setup.
I thought this concept of complementary roles with clear areas of responsibility within the larger chains, might be useful for our core small & medium business customers as well. If we built a new UI that was more opinionated about the way it should be used, we might be able to better design for the behaviors that led to successful outcomes.
A tool for local volume overrides.
Planning
We set out to get a lot done in a short time, so I wanted to make sure we were well organized. In the first week, I huddled with the front end web developer to discuss web components. We decided that he would look into existing component libraries that would work with our technology stack. At the same time, on a parallel track— I would began to create a library of web components that we might need in pixels. These mockups would help document the team's understanding of the requirements we had for web components so we could better align on what we would need in an existing library. If we weren't able to find a good library at the end of the week, we could fallback to making our own components based on the mocks.
At the same time, I huddled with the CTO, a few engineers, and the sales team to get a better understanding of some of the new requirements our enterprise customers might have. For instance, we wanted admins for multi-location customers to be able to quickly provision accounts and configure music settings for new locations. In the second week— while finishing up the component library— I created wireframes and mocks for all of the new features we discussed.
Some of these new components for enterprise customers might help solve some of the big problems our current customers were facing. So I made a plan with the customer success team to begin sharing work in progress prototypes of what we were planning to build with our small business customers.
One of my ideas was to focus on temporary overrides— such as volumen control— in the native app and place setup & configuration options in the web app.
Discovery
I spent the first two weeks prototyping all of the key flows the team wanted to explore. After that, I wanted to support the team by checking some of the product assumptions I'd made about enterprise customer needs against reality. But it wasn't obvious how I might do this, we hadn't signed any large corporate accounts yet so there was no one to interview.
I reached out to my design mentors at Google Ventures to think about how to approach user testing or research for enterprise buyers. In consumer work, I had a good pipeline for people to come in and work with prototypes, but none of this would work for a CTO type.
In the end we decided to work with the sales team as a proxy for more direct research.They were speaking directly to new CTOs, CMOs, and franchise owners each week. During the third and fourth week I created demos of the prototype flows I was exploring and asked the sales team to share these videos with potential enterprise leads.
After that, I learned the sales team didn't use the website with these leads and would often send custom powerpoints pitch decks via email and would go over them with sales leads during the call. I reached out to the sales team to see if I could offer design help with their pitch decks. Normally, this work would be outside of my role... but it helped me get into a learning loop with the sales process and better understand the buyers we were designing the product for.
The demo videos of the prototypes were a big hit and helped sell the product. At the same time I got a better understanding— via the sales team— of the enterprise problem space and types of people who would be using these new tools. Some franchise owners & corporate admins spent time doing more hands-on, troubleshooting type work and visited a different location each day of the week. Others mostly delegated and wanted local control with just enough constraints to keep things running smoothly.
With our current small & medium business customers, my access to customer insights was naturally more direct. I already had a good understanding of the pain points, but I worked with the customer success team to set up open-ended interviews to better understand their workflows. One finding was that many managers used their mobile app during peak hours and used the desktop version of the web app in the office during off hours. I decided I wanted to double-down on our idea to build UIs that focused on specific interactions for differentiated roles, to include different contexts of use for the same user. I started wireframing and prototyping new flows to create a more seamless handoff to the desktop version to mobile. I also began to explore the idea optimizing the mobile app for quick fixes that were temporary overrides to core settings, while some of the more permanent and consequential changes could be done on a laptop after closing time.
This is a prototype of a simplified UI that was geared towards temporary overrides such as skipping the currently playing song.
Implementation
We decided to use a Material Design styled AngularJS framework because it had many of the components we wanted to use and we could easily skin out the color scheme to match the customers brand colors.
I prototyped some simple and constrained features that focused on doing a single thing well, such as— setting the energy level of a certain time of day, playlist override, tweaking the volume, or skipping a song. These tools were more remote control than dashboard. I wanted to reality check some of the tools against real users. At the same time, we were hopeful that some of our small & medium business customers would benefit from the simplified toolset. For both of these reasons, I set up customers interviews to review the prototypes.
It turned out that the customers we interviewed were eager to try out the new toolset, so I worked with the CTO to launch a beta program that allowed our small business customers access to the new corporate tools. Previously, we were focused on offering complete control over the music and we were eager to reality check this assumption. If these new tools, with many constraints appealed to our longtime customers, we would have a solution to both the problem of new features for multi-location chains and improving the toolset for our core customers.
Outcome
After shipping the enterprise toolset, the sales team quickly began signing many corporate chains and multi-location franchises. The company more than doubled the number of locations every month for the next few months. This group quickly became Rockbot's primary customer and— even today— the many thousands of Rockbot subscribers are overwhelmingly large corporate chains. To be fair, these customers had a clear understanding of what they wanted in a background music service and it was easy enough to build to these requirements.
The other important outcome was that the experiment to roll out new single-task, simplified tools were hugely popular with our core customers. Overall our customers were spending less time in app controlling the music, but were gave the service higher ratings and NPS scores in surveys. By separating out the UI for temporary playlist overrides and other ad-hoc solutions from more permanent and complicated system settings, we were able to design for all the right behaviors to help customers focus on better understanding problems and how to solve them. After we started offering limited trials, we rolled out the product across all venues within three weeks.
More Case Studies
