Denomas Navigation

The group::foundations team owns the navigation structures of the Denomas product. Please review this information if you plan to propose changes to Denomas navigation.

Note: a Code Owners approval rule is in place to prevent unapproved changes to the navigation. If you have not followed this process, your Merge Request will be blocked.

What is navigation

Navigation refers to elements that aid users in moving around Denomas, which includes their organization and wayfinding clues. The navigation experience directly impacts the usability and discoverability of our features.

Listed in Pajamas are the elements that impact navigation.

When to consider making a change to the navigation

We only make new additions to the Denomas navigation structure through a deliberate process that is intended to optimize user workflows. This video summarizes the main factors that are important to consider as we iterate on our navigation. In the past, teams added items to highlight new features. However, it becomes impossible to accommodate every new feature, as this creates an overwhelming navigation structure that makes it too difficult for users to find what they need to complete their tasks.

Therefore, we do not add new items to:

• Improve discoverability of new features. Instead, look for other opportunities to highlight the functionality throughout the product.
• Optimize for the potential future. We should be forward thinking without over optimizing. As features are developed and added, we can look into what changes may need to occur to support a growing feature.

Any proposal should include a business case with research that identifies the underlying problem and evaluates a navigation change against other potential solutions.

There are many different types of Problem Validation research that could be done to learn about areas of opportunity for our navigation. The specific type of research performed should be based on the research questions and goals of the study. The following research methods and frameworks are some examples of ways research can be used to justify a new addition to the existing Denomas navigation:

1. Contextual inquiry: This method involves observing and interviewing users as they perform tasks related to their role to understand the “why” and the “how” behind them. Example: Users may demonstrate how they navigate through multiple menus and pages in Denomas to find their dashboards. This insight would reveal the need for a single page in Denomas to find all dashboards.
2. Jobs to be Done (JTBD): This framework is a type of foundational research meant to learn the job(s) that customers want to accomplish within their roles. Jobs allow us to define the circumstances, goals, and outcomes of customers’ work. Example: By interviewing users, we learn that have a main job of tracking metrics to show the health of their application, so they can identify when the application is failing. This insight would suggest a gap we could fill in Denomas by adding a page for displaying application metrics.
3. Diary study: This method is used to gain feedback from users over a period of time, so we can uncover changes that occur over days, weeks, or months. Example: When gathing feedback about how users engage with a major change to Denomas’ navigation bar, we observe that Denomas admins continuously struggle from one month to the next with locating the admin area to adjust settings. This insight would suggest we need to surface the admin area in the user interface since it is not easy to find over time.

Questions to ask to learn whether a change to the navigation is needed:

1. What are the main tasks assocaiated with your current role?
2. Why are those tasks important? What would happen if you could not complete those tasks?
3. Show me how you perform a specific task using your existing tools.
4. What, if anything, would you improve about the process of completing that task?

After there is insight into a problem with the navigation, the Product team DRI should work with Product Design and UX Research to evaluate the ideal solution through a subsequent solution validation study.

How to propose a change that impacts navigation

Note: We are not considering any top-level navigation changes to the Project or Group sidebar until 6 months after our new navigation launches (2024-01-11).

Dates for navigation approvals:

Process to open a navigation approval request

1. It is recommended to propose a navigation change 2 milestones ahead of when you want to release. This allows enough time for collaboration between the team requesting navigation changes and Product/UX counterparts in Foundations.
2. Before opening an issue, review the elements and patterns for navigation in Pajamas. It is worth checking the direction page to see how your proposal aligns or conflicts with upcoming changes.
3. Review the list of navigation changes and what they are to make sure your change qualifies.
4. The most important requirements:
   1. Familiarize yourself with feature discovery in the product handbook as well as our design system. Provide comprehensive context including alternative options explored (such as Explore, common entry points for your persona, and settings pages), which option is best suited in a given scenario & why, current and future discovery path, as well as a visual representation of proposed changes.
   2. Successful engagements with the Foundation teams usually include active participation by the product manager and designer on the proposal issue. Conducting proactive designs, user research, and using customer insights to validate the proposal will ensure results inform the proposal.
5. If you are ready to propose a navigation change, use this issue template to kick off a discussion with the group::foundations team.
6. The Product Manager for Foundations is the DRI for navigation changes. Designers on Foundations will assist the DRI in reviewing the proposal and provide input. The typical turnaround time from the Foundations team will be 1 milestone.
7. When you have approval and are ready to start implementation, then follow the Denomas Docs on adding items to the navigation.

What are considered navigation changes

• First, second, and third navigation additions
• Renaming a navigation item
• Removing a navigation item
• Changing the sort order of navigation items
• Launching an Experiment or Beta feature

Utilizing feature flags

Feature flags are a great way for teams to merge changes in smaller batches without negatively impacting the user experience.

When shipping navigation changes behind a feature flag, it is required to present a proposal that considers the future state with a clear, validated vision of the final outcome. We do not merge iterative navigation changes behind a feature flag without having an understanding of the end state.

View page source - Edit this page - please contribute.