Meridian Search and Discoverability
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 a Product Designer at Meridian, I worked with other designers to help plan, test and design for the mobile apps and web content management system.
In the Search and Discoverability project, I worked with another Product Designer, Support Engineers, Product Managers, Customers, and Dev Engineers.
Problems + Goals
In this project, we were presented with a pretty open question: How do we make Meridian Maps more discoverable?—both in terms of discovering the map space itself, and also being able to discover things within the map.
Problems
Users are struggling to easily search and filter in the current map space
Maps are the focal point of the app, but aren’t the main interface a user sees—often getting overlooked
Users cannot easily browse placemarks on the map
Search is in a separate part of the app than the map—but often times users are searching for things on the map
Goals
Create a unified mapping space that allows the user to easily determine their own experience through filtering, searching and browsing.
Original Map + Search
A huge pain point in the original maps and search interface was that the two were separate - yet, most of the time, users were searching for things that were on the map. Users also landed on the “Featured” page when first visiting the app, which reduced the emphasis on the map portion.
Ideation + Discovery
With this project, we were given a pretty broad problem to solve, but unfortunately we were working against a strict timeline and limited resources—and since we weren’t able to make any changes to the Meridian Editor (CMS), we had to build something that didn’t require a customer to update their content.
In the essence of time, we held one-day design studio to explore current limitations, possible features we wanted to validate, and problems we may encounter along the way—which gave us a much clearer picture on what the project would entail.
A big conversation that came up repeatedly was, users and customers want Maps to be the central focus of the app, but a user can’t see the map until they tap around—why aren’t we putting the map front and center?—and if users are mainly searching for things on the map, why doesn’t search live on the map?
Concept + Flow
Knowing that we wanted to make the map front and center and include search, we began to think about how we would layer search on top of the map and make it one cohesive view. With the user map being so simple, we knew we could design an experience where the map was the central point of interaction.
Sketches + Wires
As we began wireframing, we knew there were some key questions we needed to answer.
How can we allow for searching on the map without a user losing context?
How does an experience differ if a user is browsing/filtering vs. searching?
How will a user navigate within the map interface?
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.
We whipped up a couple quick prototypes to test the incorporation of Search, and decided some version of a split screen would work well to display both a map view and a list view simultaneously.
Overlay UI
Overlaying the UI components puts the search in a button that prompts a full screen modal, and
Pros:
No map real estate lost unless you’re actively searching or viewing details on a Placemark
Cons:
Out of context—can’t see the map while you’re searching/filtering
Harder to reuse UI patterns
Bottom Sheet
Bottom sheet puts a sliding sheet at the bottom of the screen that is always slightly visible.
Pros:
Map can always be accessed—keeps a user in context
Bottom sheet UI can be used across map space
Cons:
Limits screen real estate even when you’re not searching/filtering
After some validation, we opted for a map view with a bottom sheet, as it allows the user to keep the map in view regardless of where they navigate. We also felt that by using a common pattern seen in other mapping apps, it would increase the likelihood that a user would feel comfortable in the space.
Mocks + UI
One thing we really focused on in the mockup phase was what would show up when a user tapped the search bar. We wanted to offer the ability to search, but also options for quickly filtering the content. Since we were designing for many different types of customers, we knew that not all users would be interested in the same filtering options.
We worked closely with the Product team, Dev team and some of our users and determined that there were, in fact, common desires for quick filter categories [eg. Restrooms, Elevators, Nursing Stations]. We decided to select a default list based on the research we did, but also allowed the Customer to edit this in the Meridian CMS Editor.
Android
Since the bottom sheet is more of a common pattern on iOS, we designed a slightly different experience for Android that was more aligned with their common patterns. The main thing that differed was the bottom sheet was prompted by the Search icon. Since this is a common UI pattern in Android, we felt confident that our users would be familiar with this UI.
Testing
We tested on users throughout the process to ensure that we were catching any possible problems, and used the opportunity to ask open-ended qualitative questions about their experience with our products. We worked with a tight script and specific steps, as well as organized our tests into a spreadsheet which scores user tasks on a scale from 0 (didn’t understand at all) to 2 (performed with no issues).