Content
漏 2026 Fryderyk Pryjma. All rights reserved.
Privacy PolicyTwo weeks ago, I had the chance to attend Latitude 59 in Tallinn-a startup and tech conference that brings together a fascinating mix of founders, product thinkers, and emerging technologies. While the event covered a wide range of topics, what caught my attention this time was the products - connected devices, embedded systems, sensor networks, and automation layers.
Many of these founders weren't just pitching ideas-they were already building. Some were testing hardware in live settings. Some had already deployed physical products into real environments. That level of maturity surprised me, in a good way.
But something else struck me too.
When I returned and started discussing the event with my team, I realised that very few UX designers-even those working in product-focused teams-are actively thinking about usability in physical systems. There's still a mental separation between "designing software" and "designing for devices." But IoT sits right at the intersection of both, and if we ignore usability in that context, we risk making systems that technically work, but are practically frustrating or even dangerous.
The core realization I had was simple: UX doesn't stop at the screen. And in IoT, it becomes even more layered.
IoT products combine physical devices, embedded sensors, environments, and digital interfaces. That makes usability harder to define and harder to test. But it doesn't make it less important.
Most IoT systems still begin with the same UX tools we use elsewhere:
But once you move past the initial design work, everything becomes more complex and expensive. You can't just A/B test hardware changes. You can't deploy a beta to 1,000 users overnight. Your prototypes often require custom-built devices, physical environments, or integration with infrastructure.
That's why early benchmarking and competitor analysis are far more important in IoT than in pure digital projects. Iteration is slow and expensive, so it's worth spending more time up front understanding what's already out there, what's been tested, and what users already expect from similar systems.
This topic also brought back memories of my Master's thesis, where I explored the design of remote operation stations for vehicle fleets. These were systems used by operators to control or oversee autonomous or semi-autonomous vehicles from a distance.
As part of that research, I conducted interviews with experts at RISE, a Swedish research institute, and engaged in workshops and discussions with stakeholders from the automotive and robotics sectors in Gothenburg, including people working on autonomous driving and safety systems.
The core question we explored was:
How do we design a remote station that allows a human operator to control a vehicle safely, confidently, and intuitively-even when they are nowhere near it?
The KPIs in that case weren't about UI completion rates or app stickiness. They were:
One usability test we conducted looked at how video feed characteristics affected performance. Was color fidelity in the camera stream important? Or did frame rate matter more for driving accuracy? Our data showed that higher frame rates contributed more to safety, while color made little difference. That insight had a direct impact on hardware and network decisions.
Other areas we explored included:
All of these are UX questions, even though they aren't what many people imagine when they hear "UX design."
This is why the gap I observed at Latitude 59 felt so important. Many of the founders working on IoT solutions were clearly thinking about the tech. They had clever engineering teams, solid prototypes, and great ideas. But few mentioned usability testing, operator research, or user workflows in physical environments.
And on the flip side, very few of the designers I know are actively seeking to work on these kinds of challenges. There's a big opportunity here, but it's flying under the radar.
IoT systems don't just need engineers. They need designers who understand usability, behavior, interaction, and real-world constraints. And that design work needs to start early-not after the hardware is locked in.
I'm not trying to go deep into design frameworks or methodology here. That will come later. What I wanted to do now was simply raise a flag, based on what I saw and what I've worked on.
As UX designers, we have tools, methods, and mindsets that are incredibly valuable in the IoT space. But to make use of them, we need to recognize that our domain includes more than screens. Usability in physical systems-especially those that blend software and hardware-is not someone else's job. It's ours too.
In future posts, I'll go deeper into how to run usability testing for connected devices, what early research looks like in these contexts, and where UX and hardware design meet.
But for now, just this:
Let's not forget UX in IoT.