onX Maps
Shifting a navigation framework
Setting the stage
When I joined onX Maps, I discovered that what people had been calling a design system was actually just a Figma toolkit with little connection to code assets.
After a lot of wrangling, presentations, alignment, education, meetings, Slack messages, and relationship building, we were in a position to start building components. We had a good foundation of tokens and documentation to fuel the next stage.
Information gathering
By conducting a UX analysis, I gained clarity on the most common components across our experiences. This allowed me to gather in-depth knowledge about each component.
Getting the community involved
I had a pretty clear understanding of the most heavily used components, but were there things I overlooked? What about what people are currently working on?
I saw an opportunity to get validation and get people invested in the design system roadmap.
Validation
The results aligned with what I saw. Plus, I was able to begin to form common terminology amongst a number of people by roughly illustrating each component.
The most prevalent component: what people internally referred to as “card.”
Separating web and native components
The company referred to the component as a 'card', regardless of platform or interaction patterns. As I began using my secondary research sources and having sessions with my engineering partners, it became apparent that we needed to split the component into two.
Technical constraints
During sessions with the engineers, I began to understand the intricacy of the bottom sheet, especially in relation to the onX products. In particular, the interaction patterns in connection with the map. At first glance, it seemed like a straightforward component. However, there were numerous elements that needed to be defined to create a solid API.
1:1 sessions & workshops
During UX analysis, I saw a lot of inconsistencies within each product. This led me to investigate further with individual team members. Each team member tended to have a strong opinion on what the end solution would be. Many times, they were opposing views. So, I gathered the team back together for a workshop to establish a mutual understanding of the bottom sheet, collect use cases and feedback, and initiate the exploration of any existing research or knowledge.
Customer insights
We identified key user flows, which allowed us to swiftly move into creating prototypes. These prototypes were crucial in ensuring that our team's efforts were cohesive, documenting any emerging patterns, pinpointing content gaps, and breaking down the work into manageable tasks.
Accessibility recommendations
As WCAG is primarily focused on web, I used what I could derive from its recommendations and used other secondary sources for native experiences. I then made decisions about elements that were under discussion within the design team.
Design exploration with a navigational paradigm shift
Research, insights, and workshops pointed towards a significant change in navigating from one sheet to the next. This change was made to accommodate deeper content flows emerging in multiple product areas, helping give users a sense of place.
Engineering alignment
With a new navigation paradigm, we wanted to ensure that all possible scenarios were considered and that each party was fully aligned on the intended result. This process continued for as long as the engineers had questions—and there were many of them. I used quick sketches to help me visualize their questions and keep track of the response.
Design decision document & Figma component creation
After the workshop and design-sharing session, I received numerous messages with questions, comments, and preferences about the direction. Because of my knowledge gathering, I felt confident in the way forward and needed to communicate those decisions to the team. I prepared a document that we reviewed to gather all differing opinions in one place.
I consolidated all the documentation, specifications, and notes in one place to make the information easily accessible. Since it was the first component in the system, I established the framework and guidelines for its creation.
Testing
Learning is never done. The team is partnering with others to A/B test this critical component, specifically about including three detents. I also conducted usability testing focused on the navigational paradigm to create a clear path forward and better experiences for our users.
Generally, the bottom sheet and sheet header matched user expectations.
Participants understood navigation and moved between bottom sheets successfully by quickly accessing the back arrow navigation.
All participants used swipe functionality to increase or decrease the height of the sheet, with some seemingly forced to use internal scroll if they selected a specific area of the sheet to swipe. This indicates that follow-up work should be considered for internal scroll interactions.
Closing by swiping and/or tapping the map was generally used and understood. However, future consideration should be made to include an "x" close button across all sheets to increase completion and understanding of this close functionality.
Comprehension increased as participants were asked to perform similar actions. This suggests that it's important to maintain consistency within each app to enhance understanding of basic functionality.
Outcomes
Customer experience teams have noticed a decrease in the number of inquiries and comments from users who accidentally lost their work.
The UXR team has observed that participants are able to complete tasks more seamlessly when using the new approach, indicating improved usability.
There is much more consistency throughout each app due to high adoption rates.