Building A Web App To Track Inventory, Wastage and Analytics For Breweries— UI/UX Case Study

A complete dashboard experience for breweries to track their inventory and analyze consumption patterns of their beers.

TLDR;

This a case study of a web application that I designed from scratch for a client called “BeerTech.”

Overview

BeerTech is a dashboard experience offered to breweries as a service that provides crucial information like inventory details, consumption analysis, and patterns to the brewers. This data is collected and presented onto the dashboard by placing a food-grade tracker in the distribution lines of beers.

Before designing the web app, the client used to provide these huge amounts of data using spreadsheets to breweries and there was a huge loss of data lost in translation, and also it wasn’t the easiest way to consume and digest all that data.

So, the client approached me to design the dashboard interface for the service and there began my journey.

FYI, this is the first ever product design project I’ve ever worked on — this project acted as my transitional bridge from graphic design to product design.

Up until this point, I had been practicing graphic design for about a couple of years professionally and this project is the second company of one of my former clients. He trusted me with this project even though I’ve never worked on product design before based on the trust I had established through my previous projects with him.

Now, the real challenge began — understanding how to design a web app, how to prioritize functionality over form, how to pick the right typeface, how to design scalable and reusable components, and the biggest challenge of them all:

How do I design a dashboard that is completely filled with data and graphs in a way that it’s easy to consume and digest for the user?

Understanding the service

The scariest part about designing the whole dashboard is figuring out a starting point to work. What do I need to do first? What’s the process? Is there a checklist that I need to fulfill? I had no idea so I started learning about various design processes for product design and created my own flow that works best for me.

My role and design process

• Understanding everything that the service has to offer.
• Understanding the user.
• Understanding different actions that the user would want to accomplish using the web app based on priority.
• Creating a site map and establishing a clear information architecture.
• Creating roughly sketched wireframes to visually plan the whole interface.
• Researching to understand if there are products like this that exist and what are some of the best-case practices.
• Designing the entire interface and presenting it to the client for feedback.
• Working on the changes and testing the design with some users.
• Working with the developer to bring this application to life exactly as it was designed.

Research

Diving deep into the details

The first thing I did as soon as I got started with this project was to schedule an in-person meeting with the founder and understood every single thing there is to know about the service.

“Why is this service necessary?”

“How will this service help breweries?”

“What is the alternative for this service?

“How much time and money does this save for our user?

“How much value does this add to our user’s business?”

After understanding everything about the value that the service provides and its by-products I dove deep into questions about the content on the dashboard.

Even though my client had a rough plan of what needed to go on to which page and an overall structure to the dashboard, we started on a blank canvas. First, we put down the most important things that needed to be on the dashboard, then we added some good-to-haves, then added more things that enrich the already existing experience of being a brewer and owning a brewery.

After completely understanding the service we then moved on to understand the user in-depth.

Understanding the user

At this point, I wasn’t aware of the need to create a user persona or even how to create one but one thing I knew I had to do for sure, to understand the user was to create an archetype of different types of users and understanding their needs and challenges. So I started with the same.

Even though there are different types of users, the use cases for all the users are pretty much the same so I designed the entire experience keeping just this one user archetype in mind.

Information Architecture

Once I had a clear understanding of the ideal user, I spent sometime to plan and put down everything that has to be presented on the dashboard.

User Flows

Once I had the entire information architecture planned out I worked on understanding all the different use cases and flows.

The most common use cases are pretty straight forward. The user logs in and based on whether she/he wants to check the consumption statistics or track inventory or take note of the last 5 dispenses — they’ll be able to find it as soon as they log in. But there are some complex flows that a user might have to go through like adding a new batch/beer or archiving an existing beer so I identified 3 such use cases and planned their flows.

Wireframing

After completing the whole research and planning phase, I moved on to doing some rough hand-drawn wireframes to get a clearer picture of how the layout is going to look like and how all this information will be presented to the user as soon as they log in.

Visual Design and Prototyping

With a clear vision of how the dashboard should look like I got started with designing the interface.

This part of the design process took me the longest time as it was my first ever product design project. I had to do a lot of research and look at references from numerous other web applications to get a sense of how a good button should be designed and how different sections should be laid out. I spent a good amount of time observing some good-case practices by other companies and took notes on what works and what doesn’t, to improve the usability of the interface.

After trying 2–3 different styles of layouts for the home page, I finally decided to go with the below-attached style.

I started working on the web design first and then I spent time making the design responsive at all breakpoints.

Even though I worked on both web and mobile versions of the design, for the sake of this case study I’m going to take you in-depth into the design decisions using the mobile version as the reference.

Home

Let’s start with the home screen. This application is going to be most commonly used for 3 things — to track inventory, to check consumption analytics and to check the current day’s consumption data.

In that same order of priority, the first thing the user sees as soon as they log in is the inventory statistics. Starting with a bar that shows how much percentage of the batch is left both in percentage and in liters followed by more information on how many liters have been dispensed, when was this batch brewed, how long has this batch been in storage for and an expected date that the batch will run out by — for each beer. This section also showcases the average consumption rate of each beer for the day.

Following this section, the user is presented with information about the last 5 dispenses in the brewery and it is then followed by individual beer analytics and consumption statistics for the day.

Analytics

Coming to the analytics, this screen provides information about the inventory in a visual format with some quick data about the consumption analysis and a report of things like most and least consumed beers of the day, and average consumption of the month/week.

When talking to the users about the problems with the current analog scale to measure inventory — most of them complained about firstly, the inaccuracy of it and secondly, that it’s an absolute number so I tried to recreate the storage tanks visually for the inventory analysis and the users reacted very positively about that.

Bar Specific Analytics

The app lets the user even see analytics for a particular bar which can be accessed through both the home screen and the analytics page where it provides information about how much beer’s dispensed and the weekly average of that specific bar. This information lets the brewer plan and allocate inventory of each bar accordingly.

Daily Consumption

This screen provides information about the consumption stats of all beers/each beer on that particular day with additional information like how well a particular beer performed in comparison to the other beers on that specific day.

This screen helps the brewers understand the consumption rate of their beers and plan their offers and deals accordingly. This screen also provides an option for the user to select any specific range that the user would like to see the analytics for.

Chat

Now coming to chat, one of the hardest things for the brewers and the brewery owners is to communicate to their staff members in one place — be it about restocking inventory, about a particular staff member’s absence, or just simple announcements, they have to resort to different mediums like email, WhatsApp and quick phone calls to communicate which makes it very hard to track and follow up on conversations.

So, I designed a chat system into the dashboard where you can also create different channels like Slack to differentiate various different topics. This way brewers could be on a different channel to talk about just their stuff and the brewery owner could be on a more general channel just to make announcements not having to bother everyone with everything or having to personally text each person.

Settings and Profile

The Settings screen gives the user access to change basic things like their name, password, profile picture and their phone number.

The Profile screen is something we realized we needed after testing the initial designs with the users where we found out that most brewery owners owned multiple breweries and they needed a way to shift between breweries on the app without having them logout and log in each time. So I added this new section which lets the owner easily switch between multiple breweries.

Inviting brewers on-to the dashboard

Once I iterated some screens keeping in mind that a single person owns multiple breweries, that opened the question as to how much and how many breweries do the brewers have access to because in some cases a single brewer maintains 2–3 breweries so I created this quick and straight forward way to grant access to any brewer to any brewery.

As this was one of the main things that the user will be opening the app for, I added an invite button on the home screen itself instead of keeping this in the settings tab.

Record cleaning and adding a new batch of beer

Once a brewer is invited, they’ll be taking care of the inventory — and one of the first things that they’ll be doing is adding a new batch of each beer.

The current flow to add a new beer looks like this: Home>Edit>Record cleaning>Input batch details>Add beer (or as seen in the gif below).

When I was planning the flow for adding a beer with the client, we realized that if we could add a way to record the time taken for the whole process of cleaning the beer storage units and adding the beer — that data can really help the user in optimizing their process of cleaning and adding a new batch.

So, I created this flow where the brewer could add a new batch only after he/she records the cleaning process and until then all the fields will be greyed out. Once the cleaning process is recorded, the brewer can then proceed with adding more information about the batch.

Archiving a beer

When planning about how to delete a beer, we realized that even though the user wants to delete a beer at the moment — there’s a very high chance they’ll add the beer back or they’re deleting the beer from the inventory because of some temporary reasons.

So I decided to design this in a way that the user could just archive the beer instead of deleting it completely and when they are adding a new beer, if necessary they could pick an already archived beer instead of creating a new beer every time which in-turn saves a lot of time for the user.

Navigation

When designing the navigation I started my iterations keeping the most important section of the app — Activity, as the center icon assuming that that’s the perfect place to get the most attention and also that it’s easier to use. I also designed a very thin navigation bar being scared of using up valuable screen real estate.

But the reality differed from my assumptions, after testing the design with some customers we instantly realized that the navigation bar was way too thin for the users to interact with comfortably and the users in the majority of the cases expected the Activity section to be on the leftmost place so I iterated the navigation furthermore and even added rounded edges as that matched the whole visual style and language of the application better.

Developer Handoff

After all the final screens were approved by the client and validated by some users, I organized all the screens with necessary SVGs & colors and delivered it to the developer. I also gave the developer some visual notes on some interactions that I was not able to prototype using Figma.

What went right?

1. Even though this is my first official product design project, I have designed multiple websites before and that experience helped me work on an already established process like planning a content strategy and sketching wireframes to design roughly and get a sense of the content.
2. The client who commissioned this project was an old client with who I’d worked with in the past so he trusted me with all the design decisions I took and let me design with complete freedom which also meant that I alone was making these decisions and was responsible if something doesn’t work so I double checked everything I designed and I always kept the user in mind while designing each and every screen.
3. The distribution of all the data into smaller chunks and different sub-sections really made it easy to consume and use for the user and we received great feedback on the design.

What could have gone better?

Even though I followed a set process and made sure I paid attention to every detail that goes into building a dashboard my inexperience in designing screens got me going through hundreds of sources each day to make sure I was designing things the right way and I felt kind of unsure about what I was designing.

Conclusion

This was a project that I was super scared to take on initially but it turned out to be one of the most fascinating and fun projects that I had ever worked on. This project opened me up to the vast ocean of Product design that I was yet to explore and for that I am grateful.

Having said all that, none of this was easy — there was a lot of researching, understanding, planning, sketching, moving rectangles, figuring things out through the process and that’s what made me realize that designing digital products is what I want to focus on.