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.

Maps.png
Search.png

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.

whiteboard.png

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.

 
ezgif.com-crop (1) 3.gif

ezgif.com-crop (1).gif
 

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

ezgif.com-crop (1) 2.gif
ezgif.com-crop (1) copy.gif

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.

S-D.png

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.

S-D-Android.png

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

By doing this, we were not only able to stay organized while continuously testing throughout the process, but it also made it easy to compare past testing results.

By doing this, we were not only able to stay organized while continuously testing throughout the process, but it also made it easy to compare past testing results.

Previous
Previous

Meridian: Mapping Editor

Next
Next

Trusty Brewing Beer Labels