How might we use sensor data to make food and beverage production more efficient and sustainable?
This is the overarching question we attempted to answer at Connected Proof—the startup I founded with a friend in 2019. Here’s how we did it.
My role: I was responsible for all design and product management, and contributed to front-end development. As co-founder, I also did sales, marketing, financial forecasting, and partner recruitment. Startups are hard.
01
Background
Concept
In a nutshell, our product is similar to the Nest learning thermostat, for industrial process controls.
Our hardware products, much like Nest’s thermostats, enable the real prize: energy and cost savings.
UX & Market Research
At a product-led company, there is little distinction between the UX and business strategy, so UX research basically means market research.
User interviews take on a different dimension: you're doing a mix of discovery and selling, and finding people to talk to you is part of the challenge. I spoke with over 100 various potential users, industry veterans, and creators of complimentary products to understand if our assumptions had a place in the market.
Ethnographic research means getting your hands dirty with potential users where they live or work. We worked with numerous brewers and distillers to understand where opportunities for improvement existed in their current processes.
Competitive analysis is both a market and UX function. I compiled a spreadsheet of dozens of competitive products in different spaces and compared them to look for the most open space in the market.
SWOT analysis helps identify the strengths, weaknesses, opportunities and threats to help define the positioning for your product stategy so you can decide where to focus.
Design Challenge
We envisioned an entirely new IoT platform to allow anyone to remotely control and automate a variety of sensors and actuators. It needed to be intuitive enough that non-technical users could install devices and “program” them for their specific use case.
I designed a platform that would work on everything from small ruggedized device touchscreens, to mobile phones, to laptops, to large wall displays.
02
Design Process
When a startup is little more than an idea, founding team members wear many hats. At Connected Proof, running design meant being Product Manager, UX Researcher, UI Designer, and Front-end Developer on any given day.
Info Architecture
With an idea of the IoT platform we wanted to build in the short and long term, we set out to define our data model and platform's information architecture. We broke out the model requirements into broad phases (red and yellow boxes), with future ideas and open questions in blue. This represented the data we needed for both our cloud-based SaaS platform, and the broad MQTT information that our IoT devices needed to send and receive.
Below: the zoomed-out version of our combined data model and info architecture, with zoomed-in detail view below.
“Digital Whiteboarding”
Below is a digital "sketch" of the first pilot installation that we did at a real customer outside of our basements.
Just like using a pencil in your sketchbook or a marker on your whiteboard, it's okay to be fast and sloppy—the design isn't the important part, it's getting your ideas out quickly.
Whiteboards are useful in meetings to have a shared frame of reference, but I think a shared digital surface like Figma can be even better. We were building this during the pandemic, separated between Boston, MA and Longmont, CO, and Figma let us collaborate in realtime. Plus, you never need to erase it and you can catalog your changes over time.
Early Wireframes
Once we had a direction for our first pilot, I got to wireframing the experience to quickly arrive at all of the software we'd need to build to support the MVP for this specific pilot installation. In order to force ourselves to really focus on an MVP, features and screens were all broken out into phases and anything that wasn't required for the pilot was noted, but explicitly not added to the wireframes.
This afforded quick collaboration with my software and hardware engineering counterparts, and helped identify (1) features we needed to build and (2) potential shortcomings with our previously defined data model without treating any idea as too sacred to quickly change or throw out.
Early Design Ideas
I started translating wireframes to designs quickly, with the goal of getting fast feedback from our pilot users. At this stage, "acceptable" was enough for the UI—it didn't need to look super polished because we knew features would change quickly.
Early Prototype
The early designs were quickly turned into a clickable prototype in Figma in order to share with users.
It's really important to ensure users understand the fidelity of the designs they're seeing, and be guided to giving feedback on what you're looking for at any given stage: UX, navigation, concepts, etc. Rarely are you looking for visual design feedback from users.
By working directly with users early and often, we were able to quickly iterate through ideas for features, as well as address usability issues before even starting to code.
Screen recording of clicking through one version of our early Figma prototypes
A note on selecting early "alpha" testers and pilot customers
When you're talking to potential pilot testers, you're looking for the "innovators"—even earlier than "early adopters"—on the diffusion of innovations curve.
They need to be willing to use a product that is going to break and change significantly from version to version. Just being enthusiastic about giving feedback on your product isn't enough—shaping the direction of your product has to unlock tangible benefits for their personal lives. If you find this type of partner, you know you're making a valuable product for at least one real person, and you're likely going to get the most useful feedback.
If you can't find this person, then you might want to reasses what you're working on.
If your product, like ours, could pose a real-world liability or safety risk, users should understand it intimately, still want to use it, and know what to do when (not if) something goes wrong. We spelled all of this out in plain-language documentation that served as a user manual, and in a pilot testing agreement that our partners signed for liability purposes.
Design Iteration & Componentization
Testing & Documenting
The overall platform and each feature went through multiple rounds of wireframing, design, prototyping, and user testing depending on the complexity. Nothing in software is ever "final" per se, but we did arrive at versions of UI components that were tested enough that we were comfortable abstracting and componentizing them for reuse around the platform.
Once at that stage, the design documentation might look like the below file—showing the UI and interaction intent and any implementation details.
Novel front-end component tooling in React
You'll notice that the design spec below focuses on a single component that's used across web, native mobile apps, and on our custom hardware running a Chromium-based UI. We wrote a custom React compiler that allowed us to maintain one version that automatically compiled to the correct usage, depending on device parameters. This allowed for faster styling and functionality updates.
Below is another example of UX documentation that describes interaction intent for the touchscreen on our device. Even though we were a small three-person team, documenting design decisions helped get everyone on the same page in the design phase, and reduced confusion when it came time to build.
03
Final UI Designs
Here's a quick look at what we ultimately shipped with our beta product.
Hardware Device UI
The ruggedized touchscreen device was installed on the production floor at breweries and distilleries, so the goal was making the display simple and legible from a distance. The limitations of a small screen meant that primary interaction tasks needed to be big and simple, and we offloaded non-critical tasks to the mobile and web UI.
Mobile UI
The mobile app UI is primarily intended to be an extension of the hardware devices, plus an always-with-you notification center for critical alerts about production.
Web UI
Lastly, the web UI is for installation, facility setup, and reporting. All hardware device controls are available and users have the best birds-eye-view of operations and processes. Admin users can model their facility and create "digital twins" where sensors and actuators are connected to our hardware and assigned to real-life physical plant equipment.
04
Results
Our little team of three—designer, developer, and electrical engineer—built an entirely new IoT platform and shipped a custom-built hardware product that I’m really proud of, in about 18 months.
Successful Beta Launch
Our 3D-printed, custom-manufactured PCB, new Chromium-based GUI, hardware device shipped to a handful of pilot customers and allowed us to learn more about the market.
It’s still out there in the world: collecting data, operating heavy machinery—remotely, automatically. I can press a virtual button on my phone in Massachusetts and it makes a real valve open or close at locations in Colorado or New York in a fraction of a second. This still makes me grin like a child.
Pilot Customer Wins
Flexible time off to enjoy
A distiller took a vacation for the first time since opening, and a brewer saved hours every week by not having to be present to make adjustments.
Hours of saved labor time
A brewery team automated manual operations, saving labor time and allowing them more time to spend with guests.
Batches saved from spoilage
With alerts, users were able to save product after their heating and cooling systems malfunctioned, saving thousands of dollars.
Energy and cost savings
By seeing inefficient heat/cool cycles, a distillery saved money and energy on heating and cooling bills.
Peace of mind worth paying for
Knowing they can always check in on conditions was enough to convince a distillery to invest in additional sensors.
Outcomes & Learnings
After the successful launch of our beta product, we know that the appetite exists for easy-to-use industrial automation, but we also have a greater appreciation for the complexity of implementing an IoT product in a traditionally analog space.
Alas, while we overcame big technical hurdles to ship a product that is still truly useful to our pilot customers, we ultimately decided that this particular business model didn't have a market fit that was worth our continued time investment.
After about 18 months of dedicated work and a few prior years worth of daydreams, it was hard to let go, but I'm hopeful that our underlying IoT tech may still resurface as an expanded product for a different market.
A full post-mortem is probably warranted, but beyond the scope of this case study. I'll just say that hardware truly is hard—harder than I naively thought going into it from a software-based startup background.
In hindsight, we probably could have used off-the-shelf products to learn more about the barriers to hardware adoption faster. Building our software platform alongside of custom hardware gave us a better understanding about how users would use the envisioned system together, but was very time-consuming to build and probably unneccessary to arrive at conclusions about hardware.
The silver lining is that our initial product assumptions were mostly right and the platform as a whole solved a real need—this translates into important insights for a potential future business. Unfortunately, technical issues, installation/adoption barriers, and cost were all too high for this market.
But we all learned a lot—this was my first foray into designing for IoT hardware and I have a better technical understanding of deploying IoT tech, and the UX considerations involved in designing for distributed network devices.
Personally, this was a fun project that made me a better designer, developer, and hardware tinkerer.
If you're interested in seeing what we were trying to sell from the customer's perspective, you can still take a look at our marketing website at ConnectedProof.com
