Skip to main content

Design thinking in action: Improving the UX of the navigation panel

Dariusz Dudek, 9 minute read

This article is part of Pega’s Design-Driven Development series, in which we showcase design thinking in action. This article discusses an example of a solution implemented in Theme Cosmos on Pega 8.6 only.  

Imagine, for a moment, that you are an enterprise user working in an application. You’re using a navigation bar frequently to move between different areas of the application. However, the navigation may take up space that prevents you from seeing the full screen that you’re currently working in. You want the navigation bar to close automatically when not in use, so that it does not take up space on the screen and distract from your work.  

The problem? The navigation bar tends to collapse while you’re still working in it. This not only leaves you confused and frustrated, but also prevents you from accessing actions and completing tasks quickly. And you don’t have time to exit manually from the navigation, nor is that a behavior that you expect of a sophisticated application.  

This is an important problem to solve because a confusing UI experience can hinder a user’s workflow. And in this scenario, where the navigation bar houses critical information, it’s especially important for users to work with it intuitively.   

That said, this problem is not as simple as it may seem: first, we had to figure out the exact timing by which to collapse the navigation; and secondly, we had to understand how users would behave, as well as overcome any assumptions about that behavior.  

In this article, we'll discuss how we used a combination of design thinking and an evidence-based testing approach to come up with a solution that made sense both for the users and for implementation.  

We understood the desired outcomes, but had to consider multiple user needs and complex variables 

At the basic level, we know that the navigation bar should only collapse when the user is NOT actively using it: that is, if the user continues working in the nav, it should stay open. But we also had to contend with more specific needs, such as loading time, solution complexity, delays in opening and closing the panel, the frequency of that opening and closing, and the sensitivity of the cursor (where an accidental movement or vibration could result in an unexpected closing of the panel). Furthermore, we knew the solution could not add logic or business complexity into the workflow: it shouldn’t take longer to load, and it shouldn't use additional computing power to collapse at the right time. 

We tested three proposed solutions  

Based on these requirements, we came up with three possible solutions. Let’s look at all three and discuss the pros and cons of each. 

  1. Adding an invisible divider

    In this first solution, we added a thin invisible bar next to the navigation panel. The bar runs the length of the panel, and we experimented with various widths, testing both wide and narrow options. When the user’s cursor falls in the navigation panel OR within the invisible area, the navigation panel remains open. When the mouse is outside of the panel or invisible area, it closes.

    This is a simple solution to configure. However, it could also be confusing or counterintuitive for users, especially if the user moves the cursor OUT OF the navigation panel, but the panel stays expanded. Users don’t have context about how their actions affect what happens on screen. The divider is invisible, so the user isn’t aware of what’s triggering the panel to open and close, and we heard from users that this could create confusion or room for error.
  2. Implementing dynamic timeout 

    The second solution uses a mathematical approach.  We created two calculations to quantify 1) the increase in distance between the cursor and the navigation bar and 2) the time spent away from the navigation bar.

    This solution reduces the probability of the panel collapsing unexpectedly. At the same time, the user can swiftly open or close the panel, without delay. The delay reduces with the distance between the pointer and the edge of the nav bar, which solves the "shaking hand" problem without increasing the delay to collapse.

    Unfortunately, it’s difficult to choose the right coefficients for the formula to properly calculate time for both distance=1px and distance=300px.  Additionally, this solution requires JavaScript, which may overcomplicate a relatively straightforward behavior.
  3. Increase the transition delay

    In the third possible solution, we considered that the navigation bar collapses when the cursor stays outside of the navigation panel for a specified amount of time. For example, let’s say the specified time to trigger the close is 0.5 seconds. If the user’s cursor stays outside of the panel for 0.2 seconds, it will remain open. If the user’s cursor stays outside of the panel for 0.6 seconds, it will close.

    This is the simplest solution because it requires the least number of changes to the existing configuration. We only need to adjust the delay time to be longer or shorter, depending on the needs of the users of the organization’s application. With this solution, users won’t need to adapt to a different UI because the behavior is already one they’re familiar with.

    There is also an allotted margin of error for the user working with this solution. In the original configuration, we observed that the nav tended to unexpectedly collapse when users moved the mouse pointer vertically. User hand vibrations, along with cursor sensitivity, would briefly push the pointer out of the panel area, triggering the panel to close when the user did not intend it to. With this solution, however, if the user briefly hovers away from the bar on accident, we assume they don’t want it to close, and it will stay open. If the cursor remains outside the bar for a longer period, we understand that the user would like it to close.

    One challenge to consider is that this solution increases the amount of time it takes for the panel to collapse once the user leaves the panel area. Increasing the delay too much can make the interface appear sluggish—but we can rely on in-the-field testing to adjust the specifics of that delay based on actual user behavior. 

Why we implemented the transition delay in Theme Cosmos  

For Theme Cosmos in 8.6., we selected option three, the transition delay increase, as our solution. It’s the most effective at solving the user’s problem elegantly and is also simple to configure on the backend because there is no need for additional logic.   

In the first solution, we must ADD an additional invisible divider. In the second solution we ADD logic in JavaScript (mousemove listener). But in the third solution, we simply modify the existing delay value to keep the behavior both simple and easily modified in case our assumptions about the exact times users need are incorrect. We’d then rely on in-the-field testing to adjust the behavior.  

Build on familiar behaviors, but consider configuration complexity

As Cosmos developers, we aim for simple, elegant solutions that build on behaviors that users will already find familiar — avoiding, whenever possible, the addition of complicated variables. At the same time, we care about managing complexity of implementation on the backend. It’s about aiming for simplicity for the users, while avoiding too many assumptions — and testing those assumptions at every opportunity. In this scenario, we used a trial-and-error method to rule out false assumptions as much as possible. We did this by looking at user feedback to determine the effectiveness of solutions and if they needed further adjustment. 

Design-driven development creates solutions for users, but also efficiencies for developers and designers. We consider the issue facing the user and potential solutions that meet their needs, while also focusing on the feasibility of the solution from a development perspective.  

In the example discussed in this article, we developed the dynamic navigation collapse specifically for the Theme Cosmos implementation of the Cosmos design system. As we work on new releases in newer implementations of Cosmos (like Cosmos React), we’ll continue to review, evolve, and share examples of our process and solutions for design-driven development.

Recommended resources:

Don't forget 

Thank you to Michal Zarlok, principal software engineer at Pegasystems, for his contributions to this article.

About the Author

Dariusz Dudek worked as a front-end developer at Pegasystems.

Share this page Share via x Share via LinkedIn Copying...

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us