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…
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:
What’s so hard about taking inventory right now?
What makes it so time-consuming?
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:
This constant context switching took a lot of time when repeated over and over.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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
Maybe we’d work well together …