BevSpot is the leading back-of-house operations SaaS product for Bars and Restaurants. I was the first designer on the team, helping grow the platform from zero to thousands of B2B customers over about three years.
Inventory was a part of the suite* from the beginning, but it grew in scope and complexity quickly. From its roots as basic spreadsheet replacement, it evolved into to a handy mobile counting app that automatically analyzes usage patterns to make cost-saving recommendations and help customers run a tighter ship.
While I led overall UX and brand design at the company, this case study focuses specifically on how the Inventory product morphed over subsequent iterations. This customer quote pretty much sums it up:
“I would start inventory around noon on a Sunday and finish everything, including inventory and ordering, at around two a.m… Now, with BevSpot, it takes me three hours for everything, tops.” Dan, Bar Manager at an urban restaurant
From 14 hours to 3: that’s 78% faster, and a really noticable amount of time back in Dan's life every week. It's no wonder Inventory made loyal customers (once we got it right).
But it didn't start that way. We worked very closely—literally** and figuratively—with customers like Dan to make it happen. Read on to find out how we did it.
Role & team
My Role: I served as the Chief Design Officer at BevSpot from 2015-18, overseeing all UX, product, and brand design. When this work started in the MVP phase, I was the sole designer. By the time version 3 launched, the product design team was seven strong, including myself.
The Team: Thanks to a great design team, who each had a hand in something here: Stephanie Lee, Matt Russo, Cara McGrath, Cristina Silva, Zack Labadie, and Muigai Unaka. Special thanks to Maggie Crowley, Director of Product, who was instrumental in shepherding version 3 out the door and kept the huge product-wide UI redesign that it launched with on track. More thanks to the rest of the BevSpot crew, too many to name.
This is where it all started. The first version was really an MVP that allowed us to test with customers and raise a round of capital to kickstart the business. The MVP phase didn't last very long, as more complex customers demanded a better product.
The Business Problem
The software suite overall was seeing rapid adoption in an underserved market, and was getting generally positive feedback. Still, some customers complained that the inventory counting tool wasn’t saving them time—in fact it took longer!
Worse still, some customers actully printed out the spreadsheet export from our software, used the old pen and paper method, and then manually entered the numbers into the system again—exactly the process we were trying to replace! This is the worst insult a designer could receive. As soon as I heard that the first time, I was determined to fix it.
The message was clear: the business insights the software provided were valuable, but the inventory counting wasn't cutting it.
If we were going to succeed beyond an early-adopter market, we needed to ensure the actual counting experience wasn't just okay: customers needed to clearly prefer taking inventory in BevSpot over any other methods.
Inventory in a nutshell
BevSpot’s inventory product was built to replace the age-old process that most bars use: count your bottles, cases, and kegs—and keep track with pen and paper as you go.
These count numbers are used in conjunction with purchase and sales data to make recommendations for improving business outcomes. Accurate counts means better recommendations.
Quick background for non-F&B industry folks:
Why bother taking inventory?
We needed to fix inventory: our mandate was to make BevSpot the obviously preferred method of taking inventory counts, period. Except, we were pretty clueless as to what that meant. We needed to do some digging.
- End users—specifically bar managers—don't like taking inventory counts in our product, preferring pen and paper.
- GMs, operations managers, and owners wanted bar managers to use our tool because accurate inventory counts were the basis for many of the important financial insights we gave them with other parts of the suite. But, since the counting UX was bad, bar managers were advocating for other methods, sometimes competing software. We needed to provide tools that all parties preferred.
- Counting with pen and paper, a spreadsheet, or another app and then transferring the data was counter-productive and a bad UX, but it was also error-prone.
- By giving the "counters" a specialized interface separate from the view that managers use, we could make counting faster and less error-prone.
- (That's pretty much it—we were pretty clueless at the start).
When you don't really have good assumptions for how to improve something, where do you start? What questions do you even ask? Sometimes it's not enough to simply talk to users... you really have to get into their shoes.
Since there weren’t many specific asks or ideas from users, we needed to do some exploration. So, we started doing field observations and actually tried to “become a bar manager for a day”: spending time behind the bar, in basement storage areas, and in walk-in coolers to see exactly what was going on.
We spent a few weeks going from bar to bar at our local customers (not a terrible job) and helped them actually do their job. We weren't just observing, we volunteered to actually help them take inventory—and boy, what an eye-opening experience.
I should note that I previously worked in a restaurant as a cook, and I did a brief summer stint as a bar-back, so I thought I knew what I was getting into. I was very wrong. The variety of bar and restaurant types, sizes, building layouts, menus and more was dizzying—every one uniquely problematic for taking inventory.
The process generated more questions than answers…
After a few weeks, we had a bunch of photos boards with annotations that looked like this (below), and we got to work.
Synthesis and scoping
After many visits and pages of notes, a few trends became painfully obvious: counting hundreds of items spread across storage areas in a crowded bar or restaurant is simply time consuming, regardless of the tech you throw at it.
We started by organizing the issues we observed and ended up with three main buckets:
Lots of areas for improvement, but what should we focus on?
Of those pain points, we wanted to know which were the most time-consuming. We headed back out to observe a bar manager take another count, this time keeping track keep track of the time that it cost him when encountering any of the issues.
The answer would have been very surprising had we not spent so much time observing users and actually doing it ourselves: simple math.
Why? Consider some observations we made while counting:
- some users (including myself) took the time to switch from our app, over to a calculator app, then back
- some users walked around with a clipboard or notepad to scrawl notes on, just to take a tally or do simple math, even though the final count was recorded in the app
- some users literally walked around with a physical calculator in hand in addition to their phone or tablet
- some users preferred a laptop—just to have BevSpot open on a browser window with a calculator next to it—even though the app was optimized for mobile and a laptop was unwieldy
- losing track of the count due to leaving the context of the app for any of the reasons above, especially when counting mixed units (both bottles and cases), sometimes resulted in confusion and having to start over for that item
This constant context switching took a lot of time when repeated over and over.
With so many numbers floating around in their heads, it was faster for people to unconsciously use a calculator or notepad to enter numbers into—not necessarily to do math—but as a means of keeping a tally of their progress.
Now we had our primary design hypothesis to focus on: introducing calculation and/or tally to the input.
Still, there were many factors to consider: where would the input live? Did it need to be on the page at all times? Did the existing input work well for any use cases?
We reviewed what we had to see if there was anything currently working well, and started to define some project parameters (because you just can't fix everything all at once.)
We decided to focus specifically on making some sort of popout for the input field and leave the rest of the page unchanged, for now, in order to focus our attention on making the best input experience possible, and to isolate our understanding of performance improvements from the input vs. the whole page layout.
Since inventory counts generally happen while moving around an entire bar/restaurant, we felt it was important to optimize for mobile devices, so we started with a mobile-first approach to the design.
The limitations of mobile devices (screen real-estate, click target size) can sometimes prove inspirational: since you can’t jam everything into one screen, you often have to pop open a completely new view. That’s where we started.
I like to work out simple interaction issues quickly with pencil and paper, so I don’t get bogged down pixel-pushing. I started sketching out some wild ideas to try and represent how we’d seen goods stored in physical locations.
(The irony of advocating for a pen-and-paper approach to designing a replacement for a pen-and-paper approach is not lost on me.)
From there you can translate your ideas into wireframes that are simple enough to iterate on and generate quickly, but detailed enough to obviously represent your idea. In this state of fidelity, we map out the different use cases we were trying to solve for.
Once we iterate through the interaction challenges in wireframe stage, we take the best outcomes and flesh out the interface to compliment any existing patterns and to emphasize actions.
After a few visual iterations to the UI, we started to apply the styles to our wireframe templates and prep the static files for use in clickable prototypes.
Prototyping round 1: idea validation
To do the fastest testing we could, we made simple clickable prototypes of the interface to pass around the office—just to see if the concepts made sense to fresh eyes.
Of course, the danger with testing on people that (a) aren't your real users, and (b) are already familiar with your product is bias. But, there's a tradeoff: speed. Since we had every intention to thoroughly test with real users once we had a more fully-formed prototype, we decided to do some quick idea validation this way. It can be really useful for designers to get out of their own minds with "friends and family" research, as long as you know the potential pitfalls.
Because we were trying to test very specific use cases, and because the basic prototypes didn't actually do math yet, we decided to test with a script like this:
- “How would you count a half a bottle of Jameson?”
- “How about 4 bottles of Apothic Red?”
- “Now count your Jack Daniel's: pretend you have two tenths of a bottle in one well, three tenths of a bottle in another well, and an unopened bottle behind the bar.”
- “How about Corona? You have two full cases under the bar, plus an additional 15 bottles in the icebox.”
We asked the participants to click on the prototype, but describe what they were thinking. When they hit a dead end (very easy to do with this prototype), we asked:
“what would you expect to be able to do?”
A few of the crazier concepts (a 3D space of stacked boxes!) didn’t resonate with our testers—they were just confusing. Others did make sense, but the UI wasn't quite right, so it was hard to use. We iterated through the designs, each time testing the prototypes with the same users for feedback, and with new users for a fresh eye and to avoid recency bias.
After a few visual iterations to the UI, we had a spec that we felt we could pass along to engineering to build the "beta" prototype that we would test internally.
Prototyping round 2: working out the kinks
Armed with a fully-functioning (albeit rough around the edges) version of the tool working on a test branch, we went back to testing with co-workers.
We built a bar in the office (just for "testing" purposes—wink, wink), so we could have lots of people test different use cases. This time, there were no guided prompts: we just told people to take a full count of the “inventory” on hand.
Prototype testing plan:
The design team followed our testers around to our simulated “storage areas” to observe how they chose to use the new tool.
Here, a BevSpotter is testing the prototype on a laptop, but we also tested on phones and tablets.
Pictured is just one of many "storage areas"—we had more scattered throughout the office to simulate switching contexts from the bar to the basement storage rooms.
The testing in the office generated some great feedback, and helped to identify a few interaction issues. At this point, the feedback was mostly about specific interaction logic, so we were able to rapidly iterate directly in code.
After a few more rounds of design and engineering iteration, we had a beta release candidate that we felt passed new user tests in the office.
The real pain isn't counting one item—it's repeating a count over and over.
Little pains compound into major frustrations when you encounter them hundreds of times.
So to get realistic user feedback, we knew we needed to build and test the real thing (plus, asking users to take a lengthy count in a prototype was out of the question). To test, we released a private beta to a handful of customers.
So, we headed back out to visit customers: some were the same that we'd done our initial user studies with, some were brand new users.
We observed, and spent hours actually helping customers take counts ourselves.
This real-world testing helped us identify some additional improvements we missed in our prototyping phase, due to the sheer size and time dedication required in some of the counts. We also identified some performance concerns that the engineering team could address in parallel.
The Outcome: Version 2.0 Launch
The end result was a totally revamped counting experience that complimented the power of the existing app, and it was a big hit with customers.
- Average of 70% faster input times, with some locations seeing as much as 90% improvement.
- Faster self-directed user adoption, meaning less time with customer support
- The UI resonated as a key differentiator of the product, a win for marketing
Plus, users loved the feature ↓
“Does BevSpot save me money?*
I don’t even give a f*@$! My staff is SO much happier with the process. They’re spending less time counting bottles and more time with guests—and that’s the most important thing they can be doing.” Mike, partner at an urban taqueria and cocktail bar
“BevSpot has certainly cut down my inventory time, and it’s made my life a whole lot easier. We’re just really excited to have it.” Gary, General Manager at a suburban wine bar
Learning from a year's worth of usage data, feature requests, and our other products.
Rome wasn't built in a day, and the job is never done, as they say. We vastly improved the counting experience in v2, but now that we got customers so involved, we kept hearing from them... so we listened.
To be continued …
Whew, that sure was a lot of reading, thanks for sticking with me.
My design process is iterative, and I'm still adding to this story.
Hopefully you got the gist of my process from what's here already.
No? Want to know what happens next?
Contact me to learn more in the meantime.