Alex Turnwall
Case Study

Reducing cognitive load to speed task completion

Designing BevSpot’s Inventory Input

The Challenge

BevSpot’s inventory product was initially built to replace the existing process that most bars use: count your bottles, cases, and kegs—and keep track with pen and paper (or a spreadsheet) as you go.

We use the count data in conjunction with purchase and sales data to make recommendations for improving business outcomes. Accurate counts means better recommendations.

Our 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!

The message was clear: the business insights the software provided were valuable, but the inventory count itself wasn’t a great experience.

If we were going to improve data accuracy and speed adoption 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.

Goal

Reduce average inventory count times for a better experience and extra customer value perception

User Segment

Bartenders and bar managers (with a focus on programs with the greatest sitting inventory by unit)

Role

UI design, UX research

Company

BevSpot makes software for bars and restaurants to streamline their operations and improve their bottom line. I’ve served as Chief Design Officer there since 2015.

bevspot.com

Quick background for non-industry folks:
why even take inventory?

If you've never worked in a bar or restaurant, you may be wondering why taking inventory is important. After all, you should always know how much inventory you have on hand by simply looking at how much you ordered and subtracting how much you sold, right?

Wrong. According to industry-wide estimates, 20% of all product in U.S. bars is lost before it ever reaches the customer.

Think about how crazy that is. Before you even have a chance, you're losing 20% of potential earnings. Why?

Well, a variety of factors: broken bottles, overpouring, giveaways, straight up theft. Generally, all bar operators expect a certain amount of loss, or variance—but the savvy ones track it closely.

Loss is primarily why it's so important for bars, specifically, to take inventory on a regular basis. BevSpot helps them track this, and other metrics, and helps them make more informed purchase decisions based on it.

Now you know. Carry on.

The Process

Customer interviews / field observation

Since there weren’t many specific asks from users (we just knew we had to make the UI better, somehow), we needed to do some exploratoration. So, we started doing field observations and interviews: spending time behind the bar, in basement storage areas, and in walk-in coolers to see exactly what was going on.

This generated more questions than answers…

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.

Really, the ideal solution would be to eliminate the need for counting entirely, building a concept of “perpetual inventory”. Unfortunately, that wasn’t a realistic path to explore (yet) for technical and business reasons. (Still, we filed away some ideas for future projects.)

So, if we were going to fix this problem for users right now, we needed to focus on real pain points users were experiencing during the count and address them.

We started by organizing the issues we observed and ended up with three main buckets:

Pain points

What’s so hard about taking inventory right now?
What makes it so time-consuming?

Physical Space
  • moving items physically in order to see hidden items
  • getting to/viewing hard-to-see items
  • space in bars is at a premium: storage areas can be separated, sometimes even in a different building
Organization
  • matching the item in the bar with your list in the app, or vice-versa:
  • finding the item in the bar that you're viewing in the app
  • coming across “random” out-of-place items and having to find your count in the app
  • overlap and miscommunication between multiple employees
Cognitive load
  • doing the math of combining single units with multiple cases of units
  • doing the math of adding partially-full bottles or kegs
  • deciding whether to count in bottle or case units
  • having to recall how many of an item comes in a specific case

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, so we could focus on the highest-impact items.

The answer, based on our observations, was very surprising: simple math*. Why?


Consider a few user actions observed while counting:

  • taking time to switch from our app, over to a calculator app, then back
  • walking around with a clipboard or notepad to scrawl notes on, just to take a tally or do simple math, although the count was recorded in the app
  • literally walking around with a physical calculator in hand in addition to their phone or tablet
  • 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), focing them to find and/or start over for that item
  • using a laptop just to have BevSpot open on a browser window with a calculator next to it

This constant context switching took a lot of time when repeated over and over.

*Getting to this outcome is one of those things that is painfully obvious during a field visit, but can be completely overlooked in an interview for a few reasons:

  1. users might not think to mention the problem because it’s external—not a problem with your product, and
  2. the user might actually be embarrassed to admit that simple math is taking them time.

So, get out there into the real world!

With so many numbers floating around in their heads, and so many specifics to remember, 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.

As an aside, we didn't lose track of the organization or physical space issues, but we decided to address those as separate streams of work.


Design, iteration

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.

Note! this project is from early 2015—our product UI has been updated significantly since then. Check out a later case study to see the evolution (and don't judge too much).

Before:

Input groups had simple plus and minus buttons to increment whole units, and you could click into the input field in the middle of the buttons to input via typing.

On some mobile devices, this was problematic because the native numeric keyboard didn’t allow decimals.

You could switch counting between cases and bottles, but you couldn’t mix the two (meaning you had to do mental math when combining loose bottles and cases).

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.

You can work out simple interaction issues quickly with pencil and paper*, so you don’t get bogged down moving stuff around in the next step. 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* to try and understand if the concepts made sense. 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 in the office 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 features didn't resonate with our testers: they were confusing concepts. 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.

*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 built-out 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.

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**, 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.

**Just for testing purposes.  ; )

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.

Note the blue masking tape on some of the bottles representing our "fill lines". We wanted to simulate the experience at bars: full bottles, partial bottles, cases, and every different combination therein.

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 blind user tests in the office.


Usability testing

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 it as a private beta to a handful of customers so we could test with them.

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.

Once users get to the top of a bottle, we alert them to save a full bottle.

As users find misplaced items, they might need to circle back to a previously counted item and add another instance. This caused confusion about whether or not the new number was saved or should override a prior number, so we needed to design better "saving" logic and a new "save" view.


The Outcome

Customer Wins

Up to 90% faster input times

Faster self-directed user adoption

This UI resonated as a key differentiator of the product, a win for marketing

Users loved the feature ↓

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
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
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

Like what you see?

Maybe we’d work well together …