Designing a Shared Visual Language for OpenRemote
I joined the OpenRemote team at the start of this year as a UX/UI designer. Coming into an open source platform that engineers have been building and refining for years, the first thing that struck me was how complex and versatile the system is. The Manager does a lot: connecting devices, automating logic, and visualising data across energy, cities and asset management. There’s a lot it can do, which is also what makes it hard to get to grips with at first.
I care a lot about consistency in an interface: hierarchy, spacing, typography, colour, the way controls behave, and how they add up to something that feels coherent. There wasn’t yet a single shared visual language, or the kind of repeating patterns that help people get familiar with new concepts quickly. We were also working with an outdated component library, one that needed replacing to keep us on solid ground for the next few years. That’s natural for a product that’s grown feature by feature, solving real problems as they came up. It’s also exactly the kind of thing I like to bring order to.
So since January, I’ve been building a design system for OpenRemote.
Rather than start from a blank canvas, I built it on top of Vaadin. It gives us a supported, well-documented foundation of the building blocks every interface needs: buttons, input fields, tables, and the variables that make customisation easy. Instead of spending time on the basics, we can build the components specific to OpenRemote and improve the experience around them. It also keeps design and development speaking the same language. What I draw in Figma matches what we can ship, which gives us a single source of truth instead of developers guessing how things should look.
Most of this has been the kind of work that stays invisible until it isn’t. That’s about to change. Over the coming months we’ll roll out our first UX/UI improvements built on the new design system, starting with the Vaadin base components. Small steps to begin with, but they’re the first visible results of a more consistent, considered direction for OpenRemote, and there’s plenty more coming.
We’re also talking with clients and users to learn how they actually use the Manager: what’s blocking them, and what they’ve built themselves. Those conversations surface flows we never planned for, and they shape the changes I work on day to day. Because the product is open source, something a user builds for their own needs can end up as a core feature that benefits everyone else. Part of my job is making sure those additions are integrated properly and fit the rest of the system.
If you use OpenRemote, I’d love to hear what you think as these changes land, contact me at remy.berden@openremote.io, I’m always open to discuss feedback.