Case Study
IoT_Apro
Designing a smart access app that works for someone opening a gate and for an admin managing hundreds of simultaneous accesses.
Client
ConsultaMe s.r.l.
Year
2025
Type
Mobile App
Role
UI/UX Design, Design System, Prototyping
Deliverables
Mobile app design, Design system, Icon set
Tools
Figma, Notion
One app, two mental models
ConsultaMe came to me with a working IoT backend and no design layer. Their system managed physical access for smart buildings — gates, barriers, elevators, intercom systems — through a network of connected devices. The engineering was solid. What they needed was a mobile interface that field technicians and property managers could both use without either group being forced to navigate through the other's workflow.
The challenge wasn't purely technical. Technicians and managers share data but have completely different goals. A device going offline means "schedule maintenance" to a manager and "check firmware, pull diagnostic logs, call the hardware team" to a technician. The same notification — opposite required actions. One app. Two mental models. No prior design work to reference.
The constraint that defined the whole project: no dual-app solution. ConsultaMe had one codebase, one product, one support team. Every design decision had to hold up for a property manager approving access requests from a desk and a technician troubleshooting a gate controller in a parking structure in January with gloves on.
Visual language for a technical product
Before designing a single screen, I mapped the full color and type system. IoT interfaces carry a specific visual burden: status needs to be legible at a glance, error states need to stand out without crying wolf, and the interface has to work in bright outdoor light as well as a dim server room. I built a palette that separated semantic color — status, alert, confirmation — from brand color, so neither system contaminated the other.
The type scale was built around the same logic. Information density varied between roles, but legibility couldn't. The accessible density level — the default for technicians working outdoors — required a minimum 16px body size, wider tap targets (48×48px minimum), and high-contrast status states. Managers got standard density, with more information per screen and a reduced icon footprint.
The role-adaptive navigation was the core structural decision. Rather than two separate apps or a flat permission layer that just hid certain screens, I designed a context switch at the root level. The navigation, information hierarchy, and default views all shift when the role changes — not by hiding content, but by reweighting it. A device status card that shows a one-line summary to a manager expands to a diagnostic panel for a technician.
The technicians kept asking me to add more. That's when I knew the density system had worked."
Reflections
What I learned
The hardest part of this project wasn't designing the screens — it was convincing two groups of people with different priorities that they could share an interface without compromising either side. Technicians assumed a manager-facing app would be too simplified for their needs. Managers assumed a technician tool would be too complex to navigate quickly. Both assumptions were reasonable. Neither was accurate.
The role-adaptive architecture was the answer, but it required trust before it could be built. I created an early prototype that showed the same device data rendered for each role side by side: same underlying information, completely different presentation. Once both groups saw that their view wasn't a stripped-down version of the other's, the conversation changed. Engineering stopped pushing for two apps. Product stopped worrying about scope.
The density system was a late addition that became central to the product. The original brief called for a single layout. I added density levels after visiting a building site in Pomezia where a technician was squinting at a small font label through safety glasses in direct sunlight. Adding three density levels extended the timeline by two weeks. They were worth every day — the accessible level ended up being requested by several managers too, particularly for field walk-throughs.
If I could redo one thing: I would have introduced the icon set earlier. The custom IoT iconography — device types, connection states, permission levels — became a communication tool that accelerated conversations with engineers once it existed. I spent two weeks mid-project describing things in words that a symbol would have made instantly clear. Starting with a rough symbol vocabulary from day one would have shortened every meeting in the middle phase of the project.