Enterprise Vue


Company Lutron
Project Duration
1 year

My Role
User Research
UI Design & Testing
Project Leadership

The Team
1 User Researcher (me)
2 UI Designers (me)
1 Visual Designer
1 Business Analyst
1 Product Manager
10+ Engineers

What is Enterprise Vue?

Enterprise Vue is a web-based software for Lutron's largest building management system. It empowers facility managers to make data-driven decisions on energy saving initiatives, space utilization and the automation of lighting & shades. The system also alerts electricians when equipment needs maintenance.

Dashboard_2x.png

The Motivation

Before Enterprise Vue, Lutron’s largest smart building solutions were limited to a single building. However, Lutron’s top markets (universities and commercial offices) are often multi-building campuses. For these customers, Lutron systems were installed in several buildings / parking lots and facility managers desired a “single pane of glass” to manage their campus needs. With emerging competition in the market, Lutron needed to stay ahead of the game by providing a more streamlined experience for campus-based users.

Current-Desired.png

The Outcome

Enterprise Vue is more than a superficial layer on top of existing Lutron systems. From our team’s research, we discovered that our campus users had different needs for data analytics and system control than our single building users. We designed for these use cases and tested with users to make sure we were hitting the mark. Enterprise Vue launched mid-2018 and was one of Lutron’s featured products in the nation’s largest annual lighting trade show.


The Process

User Research

 

The Research Objective

Since Lutron already had solutions at the building scale, the research objective was to understand how the user needs differed when it came to a campus scale.


Site Visits - Empathizing with the users in Person

The Research

I conducted a contextual inquiry at two university campuses. This gave me first-hand & in-context exposure to the user needs. At each campus, I met with several people in facilities roles: electricians, building automation engineers and energy managers.

Key Takeaways

I learnt that the two campuses divided facilities responsibilities in different ways. One team divided their campus into “fiefdoms” and each member was responsible for all facilities-related issues in their few buildings. The other team divided responsibilities by function rather than by space. For example, certain members were responsible for replacing lamps & batteries, while others were dedicated to meeting energy saving objectives. The second group especially suffered with the current experience. They had to login to each building system separately to tend to maintenance alerts. Furthermore, their analytics data was fragmented, which made holistic energy saving or space utilization decisions difficult.

Responsibilities.png

Phone Interviews - discovering the Detailed use cases

The Research

After the site visits, I had a broad understanding of the experiential problems. I conducted 5 phone interviews to understand the details of what users needed in their maintenance alerts, their energy data and their space utilization data. Since I was only able to do site visits on universities, I made sure to include commercial offices in my phone interview data set.

Key Takeaways

For each topic, I extracted out the main use cases, shown below. These served as the basis for design when we began ideating on UI designs.

Use Cases.png

UI Design & Testing

 

The Design Process

Working in Sprints

As the project leader for UX deliverables, I designed a process that would allow us to work in parallel with our development team. We worked in 4 design sprints that were each 2-3 weeks long. At the end of each sprint, we delivered a piece of the complete design that developers could start implementing.

Divergence & Convergence

For each piece of design, we first generated several ideas in the form of sketches to encourage out-of-the-box thinking. We assessed each design against the use cases discovered through research and selected 1-2 concepts for user testing.

User Testing

For each piece of design, we mocked up a clickable prototype and user tested it with 1-3 facility managers. After incorporating our findings, our visual designer worked to get each interaction design to a high fidelity state.


Sprint 1: IA & Navigation

In the first sprint, we focused entirely on the information architecture and navigation experience since this was key to our user’s mental model of connecting their existing building-by-building data into an aggregated campus experience.

In our design, we used a campus map for navigation rather than a list of buildings. This allows a facility manager to intuitively get to a particular room on campus. We also supported search at the global level for users who already knew where they wanted to go.


Sprint 2: ENERGY

Navigation to Energy

We designed quick details about energy savings to be displayed on a the energy tile of the campus dashboard. From there, the user can click into a more detailed display of data and switch between two views.

Energy Consumption

The first tab within the energy page displays consumption against the connected load of each building. The connected load represents the “energy size” of a building, or how much potential it has for savings. Buildings of a large energy size and a high consumption are the biggest opportunities for further savings.

Energy Savings Across Strategies

The second tab within the energy page displays the energy savings of each building broken down by the various strategies that Lutron offers. The horizontal bar graph design allows for easy comparison across buildings. From the data below, a facility manager may think of installing occupancy sensors and daylight sensors in Building B, F and G.


Sprint 3: Space Utilization

Navigation to Space Utilization

Similar to the energy workflow, space utilization data is also accessible through a tile on the main campus dashboard.

Space Utilization Details

The inner page displays the utilization of buildings from least to greatest. This allows a facility manager to quickly identify buildings that underutilized and could be used for more employees / classrooms / etc.


Sprint 4: Alerts

Navigation to Alerts

Alerts is the last tile accessible through the main campus dashboard.

Alerts.png

Alerts by Type

The first tab displays each type of alert and how many there are across the whole campus. The alert type can be expanded to show how many are in each building. With this view, the facility manager can determine if it’s time to do a wide-spread maintenance activity such as replacing lamps across a few critical buildings.

Alerts1.png

Alerts by Location

The second tab displays how many alerts are in each building on campus. The building can be expanded to show how many alerts there are of each type. The facility manager can use this view to determine the overall health of a building,

Alerts2.png

Preparing for Launch

After each feature was implemented, we worked with the development team to review the work for usability and accuracy to the specification. Before the system reached our customers, we also installed the system in our own building and experienced real-life data first-hand. We made small improvements to the design before finally launching.

The Final Product

 

Navigation


Energy


Space Utilization


Alerts

Alerts1.png