Skip to Content

BinWise Part 2 (Inventory Redesign)

BinWise Product Design series

Part 1: User Research, Personas, and Pattern Library
Part 2: Inventory Redesign
Part 3: Scansheet Redesign
Part 4: Aspirational Designs

In Part 1 I discussed the work I’ve done at BinWise to move us toward a human-centered design process – through user research, personas, and the development of the pattern library – in order to create a more successful product for our customers. In this part I’ll talk about how that work drove the redesign of one of core areas of the app.

Some positive feedback we’ve received in testing this new inventory include:

  • “Much cleaner, faster, and takes out unnecessary things you had to do and look at before”
  • “It worked really well. It was very intuitive and simple.”
  • “the visual design seems very clean”

Inventory Redesign

The Old System

Restaurants count inventory in order to track what they’re using over time and keep control of their items. Most count inventory 1x/month, either by scanning barcodes or keeping an excel file and manually counting items.  The items are uploaded into the app through the Inventory section. The company has been needing a redesign of this system for a while, because the current system is clunky, prone to error, and often leaves the users confused as to what they need to do.

The old process looked like this (click into slideshow for descriptions):

Major Problem Areas

Long and complicated process
Inventory counting can feel like it takes forever, and it typically happens late at night after a restaurant has closed (I’ve talked to people who have to stay until 2 or 3am), or very early in the morning. No one really looks forward to counting inventory. Then when they come to the app, they are presented with this overly complicated and confusing process. This causes them a lot of frustration at a time where they are already stressed out and almost at the finish line.
No Guidance
Most restaurants physically count inventory 1x/month (some more, some less). Since they infrequently use this UI, and system doesn’t do a great job of guiding the user through this task, they forget how to do it each month which causes stress for them and a high volume of support tickets for us.
Unhelpful Errors (or none at all)
The system does not always present errors if something goes wrong; or if it does, they are generic and unhelpful. The system does not also help them sort out obvious mistakes with their counts. For example, sometimes the system thinks a quantity is negative. It’s physically impossible to have a negative amount of an item – what this typically means is the sale for that item came in wrong and it needs fixed.

Goals of the New Design

The analysis from the user research and the visual design above fed into overarching goals for a new inventory system: guide the user, present information in a clear way, don’t ask for confirmations but instead provide an undo, and enable users to fix their mistakes. In addition to knowing that going in, we audited the old system and talked with current customers and our customer support team to determine problems specific to that system. It was important to not view as a superficial reskinning – I spent a lot of time talking to people and asking questions to figure out the root of how the customer really needed this feature to do for them, and as a result we implemented some major restructuring of the entire system.

Streamline the Process
The old system took 7 steps. At first I was able to condense this into 5 steps… then through some team testing and user testing, I was able to get it down to a 3 step process.
Provide Guidance
Provide clear instructions, guide the user, provide more context with where they are in the process and what they will do next. Now, there are instructions on every page.  Once you open the wizard there is a progress bar that reinforces what step the user is on, and what is remaining.
The System Should Help
The point of using a system like this is to help users manage their program better, including helping you catch errors. For example, sometimes an item count will show a negative number – it’s impossible to have a negative number of an item so that usually means a sale was captured wrong or a piece of data was entered wrong somewhere along the way. The system knows things like this, and we want to utilize this better to help users catch errors earlier.

While the goal is to not have the user trigger ANY error, something might still get through so we’ve focused close attention to error handling. All errors must tell the user what went wrong and what actions they can take to fix it. It’s important that they can do this when it’s midnight and all they want to do is finish their inventory, instead of filing a support ticket and then waiting until they get a response the next day to finish it.

Error examples

Error examples

Video Walkthrough of the redesigned UI

Here is a walkthrough of the nearly finished UI (set to HD for clearer text):

Design development

Communicating Goals
Wireframes & Flows
Prototypes & Testing Feedback
Visual Development
Design Comps
Communicating the Development Process

Communicating Goals

Goals were coalesced into business goals (what the company needs this to do) and user goals (what the user needs this to do). During the wireframe development, I mapped each goal to each section of the UI. This helped make sure the interface was driven by the established goals – if there was a piece of UI that *didn’t* have a goal attached to it we evaluated why it was there – maybe there was a glaring goal we had missed, or maybe that UI was extraneous and should be nixed.

An example goal map is below:

Business & user goals example

(In hindsight these are too many goals – if I were doing this again I would pare these down to just a couple to focus this more.)

Wireframes & Flows

Wireframe examples below are available for download (anything shaded pink is click-able)

User flow #1 (one of the very early passes)

User flow #2 (revision after some team testing and user testing)

Wireframe examples:

Prototypes & Testing Feedback

I worked with the front-end developer to prototype some of our more promising flows in the browser. We testing and iterated on that internally, then user tested either in person or via screenshare.

Screenshots from one of the prototypes:

The testers responded really well to this prototype, and we got some great feedback that helped make the experience better, such as…

  • We learned a number of users don’t use our barcode scanner, but instead count item manually and keep them in a spreadsheet. In the old system they’d have to enter those one by one. The new system we did plan for a file import, but since it was more widely used than we thought we put more focus on supporting that.
  • It would be helpful for users to see inventory totals broken down by category. A wine director knows how much wine they have and needs to know the percentage of their inventory that is in each category (counts and dollars). If those totals look about where they expect them to be, they’ll know they didn’t miss anything big.
  • Some original terminology was confusing.  For example, we changed “export” to “download”.

Some positive feedback included…

  • “Very understandable”
  • “Super simple”
  • “Much cleaner, faster, and takes out unnecessary things you had to do and look at before”
  • “Visual design seems very clean”
  • They were excited about the new features such as the alerts system and the ability to verify the contents of a scan file before loading it in – they thought that would help them catch errors quicker.
  • One small thing to me but I discovered was huge to them: in the old UI list of inventory items, there was no way to search for a specific item! The items were alphabetized and the UI was paginated by letter. So if I wanted to check an item that started with the letter M, I had to click on that letter, then navigate through all the pages of items that started with M in order to find my item.  Crazy. In the new UI, they can type in the search bar by any item parameter (not just the name) they want to search for (maybe the price, the barcode number, the quantity…), and the table will live update with their results.

Visual development

Visual development on the inventory project occurred at the same time as the pattern library, so some of this style development below informed the patterns and vice versa. Working on both at the same time really helped me to see the patterns in context as make adjustments, rather than trying to develop all the patterns first and then wind up with them not working together as well as you’d hope.

Some progress shots:

Design Comps

Everything is getting a visual overhaul, but one area that will really benefit from this is the reporting and table interfaces. Current reports don’t use a singular framework, but take for example the variance report:

Old Inventory - step 5 - variance

I wanted the new design to clean up the information presentation and de-clutter the UI, and strip out info that is not relevant to the user. For example, several columns above just have “0.00” values – these columns pull data from old, legacy areas of the site that most restaurants don’t touch. Clutter just makes it harder to parse the information they DO need.

New design:

Variance report (1)

I’ve created more padding around the text, more white space to focus attention, used iconography where possible to make it easier to take in information at a glance (such as whether an item is on or off a wine list), and used color to make the high variances and low variances obvious. I’ve also stripped out the unused columns to eliminate clutter.

User response to the new report design: “The variance report is very clear, much better than the old one, and it will be understandable to a newer person.”

An Alerts system was planned to further help the user catch errors earlier, by making checks behind the scenes and displaying areas that possibly need attention. This has been deferred, but the designs are below. Every restaurant has unique needs, so alerts were planned be configurable by the account so that users can set parameters that will provide the most helpful info to their situation.


User configurable alerts
Below is a gallery of more design comps. These are the ‘final’ versions out of Illustrator – once a feature or pattern goes into development, I make refinements there.

Communicating the Development Process

A big part of my job is communicating the design and the process to those outside of the development team. It can be challenging to explain to those outside of this process that we would build a complex design like this first by focusing on the core components and flow, and then by adding in additional functionality and details from there. After unsuccessfully trying to explain this process just with words, I made a presentation where I visually mocked up how we might implement Inventory. Showing it visually ended up being much more effective:

Mockup to communicate the inventory development process

This series is continued in Part 3, in which I talk about a smaller redesign project worked on in parallel with inventory – how users set up their barcodes to print and scan their items.