Whole Note
Handling manufacturing and supply chain for a start-up food company
My family has a business making gluten-free baking mixes, and I joined in 2013, about a year after my dad founded it. One of the first things I helped tackle was improving our manufacturing process. We had started to get our products into grocery stores, and the very basic approach that we had used thus far (doing everything by hand) was clearly not practical at a larger scale.
Our first mixer we used to blend flours together. You had to spin that thing by hand.
As part of this effort, my dad had the idea to use an iPad app to display the recipes of our products to the person mixing them. This way, they could tap through each ingredient one at a time as they added them to our new motor-driven mixer, rather than just reading them off a sheet of paper. This would hopefully reduce the chance that they would lose their place and add something twice or skip a step (we had done both). I had experience making iOS apps, so this sounded like a pretty simple project.
Look at enough of these and you'll go insane
I was also actually doing a lot of the manufacturing myself (we all wore many different hats at this stage of the business), and one piece of it became the bane of my existence: batch codes. If you’ve ever noticed the seemingly random string of letters and numbers on the side of anything you buy at the grocery store, that’s a batch code. It gives each batch of product that a manufacturer produces a unique identity, and allows the batch to be recorded and tracked.
In addition to generating their own batch codes, manufacturers have to maintain records of the batch codes of every ingredient that goes into every batch of their product. For me, this meant that for each of the 20+ flours and starches that I threw into the mixing barrel, I had to write down its batch code, then go back to the office and enter them all into a new line in an increasingly massive spreadsheet. Not exactly difficult, but it was tedium in the extreme.
After a couple of weeks of this, as I was wearily typing X547J36 or something into yet another row in Excel, a thought struck me: what if I could do this in our app? What if, instead of writing all these batch codes down and then typing them in later, I could just type them into the app, right when I was using the ingredients, and the app would record them all in a spreadsheet for me? That insight immediately led to others: batch codes weren’t the only thing we were keeping track of in spreadsheets. Orders, gluten tests, and more could be integrated right into the app. In fact, it was possible that it could incorporate all of our manufacturing, supply chain, and quality assurance processes. My dad enthusiastically supported the idea, seeing that it had the potential to make scaling up our operations much easier.
Research
The first step was to make sure there weren’t any existing products that would do what we wanted. As eager as I was to put my design and coding skills to use for our company, we didn’t want to reinvent the wheel.
After conducting a thorough survey, we concluded that developing our own app was worthwhile. All of the available solutions were either too expensive for a small start-up like ours, or didn’t include all of the features we wanted. Furthermore, by doing it ourselves we could customize the software to exactly fit all of our needs, some of which were unconventional (for instance, we had to test specific batches of our products and ingredients for gluten).
I assessed our needs by making notes on all of the data that we collected and generated throughout our production and supply chain processes. I then mapped out the relationships between these data, which helped to inform the content of the app and how it would be laid out.
Planning
The next step was to determine what all the app should be able to do. It obviously needed to guide the user through a recipe when mixing, and let the user record batch codes while doing so. The question was how much more it should offer.
To decide this, I sorted the data by how often they would need to be updated. Some things, like ingredients inventory and orders, were updated frequently; we received shipments of ingredients and sent orders to customers on a regular basis. The app would provide a lot of value by making these events simple and painless to record and edit.
Other data, however, while clearly needed in the app, were not updated frequently. These included information about our products, ingredients, and recipes, among other things. While we did occasionally tweak a recipe, or change suppliers for an ingredient, these were pretty rare, so I decided not to build functionality for these changes into the app. Instead, we would just go into the spreadsheets where the data ultimately lived and edit them there.
This was not the most user-friendly option, since it meant we still had to work with some spreadsheets directly. However, since the app was just for internal use, and we wouldn’t need to do this very often, we decided that it wasn’t worth engineering the app to handle these changes. We could still deal with a few spreadsheets.
Design
Since the app was not a commercial product, I put minimal emphasis on visual design, and focused on logically laying out all of the information and making the app easy to use.
The screen that required the most thought and care was the one that would guide a person through mixing a product. It was crucial that it was easy to understand and navigate; if a mistake was made, it could mean having to throw out an entire batch of product, which was a costly headache. Because of this, I made sure that the important information in this process – what step you were on, which ingredient to add, and how much to add – was as front and center as possible, with everything else occupying relatively little space.
I made the arrow buttons that move between steps large and easy to tap so that someone handling lots of different flours and equipment could step through the recipe without much effort.
Testing
Because the app was only used in-house, we tested it live by deploying it in our operations, and checking the data it generated to make sure it was accurate. We were still small enough at this point that any errors could quickly be caught and dealt with, and wouldn’t cause any major problems.
Aside from dealing with some minor bugs, the app worked as intended, and we were thrilled by how much less work it took to stay on top of our data.
A couple of usability issues did crop up, however. Because of how the app was laid out, there were a few common tasks we performed that required multiple taps to get to. For example, to begin recording an order to be shipped out, the user had to tap into the Orders section, then find the + button in the top right corner.
This was only two taps, but it was something we did frequently. Over time, I felt it was just cumbersome enough, and just a little too difficult to discover even after doing repeatedly, that it was worth making more accessible.
There was a natural home for “quick actions” like this in the top section of the home screen. It had previously just been for the "Mix" action, but it was intuitive for there to be more actions in this space. I chose the three things we did the most and included them there; this struck a good balance between convenience and keeping the home screen uncluttered and easy to navigate. I also removed the Mix action on the iPhone version of the app, since we used an iPad to mix and never used this on our phones.
Summary
Overall, the app has been immensely beneficial to our business, and has helped us effortlessly stay on top of our manufacturing and supply chain needs. It has allowed us to expand from a single Whole Foods location in the Houston area to a variety of stores across the country, without making any major changes to our processes.
The app makes training employees much simpler as well, and helps guard against the errors that tend to come with bringing in new people. All of this has freed us up to devote more attention to other aspects of the business – a huge boon for a tiny company with limited time and resources.
2013 vs. today