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.
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.
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.
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.
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 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.
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,
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.