Navigation paradigms for
multi-platform experiences
The refreshment of the Design Language System brings the opportunity to look at the current design holistically to find out what could be improved. I led the research, analysis and ideation phases to re-think and re-design the navigation framework for a cloud-based software portfolio in the exploration and production industry.
MY ROLE
UX Researcher
UX Designer
INSTRUMENTS
YEAR
Survey
Moodboard
Discovery workshop
HMW
Heuristics
Lo-fi wireframes
Mid-fidelity prototypes
2021
The challenge
A design language system is supposed to be a guideline for designers to create consistent experiences across products and channels of a family of products. Although there was already a 5-year old design language system to serve over 30 web-based applications, less than 50% of them were using it. The goal of this project was to define a new framework that could meet the needs of the different domains and applications to facilitate adoption.
Strategy
Before starting designing, we made sure that we were asking the right questions and solving the right problems. The initial research questions were:
-
What are the business drivers?
-
What are the trends?
-
What are the challenges of the current DLS (2.0)?
-
What are the ultimate goals that we want to achieve?
-
How will we measure success?
We took a user-centered approach under two lenses:
1. The UX Community as our audience. They interact with the library and decide the components that they will use in their applications.
2. The end-users of the applications. Although they don’t use the library directly, they are the ultimate receivers of the designs that the UX designers created for them.
Research
First, we looked for inspiration in other domains to learn about trends in Navigation and Interaction in complex applications. Our main goal was to set ourselves in a diverging mood, rather than solutioning.
Then, we ran a survey with business stakeholders, the UX Community and technical teams to know how the DLS 2.0 was perceived. The main findings were that:
1. The DLS 2.0 is perceived as of good quality
2. There were opportunities in the completeness of the library and guidelines
3. Some teams had not adopted it because they didn’t consider it a priority
4. Some teams had not adopted it because they found it difficult to implement
Based on the results of the survey and what we had heard from the UX community we framed 2 initial challenges:
How might we facilitate easier adoption and implementation?
How might we provide better guidelines?
In order to have a better understanding of the specific opportunities we had in the current DLS, we held 2 workshops with the UX Community of 14 participants each.
They were scoped to Navigation, Interactions and Templates, which where recurring topics in the Survey.
The frameworks used to classify findings were:
-
User: UX/UI Designer or Application user
-
Category: Navigation, Interaction, Templates and Documentation
-
Nielsen Norman Usability Heuristics (https://www.nngroup.com/articles/ten-usability-heuristics/)
Analysis
By identifying the users, the type of issue and heuristic, we could easily see where the opportunities of improvement were. When filtering the issues that affected designers vs end-users, we found that:
40% of the issues affect designers directly
60% affect designers and end-users
When UX teams find that the assets provided by the DLS do not meet their needs, they often customize and design their own components. This takes time, affecting the designer directly. Each team ends up with a different design to fulfill the same need and ultimately, the user is also affected by finding inconsistent experiences across DELFI.
51%
Of identified issues fell under the heuristics of
Efficiency of use and User control and freedom
Design
We prioritized the items that were affecting designers and end-users and moved on the the Design phase.
We did some exploratory concepts based on the trends that we looked at in the inspiration exercise. We focused in identifying how other products where meeting simiilar needs to the ones we identified in our Research.
These exploratory concepts were presented to the UX Community with the goal of capturing their first impressions
1. Horizontal Navigation
The first level of navigation is available on the top menu. If more items
The second level through dropdowns
The third level of navigation is available in the canvas horizontally, next to the selected Title in the second level, allowing the user to see the three levels at all times.
2. Megamenu
Horizontal menu supporting 3 levels of navigation. Once the desired section is selected, the menu disappears and the whole canvas can be used without any menu taking space.
This type of navigation is common in e-commerce sites where there are many categories and subcategories to choose from, giving with one click or on hover a general idea of the contents of the site.
3. Two-level side-panel
Supports 2 levels of Navigation in the side panel plus a Global Navigation panel that allows users to go to other DELFI apps or to the DELFI portal. It also provides quick access to recently opened projects/workflows.
A third level of navigation is available in the canvas as tabs.
Validation
The concepts were shared with the UX Community with editable Sketch files for them to make their own tests and mock-up their own applications with the proposed solutions. While some found horizontal navigation useful because of the use of space in the canvas, others preferred left-side panel to have affordability for more menu items at the first levels of navigation. After some rounds of feedback, we found that:
-
The new Navigation framework should be consistent, but flexible. One design was not better than another but rather better for one scenario
-
Navigating to other Apps was valuable, but not useful from the top level navigation, since that would not be a main nor recurring action.
-
The progressive side panel had potential but if we supported infinite levels, it would become complicated to go back
-
The interaction of the logo had to be consistent across apps.
-
We needed to provide navigation hierarchy and data hierarchy (context selection)
-
Side bars should overlay, not push the content