Don't think about IoT without UX design - a chat with Infiswift

One glaring oversight in my Enterprise UX series is designing for IoT. Internet of Things projects are typically data-focused, but that doesn't render UX design irrelevant. If anything, it raises the stakes, posing problems that the most experienced UX designers may not have encountered.

Recently I had the chance to hash this out with the Infiswift team. Joining me on the phone were Phil Dawsey, Marketing Director and Subramani Baskar, Lead UX Designer. Infiswift bills itself as an IoT platform company that provides a tech foundation for customers to build out IoT solutions. Though they provide the "wiring and piping" like device and user management, Dawsey says that the biggest need is supporting customers as they build:

Most companies on the enterprise side need pretty much full support in developing an IoT solution because the IOT is the wild, wild west right now.

Whether it's solar power or agriculture, companies have IoT ideas but "there's no defined way, like mobile or web, to build out these solutions."

Why is UX for IoT overlooked?

So why is IoT UX overlooked? Dawsey and Baskar point out that when it comes to consumer IoT like smart thermostats and lights, the user experience is taken into account more. But that's not necessarily the case in industrial IoT:

When we're talking about John Deere tractors out in the fields, or monitoring various aspects of an oil pipeline, these user interfaces are pretty much the last thing that these guys are thinking about.

Many don't even confront the UX part until IoT sensors are deployed:

People are starting to roll these things out. User interfaces are generally not even really considered until you have sensors implemented in the fields, and you're starting to get something back. Then companies say, "Okay, we need some dashboards, let's create some really basic dashboards."

But slapping up a dashboard isn't enough:

There's a lot more than just a web dashboard to user experience. On the enterprise side, that's generally something that's not asked about in the RFP and proposal phases.

Automation doesn't negate IoT design needs

The nagging question about UX design and IoT is: to what extent are user interfaces even needed? If you're enabling machine-to-machine communication, wouldn't the best design be to remove the human UI whenever possible? I put that to the Infiswift team. They argued that automation is not the first phase in IoT:

Automation is an important step for IoT, but in reality, the first step of IoT is not automation. The first step is getting data in, doing analysis on that, and making decisions based on that. A lot of those decisions are not automated.

Those decisions go through users, and, as Baskar explained using a solar customer example, you have to design for a range of users, from field technicians to owner-operators to IT departments. They all expect a UI that helps them act on relevant data quickly:

All of these groups want to see different sets of data to make different decisions on. And while automation is something we want to strive for, it's in the future. That's generally not the first step. There's no way humans are - at least in the near term - being removed from IoT solutions. And even if there is some form of automation, informing those end users is still a critical part of the process.

But the IoT UX challenge goes beyond designing for different roles. People don't just wear different hats, they rely on different devices. Dawsey went back to the solar power example:

In solar plants, you have interfaces on some of the systems. You may have a very basic LED display of some sort, or even a graphical interface attached to devices that you need to provide consistent information. The type of device operating system, the coding language, all of that stuff, makes it more difficult than creating an app for Apple or Android, for which you have a very defined, specified ecosystem of devices.

It's a mistake to get too far down the IoT road without a UX discussion. So how do you prompt it? Presenting UX mockups to clients is one way to get their attention:

It's hard for people to think about something when it's abstract. Once you have a first iteration of a UI and UX, people can look at it and hold it and say, "Okay, now this makes no sense, we need to change this." Then they start getting very concerned and very interested in that aspect of the project.

Look out for design issues during POCs

Be prepared to incorporate UX feedback from wherever it comes, including technical decisions. Infiswift gave the example of hardware and GPS connectivity:

Let's say you're using a certain GPS module, and then you start getting the data in. [During prototyping, the customer says] says, "Uh oh, the latency is way too high and the accuracy is not high enough." Crap. This is a user experience issue, but it relates to the hardware and the connectivity that we've selected. So we have to go back to that decision and change that. It's just unusable. The data gets there but it's not enough. That's something that's unique to IoT in that issues come out and are uncovered in UX, but those issues may also be very technical, and related to parts of the project that you might not associate with user experience.

I appreciated the honesty of Dawsey and Baskar, who did not pretend their clients are eager to address UX from the get-go. This leads back to the classic "How much do you challenge your customers, versus fulfilling their stated priorities?" Dawsey told me that right now, for most customers, the UX issues are raised during the proof of concept phase:

Most customers start with a proof of concept, and that is the low-risk tests that get you through some of that A/B testing and figuring out where you made some bad decisions.

POCs are useful, but isn't it better to push customers upfront on the UX issues?

That's the ideal situation, but everyone is figuring out IoT right now. We're figuring out IoT. Each project is different, from agriculture to manufacturing. We want to do that completely upfront, but right now, proofs of concepts are an important part of the IoT development process.

My take - designing for industry will carry the day

Infiswift told me they are considering expanding their POC format to include more UX A/B scenarios, such as having users test on two different types of hardware and two different app UIs. The tradeoffs are cost and time, "But that's a concept we're toying around with."

Speaking to industry needs is another hurdle. My knee-jerk response is that it's going to be difficult to design for IoT across industries - that strikes me as a domain for industry specialists. It sounds to me like Infiswift will push in that direction, perhaps by creating specialty UX divisions in industries where they have traction. As Dawsey said to me:

When we've been chatting with customers, it's really important to speak their language. And if you're showing them an example of something, it just doesn't translate most of the time. You're trying to illustrate a UX concept, but if you show them a solar panel versus a tractor, it doesn't get across a lot of the time.

With forty employees, and clients in the U.S. and India, it's growth mode for Infiswift. Japan and China are other targets, now being serviced by partners. The most encouraging thing I heard from Infiswift was their willingness to grow and change. No, they don't have IoT UX completely figured out. But they've learned enough to put some stakes in the ground, and that's what this discussion needs.

End note - this article is part of my ongoing diginomica Enteprise UX series.