Design Brief: Cooler Calculator
What’s cooler than bein’ cool? Dry ice!
I built a Cooler Calculator for a small dry ice business in the Bay Area. This is the story of why and how it came to be. I’ll start with the backstory, then unpack my design process, and finally share the end result.
Backstory
Every year, me and 70,000 of my closest friends get together and head out to the remote deserts of Nevada for a week or so. It’s like a camping trip but bigger, and with more LEDs. I’ve been a couple times and decided to go again this year.
Well, if you’re going to the desert for a week, you should come prepared. Water comes to mind. Food is also critical. Personally, I like to cook, especially in unexpected places. No peanut butter jelly for me, thanks. On the menu: stir fry with steak and vegetables, pasta with smoked pheasant, and bacon—lots of bacon. And all of that needs to stay frosty. Ice is OK but dry ice is better. It doesn’t melt, it sublimates, which means your cooler doesn’t turn into a swimming pool. It’s also very cold so your victuals can stay fresh longer.
The first time I needed dry ice, I did some Googling and a little site came up: Ben’s Dry Ice. It wasn’t much to look at—just a form basically. Fill it out and get dry ice. Simple enough. But this year, when I went back, holy upgrade! Ben had been busy. Now, his site was powered by Shopify and it looked great. So I went about my shopping.
One of the first questions you have when buying dry ice is “how much will I need?” In the past, I had answered that question with an email, “hey, Ben, I’ve got a 50 quart cooler and I’m trying to keep food cold for about a week, how much dry ice do I need?” Ben’s always been helpful but as his business grew he realized he couldn’t respond to every email so he figured out a better solution. He built a spreadsheet, locked some cells, and boom he had a very basic Dry Ice Cooler Calculator.
Well, this spreadsheet calculator had some problems:
- Only one person could use it at a time. Google Sheets actually shows you who else is editing the document at the same time. So you kind of play this weird waiting game of chicken. Not good.
- It required a lot of instructions. Just look at the screenshot above. Where do you type? Where is the output? It’s not very clear. There are instructions outside of the spreadsheet and even more within.
- It assumed all your coolers were the same size. Not a deal-breaker but definitely not ideal.
- It undermined the professionalism of the site. The rest of the site looked great! But this page just felt cobbled together.
I started thinking: I bet if I built Ben a legit calculator that solved these problems that a) his customers would really appreciate it and b) I’d get free dry ice. 😉
So I got to work.
The Pitch
I’ve been doing this type of work long enough to know: don’t ask, show. I knew that taking a first crack at a mockup wouldn’t take long and would give Ben and I something real to talk about.
After spending a little time in Sketch, I had a mockup.
Here’s how it works:
- Pick your cooler type: “freezer” if you’re trying to keep things frozen or “fridge” if you want to keep things cold but not frozen solid. I chose icons that really reinforced that. No matter who you are, you want your steak frozen and beers cold.
- Indicate your total cooler size. If you have two 50 quart coolers, just drag the slider to 100 quarts.
- Choose the duration of your trip.
- See the total number of pounds of dry ice necessary.
It was simple. Too simple in fact. Because I hadn’t fully unpacked the problem yet, I ended up over simplifying things. When I’m just getting started with something, I actually like to over simplify because you end up challenging more assumptions and, if you’re successful, you’ll have to do less work in the long run.
I actually like to over simplify because you end up challenging more assumptions and, if you’re successful, you’ll have to do less work in the long run.
But this mockup had some problems:
- The visual design didn’t match Ben’s brand. That’s fine—I had absolutely no attachment to any of it. I just picked something that looked decent. In fact, I think I ended up with pink because the icons I liked were pink, when I found them and I didn’t want to bother to change them.
- You have to do the math of adding up the total quart size of all your coolers. It’s not terrible but if we’re setting out to replace an incomplete tool let’s not replace it with another incomplete tool, right?
Round 2
I set to work to fix these problems. I used the typeface used throughout his website and matched the colors as well as I could without sacrificing readability. I also made it possible to add a cooler.
Sadly, I didn’t consider that you may want one cooler dedicated to frozen items and another used as a fridge. Now, all the coolers were of the same type. I was disappointed that in this iteration the spreadsheet actually was more useful.
Round 3
Finally, we were getting somewhere. It had all the features we needed and I was starting to ask questions like “what happens when you click the +” or “should you be able to remove the first cooler?”
Whenever I start to ask myself interaction-related questions, I need to start coding. I like design tools like Sketch but I start to get antsy if I’ve been there for too long. There are questions that a design tool can’t answer like “how does it behave as I resize my browser?” Or, “will these controls even be possible to build?” I had some doubts as to whether sliders were the best choice and I also wanted more clarity about mobile vs. desktop experiences. There were also design queues I wanted to imitate from his website that I didn’t want to spend time replicating in Sketch.
Whenever I start to ask myself interaction-related questions, I need to start coding.
Round 4
In high school, my sculpture teacher gave me a really good piece of advice: get material on every piece of the armature first. Only after the entire form has taken shape can you focus on polish. I set out to reproduce my static mockups quickly so I could focus next on getting the interactions right.
I wasn’t at all concerned about the calculation. I left that until the very end because I knew I would be changing things that would affect how the result was determined.
At this stage of a project, I want to address the technology stack. I try to avoid dependencies wherever possible and I felt like HTML, CSS, and JavaScript with jQuery would probably be all I needed here. But I wanted to be sure that the layout and the sliders wouldn’t give me a hard time.
I wanted to have a grid system that made laying out content into columns easy. I didn’t want a framework like Bootstrap determine what and when content should stack. My goal was to design for a medium size desktop browser (~600px wide) and use percentages for everything so it just did the right thing at smaller widths. I’d drop in a few optimizations for mobile with media queries later. I decided to go with Toast by Daniel Eden. The class names are a little verbose for my tastes, but it let me nest grids and didn’t really have any functionality I didn’t want. It was a grid, plain and simple.
Allowing someone to specify a specific value sets an expectation of a very accurate result.
I had to make sure the sliders would suite my needs. If they were unweildy I would have to redo the design with text-based inputs. I wasn’t too worried about browser support but the sliders were a critical part of the design. They also had to be easy to use on mobile. I wanted the sliders to work in increments—I never wanted you to be able to pick a 43 quart cooler size. That may be your actual cooler’s size but allowing someone to specify a specific value sets an expectation of a very accurate result. But this whole tool can only give you an estimate that’s reinforced by the fact that you can only buy dry ice in 10 lb blocks. The good news was that browser support for the range input is very good. I only ended up using range.css by Daniel Stern to customize their appearance.
Once I had a working prototype, I was able to quickly spot improvements:
- There was no need for an add cooler control on every cooler. It only needed to appear once, at the bottom.
- The days slider was getting in the way. It disconnected the add cooler control and the coolers themselves. So I moved it to the top.
Polish
Now came the fine-tuning. This was the point at which Ben and I actually went back and forth the most. We made a lot of improvements:
- Some leading instructions and labels. I was hoping to avoid having any instructions but after putting it in the hands of someone who had never seen it before we realized that “Freezer” and “Fridge” made no sense without some explanation.
- The freezer and fridge toggles were taking up too much vertical space. Horizontally aligning the label and icon made room for additional coolers.
- The sliders worked well but were too small for mobile users.
- We moved the “add cooler” control closer to the coolers, which helps reinforce it’s role. Also font-size, casing, and stroke helped address low contrast and readability.
Instrumentation
With any project I work on nowadays, I provide instrumentation to go along with it. I wanted to track basic actions like adding a cooler, changing a slider, or clicking buy.
I already use Google Analytics for most projects so I simply used their event tracking. I wrote a helper function that let me send events to Google by simply specifying the element, the event, and optionally a value:
- cooler added
- cooler removed
- cooler type changed (with type)
- days changed (with number of days)
- cooler qts changed (with qt size)
- buy clicked
So far I haven’t needed to dig into any usage data but it should help answer questions, when I do have them. Better to have the usage data (and not use it) than to not have it when you do end up having questions.
Instrumentation can be a bit like testing. It’s always hard to write your first test because you have to set pick tools and set everything up. But once the framework is in place writing your second test is much easier. Just having a simple event logging helper may take a few minutes to set up, but allows you really quickly add instrumentation as you continue to evolve the project.
In Conclusion
We launched this a few weeks before my trip. I was happy to haul a complimentary 300 lbs of dry ice out and share it with my campmates and friends. You can see the finished product here:
http://bensdryice.com/pages/cooler-calculator-1
Ben says customers have loved it. I haven’t talked to any of them myself but I’d like to! If you have any feedback, I’d love to hear it.
I set out to do this project mostly out of good will. It’s been great working with Ben and the cycle of good will has definitely started. Now, Ben has commissioned me to build another calculator for determining the amount of dry ice needed to build a fog machine. I’m excited to take on this next project just in time for Halloween. 🎃
Stats
- Libraries: Toast, range.css, Sprinkles, jQuery
- Lines of code: 124 HTML, 151 CSS, 123 JS
- GitHub: avand/calcoolator
