BevSpot Inventory

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.

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.

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.

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