Make 6 Protocols
Feel Like One.
Sole designer at a formation-stage IoT startup. One platform, two customers.
Scope: Research, IA, interaction design, visual design, Figma component library, design system documentation.
A Norwegian IoT startup
building from zero.
Dimension Four was building an IoT platform that needed to handle six different communication protocols (MQTT, HTTPS, UDP, LoRaWAN, NB-IoT, and 5G) through one consistent interface.
Their customers ranged from a Norwegian municipality managing 40+ physical sensors (waste bins, parking, air quality, water levels) to a startup building a baby monitor app using a pure API layer.
I joined as the sole designer on a five-person team: CEO, CTO, two engineers, and me. No PM. No design precedent. No existing design system. The product needed to be designed from the domain model up.
Five people.
No PM.
Direct access to everyone.
The team was CEO, CTO, two engineers, and me. I partnered directly with both founders on product direction, no intermediary, no translation layer. When there was a design question, I was in the room.
My first two weeks were pure domain onboarding. I learned IoT protocols, sensor types, data hierarchies, and the Stavanger municipality's infrastructure. Those onboarding notes became the team's reference documentation. Engineers joining months later used them.
I ran ad-hoc frontend syncs with the engineers rather than formal handoffs. The Figma component library I built became the shared language between design decisions and implementation.
Six protocols.
Two customer worlds.
No precedent.
Six incompatible IoT protocols. Two fundamentally different customer types.
One platform that needed to feel coherent for both.
Protocol chaos
MQTT, HTTPS, UDP, LoRaWAN, NB-IoT, 5G. Each with different data formats, latency patterns, and reliability guarantees. Users shouldn't need to know which protocol their sensor uses.
Two customer worlds
A city admin managing physical infrastructure (waste bins, parking, water) and a startup CTO using a pure API. Same data model, completely different mental models.
No design precedent
No existing IoT platform had solved the multi-protocol UX problem elegantly. Competitors either exposed protocol complexity or oversimplified into unusable abstractions.
Before sketching any interface, I mapped the domain's data model into a hierarchy of Tenant → Space → Point → Signal, and explored three IA models against these constraints. Every design decision traces back to that hierarchy.
Flat list
All data sources in one scrollable list. Simple but collapsed hierarchy. Users couldn't distinguish spaces from individual sensors.
❌ Abandoned · lost context at scaleTree navigation
Nested sidebar tree reflecting the full Tenant → Space → Point hierarchy. Powerful but intimidating. New users got lost in the depth.
❌ Abandoned · too complex for onboardingRepeating tab pattern
Three-level tabs (L1: Spaces, L2: Points, L3: Signals) that repeat the same interaction at each level. Consistent, learnable, scalable.
✅ Shipped · engineers adopted it without being briefedThree structural
choices that defined
the platform.
“Points” not “Devices.”
The naming decision that made the whole system work. Calling data sources ‘Points’ instead of ‘Devices’ or ‘Sensors’ meant the same concept could represent a physical waste bin sensor, a virtual API endpoint, or a weather data feed. The abstraction was protocol-agnostic by design, and it unlocked the flexibility for both customer types to feel at home.
Repeating tab
pattern at every level.
L1 shows Spaces, L2 shows Points within a Space, L3 shows Signals within a Point. Same interaction, same layout, different data. Users learn once and navigate everything.
Filter system that
scales with protocols.
The filter needed to work for 6 protocols with different attributes. I built a composable filter system where each protocol contributes its own filter options. No hardcoded protocol-specific views.
The Points list is the
most-used screen
in the platform.
An admin at Stavanger Municipality managing 40+ sensors across five city districts needs to find a specific device quickly, filter by location, and see when it last reported a signal.
The filter system evolved across iterations. Early: Status and Space filters. By MVP v2: a full time-range filter alongside text search. Applied filters render as dismissable chips.
The Signals tab shows the last 10 signals under a green real-time banner. The “Waiting for signals…” loading state uses the same teal. A visual connection that communicates: this is the same thing, just not arrived yet.
-
01
The three-tab navigation model was validated when the engineering team adopted it as their own mental model when building, without any explicit brief to do so.
-
02
The progressive disclosure system reduced the most common early complaint, “this is too complicated”, by letting users start simple and grow into advanced configuration at their own pace.
-
03
The filter chip pattern was adopted in the Spaces view without explicit guidance, because the pattern was consistent enough to generalize on its own.
-
04
The access token flow became the company's internal reference for how to handle irreversible actions. A pattern that outlasted the screens that first introduced it.
-
05
Making the hierarchy visible rather than flattening it was the most counterintuitive decision that held up best. Users could navigate Tenant → Space → Point and always know where they were.
The platform shipped.
The patterns held.
Validation rarely came from user testing sessions. It came from watching
the patterns generalize, to screens I hadn't designed, to teams I wasn't guiding.
At core launch: Stavanger, Porsgrunn, Babysensor, Cemit, Tvillingfabrikken
MQTT, HTTPS, UDP, LoRaWAN, NB-IoT, 5G. One consistent interface.
Stavanger municipality alone: waste, parking, air quality, water levels