Interact Landmark Monitor

Project Background

This project's purpose was to redesign and rebrand the legacy application Philips Activesite.  The application had lived in research and was originally designed by Research and Development without a UX designer. Once market value had been demonstrated it moved to my team to be given a redesign and rebranding. 

This web application monitors the health and status of large outdoor lighting installations (used on Empire State Building, Bay Bridge, and One World Trade Center). The user of the application ranges from internal Philips Employees who are Application Engineers and maintain the installations remotely to Building Managers who oversee the buildings these lighting installations on-premises.

The redesign project also happened while Philps underwent a restructure.  All cloud-based applications such as Active site would be under the brand umbrella of Interact. Interact would have its own look and branding separate from Philips/Signify and Active Site would be a pilot application for the new Design System that would then scale to 38 other applications.  

The Process and My Role

My role on this was project was Creative and UI lead. This project was developed in an agile team with the Product Owner, Project Manager, Software Architects, and myself. I started with user interviews alongside an internal People Researcher and the Product Owner.  I also held a Design Thinking workshop to understand the user needs across all applications in the eco-system of Philips Color Kinetics lighting.  Once we had an idea of what the main jobs to be done were and features that were widely used the team and I began the process of breaking up the redesign into parts so we could deliver small pieces often - rather than a new application all at once. 

The Outcome

This project launched under the new brand as Interact Landmark in  2018 and was made to be flexible enough to add features that the company was testing out as future stand-alone applications such as social impact, scene management, and sensor API integration. By keeping the framework flexible and scaleable this product became the pilot application to host initiatives coming out of the research department and test them on large-scale projects without needing to build their own application. 

 

The customer got an application that works better for their purposes - we cleared out the clutter and extra data points no one was using from the dashboards.  Redesigned the navigation to scale for anywhere from 10 - 100k lights, and created a platform from the original application that would allow for scalability in the future. The company delivered a platform rather than a stand-alone application that allows it to easily test new concepts on large lighting projects without a lot of rework. And the end-user ( citizens who observe the lighting installations) experience less downtime because the monitoring system is simple enough to use that a Building Manager can diagnose a problem within 20 seconds of an outage. 

Open Site Alerts

Open Site Alerts

This page would be where a user can see all open alerts on a site.

Old Site Experience

Old Site Experience

The old site experience was created by engineers for end users. They pulled any and all information available to them and surfaced it all to the user. After conducting interviews with end users their biggest pain point was too much irrelevant data. We determined that the info that is most important should be easy to find but all data should be available, just not at first glance. The other major issue was the device tree took up a majority of the screen.

ckeco- 2

ckeco- 2

Customer Journey Map

Customer Journey Map

Maping business needs v user needs

Maping business needs v user needs

Device tree level 1

Device tree level 1

This page shows how the user would land on the site and navigate to a particular asset. The design of the device tree was the largest undertaking because the current application requires this to be on the page at all times which took up page real estate. However once a user navigates to the problematic device they don't need this again. So I designed a device tree that could be collapsed and pinned to the top left corner.

Device tree expanded

Device tree expanded

This is the device tree at its most expanded level where the user can see the list of fixtures as well. It also gives the user a quick visual que if the device is online or offline and if the last scan is current for that device.

Device tree collapsed

Device tree collapsed

This page is the state of the page after the user has navigated to the fixture that is problematic. I felt it was important to keep the search box there because that was how users most commonly wanted to navigate to a fixture.

chart modal

chart modal

Because of the dense information on the main page we felt that the user might want to get more infomation about a chart and see them larger. For this we took the approach of having each card be clickable and expandable.

report page

report page

Reporting is one of the main tasks that was messy before the redesign. The previous design compiled everything they could pull without considering if the user needed that data.

report page pop

report page pop

By adding the ability for users to easily customize their reports based off all the data pulled it would allow the users to keep the reports as simple as they needed. It also allows for scaleable reports for when the fixtures have new sensor data.

how to switch apps

how to switch apps

When the project was midway through there was shift in strategy to allow Landmark change from a app to a platform with many apps.

switch apps

switch apps

By adding the ability to change the app from the global navigation users can easily toggle between apps.