Building an industrial automation platform
Product Manufacturing data streaming and analysis
Role UX Design, Research
Timeline 2 months
Team Founders, Engineering (hardware, backend, frontend)
Tools Sketch
It’s a week from Christmas, 2016. I’ve just moved to Manhattan to join a startup as employee 8, product hire 1. They have funding. They have customers. They have a product.
And nobody is using it.
Our team is spending its time consulting with customers to get them value from our product. This is crazy.
Part 1: “I want to, I just don’t have the time.”
Fast forward 3 days. I’m on the ground somewhere in the industrial flats of Chicago with a few team members. It’s -20º outside. We’re there to meet with one of our key customers, take some interviews, watch over shoulders and see what a day looks like for them, and where our product does—or does not— enter in to the equation.
What we see: our customer still has the need they hired us for, our target audience is hungry to make use of this new data … but there’s just too little time in the day. What they really need is a way to see the good bits and the bad bits of the process to make the raw data make sense.
As product people, we know what “there’s just not enough time” really means: the product has failed. If the potential value is high, but it can’t be tapped, it’s worthless.
We left the factory feeling certain we’d identified the hurdle. We were wrong.
Part 2: I target wrong user.
I return from Illinois ready to evolve the product to kick over this hurdle. Atop our timeline view of process data, I design an annotation engine, allowing engineers to carve up time like a video editing interface, adding golden context to raw data.
This was it! The process engineers would now be able to say which processes were good, which were poor. Exactly what was asked for. I mock up concepts, put it in front of customers, they love it, we built it, ship it.
Crickets.
We call up our process engineers. They love it, they want to use it … but, well, it’s just hard to annotate things after the fact. I’m called away from my desk for an hour, and when I get back, I can’t recall what was what.
Back to the drawing board.
Part 3: I target a different user. And it’s controversial.
I take a step back, take a deep breath, and cast anchor on the friendly shores of proper design process. I take the team through start-at-the-end exercises, forcing us to define ideal outcomes, key blockers, and users in the playing field we’d maybe ignored.
Through this process, we realize machine operators have both the context of what’s happening at a machine and dependable presence. Could we involve them in the process? Could they contextualize the data?
Engineers don’t think it will work, and factory managers scoff - operators are viewed as second-class citizens in factories, basically a replaceable pair of hands. Can we try it? What can it hurt?
Part 4: I Design and ship a React native tablet app.
This new user spends their days on-foot, hovering around a cluster of 40-foot-long manufacturing lines. They can tell what’s going on with the machine by sounds it makes. They write things down in a physical logbook. I’m designing an interface that makes sense for them.
It’s gotta be faster than writing things down.
It’s gotta be smarter than whatever process they already have.
It’s gotta make them feel good about their work - see the value of what they do.
Important things should be desirable to do.
It should learn from them, and reflect this, feeling like a tool that’s worn to the craftsman’s hand.
It’s a simple app, oriented around a single view synchronized to the manufacturing line, streaming the status of the machine via integration with our platform. They can see data that they’ve never seen before. When changes in state are detected, the app reflects this, and prompts the user for input—What’s going on now? The operator can respond with a single tap to contextualize the time segment. This is streamed platform-wide in realtime, so process engineers can analyze it and managers can keep tabs on the floor.
I mapped out the system behavior, sketched an interface, mocked it up in Sketch, engineers prototyped it, we tested it on a rig in our lab, and we shipped it.
Part 5: People use it. And we find our next product.
The doubt of others had crept in as we finished the app: what if our target user is unreliable? What if they don’t contextualize anything?
This turned out to be a non-issue. It turns out operators liked being able to flex their expertise and have knowledge attributed to them.
The story ends in this way: operators ended up using the app, engineers got what they needed, pilot customers expanded to full-portfolio installations, and Oden survives to this day, running off a very healthy Series B.
As for what happened next …
While at a factory post-launch, we saw a curious thing: an engineer had bought their own tablet and was mirroring the app at their desk. They were using it to monitor critical products and lines. And here our next product iteration was born: factory-level monitoring views.
