Hero image for Maya

Maya

a comprehensive overview of a portfolio of buildings

Keywords
Product designFrontend developmentUI/UXInformation architectureBuilding monitoring/maintenanceReportingSchedulingDynamic ChartingAlarms & notifications
Tools used
SketchAngularSCSSD3.jsGoogle Maps APITrimble Sketchup

Goals

Maya was designed to solve a fundamental accessibility problem in building management systems. Its predecessor, Brightedge, was a web application built primarily by engineers for engineers. While it was functional, it was increasingly clear that it had reached both technical and marketing limitations. The interface assumed deep technical knowledge and lacked the clarity needed for broader audiences.

RiptideIO wanted to expand its reach beyond facilities operators to include decision-makers in the executive suite. These stakeholders were responsible for operational and financial oversight of large portfolios of buildings, yet they lacked accessible tools for understanding the health and performance of those assets. Maya was conceived as a platform that could bridge that gap.

At the same time, the company was rapidly expanding its product capabilities. New tools were being developed for data visualization and analytics, visual programming, equipment visualization, reporting, scheduling, alarm triage, and equipment controls. Maya needed to serve as the epicenter that unified all of these capabilities under a coherent interface.

To guide the design, we adopted a deceptively simple rule: a user should be able to navigate from a global overview of their building portfolio to a specific piece of equipment in four clicks or fewer. Achieving this level of navigational clarity across thousands of assets was a significant challenge, but it became the north star for Maya's information architecture.

Overview of a single building in the Maya interface

Insights

One of the most important insights was recognizing that different user groups conceptualize buildings in very different ways.

Building operators tend to interact with their systems much like emergency responders or nurses in a hospital setting. Their role is reactive and vigilant. They monitor alarms, anticipate operational events such as weather-related energy spikes, and need quick access to controls and diagnostics when something goes wrong.

Executives, on the other hand, interact with buildings from a strategic perspective. They are less concerned with individual sensors and more interested in identifying trends across a portfolio. Their focus is on operational efficiency, cost management, and identifying outliers that may signal larger problems.

Designing Maya required supporting both of these mental models simultaneously.

We also studied patterns from adjacent tools. Our analytics and charting capabilities borrowed inspiration from platforms like Tableau, which had already established effective paradigms for data exploration. Equipment visualization drew from tools commonly used in HVAC systems from manufacturers such as Trane and Carrier. While these products offered valuable precedents, many required deep technical expertise or suffered from poor UX decisions that limited accessibility.

Finally, conversations with operators revealed a critical priority: alarms had to be front and center. As one operator put it, "I need to see those alarms before my boss does." This insight reinforced the need for clear prioritization and rapid access to critical alerts.

A custom graphing engine was one of the core features in early versions of Maya

Drilling into the graphs showed more granular data

A study of different ways to treat notifications in the Maya interface

Constraints

Maya's challenges were not limited to the interface.

On the technical side, the system relied on a complex network of wireless protocols and microservices communicating across distributed building infrastructure. Failures could occur at multiple levels, which meant error states needed to communicate problems clearly without disrupting the broader application.

Organizationally, the product was evolving rapidly. I was the sole product designer responsible for supporting a wide and expanding feature set. The interface had to accommodate frequent iteration without becoming brittle or inconsistent.

Another key constraint was the diversity of users. The platform needed to function equally well for operators managing real-time alarms, technicians investigating equipment performance, facilities managers coordinating maintenance schedules, and executives reviewing high-level analytics.

Concepts

Maya's architecture was built around a hierarchical model that was fixed at the lowest levels but flexible at the top.

At its core, the structure followed a predictable pattern:

Building → System → Equipment → Sensor or Control.

This ensured that any asset could be located reliably within the hierarchy. However, the upper levels of the structure were intentionally flexible. Users could organize portfolios by geography, grouping buildings by country, region, state, or city depending on their operational needs.

The interface itself relied on layered navigation patterns. A narrow, fixed sidebar provided access to the platform's primary feature areas, such as the portfolio view, scheduler, and analytics tools. When a feature was selected, a secondary navigation panel appeared beside it, providing deeper access to that feature's hierarchy.

Additional controls were introduced through contextual elements such as filter bars across the top of the interface or slide-in drawers that revealed supporting tools without disrupting the primary workflow.

Each major feature required its own internal hierarchy, but consistent patterns allowed users to move between them without relearning the interface.

I also introduced hierarchical filtering and alert prioritization systems to help users manage large volumes of data. One particularly enjoyable design challenge involved creating isometric equipment diagrams that simulated three-dimensional rotation, allowing users to explore building systems in an intuitive visual format.

Tradeoffs

Designing Maya required constant tradeoffs between flexibility and clarity.

RiptideIO already had a functioning application in Brightedge, but that platform had accumulated security concerns and architectural limitations that made further expansion difficult. While Maya was built to support the company's future, we also had to ensure that it could deliver value quickly.

Another challenge was balancing the breadth of features with interface simplicity. The platform included a wide range of capabilities, each with its own complexity. Establishing strong foundational patterns early allowed new tools to integrate into the system without introducing unnecessary cognitive load.

Not every workflow fit neatly into Maya's structure. Equipment onboarding and provisioning, for example, required a completely different approach. These tasks were often performed outdoors, sometimes without reliable internet access, and frequently on devices without traditional input tools like keyboards and mice. As a result, provisioning interfaces relied more heavily on simplified forms and clear connectivity diagnostics rather than the hierarchical navigation patterns used elsewhere in Maya.

Impact

Maya significantly improved how building operators and executives interacted with their data.

Operators were able to triage alarms much faster and respond to issues proactively. Earlier visibility into system problems allowed technicians to prepare more effectively before arriving on site, reducing downtime and improving operational efficiency.

Executives gained the ability to explore building performance from both a macro and micro perspective. They could identify trends across large portfolios while still drilling down into specific equipment when necessary. Automated reports and real-time dashboards made building performance more transparent across the organization.

The platform's success also had significant business implications. Enterprise customers began requesting white-labeled versions of Maya, prompting RiptideIO to expand its B2B strategy into a B2B2C model where industrial companies could deploy the platform for their own clients.

Internally, the creation of a comprehensive design and component library allowed the engineering team to develop new features much more efficiently.

Ultimately, Maya became the central hub for RiptideIO's entire ecosystem of building management tools. Its success also played a role in the company's eventual acquisition by Turntide Technologies, which sought to integrate Maya into its broader portfolio of IoT infrastructure and equipment control systems.

© 2026 Zak Erving
built with ❤️ from scratch👨‍🍳