Aruba Meridian: Sensors App Project
Who is Meridian?
Aruba Meridian is a cloud-based solution that bridges the gap between the physical and digital world with indoor mapping and asset tracking. Through integration with Aruba’s beacons and tags hardware, Meridian apps provide turn-by-turn directions in a facility, and provide location tracking for valuable assets. Typical clients include organizations and venues like corporate and university campuses, as well as stadiums, airports, museums, hospitals, and retail stores.
As the Product Design Lead at Meridian, I lead the planning, testing and design development for the mobile apps and web content management system.
In the Sensors App Project, I worked with another Product Designer, Mobile Support Engineers, Product Managers, Customers, and Dev Engineers.
Problems + Goals
In this project, we were confronted with the task of designing an all-in-one solution that would allow for maintenance, deployment and troubleshooting for both Tags and Beacons hardware, as well as a new version of hardware being set to release the following quarter.
Problems
Beacons and Tags are deployed and maintained on two separate apps that perform similar functions
New hardware allows for a single sensor to be deployed as a Tag OR a Beacon
Troubleshooting is unreliable
Goals
Create a streamline experience that combines the functionality from the Beacons and Tags app and allows users to deploy, maintain and troubleshoot their hardware.
Original Tags + Beacons Apps
The main problem that we saw with the Tags and Beacons apps was the lack of overall hierarchy and direction, which created a highly confusing and unintuitive experience.
Ideation + Discovery
Most of our research was conducted by interviewing and working with our Mobile Support Engineers, who help customers to deploy hundreds (sometimes thousands) of Beacons and Tags using the deployment apps. We reviewed analytics that were collected from the current apps and were able to identify current pain points we wanted to address.
Since there were so many different types of users and use-cases, we spent a large portion of the design sprint on user-mapping. We mapped users for both Beacons and Tags, and analyzed where the similarities and differences were.
Beacons User Mapping:
Tags User Mapping:
Concept + Flow
Once we began overlapping the user maps and comparing the similarities in user goals, the user flow seemed to create itself. We knew that we needed to simplify the software by combining everything into one experience, but also wanted to respect the separate users and use cases that come with deploying Tags and Beacons.
Beacons User Flow:
Tags User Flow:
Sketches + Wires
As we went into the sketching and wireframe phase, we knew there were some key questions on the forefront that we needed to answer before we could make any significant progress.
How might we allow a user to seamlessly toggle between a map and list view without losing context?
How might we combine the tags and beacons apps to allow for a seamless experience while avoiding overwhelming a user with controls and information they may not need?
Answering these questions were critical in deciding on the infrastructure for the app, so we created low fidelity rapid prototypes to help us quickly test some of the workflows.
Rapid Prototype A
Option A is allowing the content to live in a bottom sheet. The bottom sheet content would be dynamic and always visible
Rapid Prototype B
Option B puts the content in a side drawer (similar to current UX). A big downside to this option is that the drawer space can’t be utilized for other content like the bottom sheet is.
As soon as we made the rapid prototypes, it became clear to us that the bottom sheet was the better solution for the overall structure, and some quick testing confirmed our hypothesis. Since the list view was always visible, it felt more connected and integrated into the map content, and was also much easier for a user to quickly access at any time.
Deployment
Another big problem we had to solve was how a user deployed hardware. Since the user was required to place the hardware on the map, there had to be either an edit state where a user can freely move the hardware around, or a notion of “picking up/dropping” the icons on the UI. We opted for the edit state to make it easier for a user to go back in case they misplaced a beacon or tag.
Mocks + UI
Navigation
Once we were well into our mock-up phase, Meridian decided to deprecate ‘Campaigns’ which was an entity currently living in the bottom nav. Because we were only left with two items in the nav bar, we decided to rework it a bit and added it as a tab overlay on the map.
Another main portion of our navigation was in the bottom sheet. We reuse this UI pattern throughout the experience which allows users to keep the context of the map view while navigating through the list content.
Deployment
We heavily tested the deployment portion of the app because we knew it was a critical to get it right. We found that most of our users preferred to pair their beacon and device automatically, but we still had to account for users who wanted to manually pair them.
Detail Pages
It took some time for us to get the UI of the detail pages right because we had to take into account that not only was there a lot of content, but some of was editable, while the rest was static. We opted for tap-through pagination to avoid having to hide information when an edit state was selected.
Troubleshooting: Walkthrough
Troubleshooting was a big pain point and created a lot of confusion for users. We wanted to make sure we were setting them up for success, so we added a walkthrough that could be reaccessed at any time that walked users through the steps of setting up troubleshooting.
Troubleshooting: Associated Beacons
Another big pain point we discovered early in our research was that users couldn’t figure out which beacons were affecting their Bluedot. We created a troubleshooting mode called ‘Associated Beacons’ which changes the colors of the beacons as you move around your space.
Testing
Development is in progress with this project as we continue to test and make improvements where we see fit. The plan is to release the Sensors app with the new beacon/tag hardware in spring 2020 and we will continue to test and gather feedback as the app is released.