Flyer Stories
Case study: Designing a context selector component to elevate hybrid cloud navigation
Pull back the hood on how Red Hat User Experience Design (UXD) designed, iterated, and implemented an extra layer of filtration for Red Hat Insights.
Because Red Hat’s enterprise IT products service a wide scope of users and use cases within the hybrid cloud, they require nimble navigation — and Red Hat Insights is no exception.
Imagine a system administrator needs to troubleshoot problems for the specific systems they oversee. Sifting through other systems outside of their scope can slow their workflow, crowd their content view, and stand between them and successful task completion. To power nimble solutions, they need a more intuitive way to access the systems they need — and skip what they don’t. How could we enable that tailored experience within Red Hat Insights?
Simplifying and streamlining navigation meant supporting quicker system selection. Our design goal became clear: To eliminate time spent browsing to find a desired system, we needed to create a filtering mechanism in the UI itself.
Enter context selector, a component built to add an extra layer of filtration so that Red Hat Insights users can switch and navigate between specific contexts within the hybrid cloud.
We moved through 10 iterations of the context selector component throughout the design process. This case study walks through this journey from creation to implementation.
Let’s dive in.
Every design starts with a business reason, and ours was to create an experience for the November 2020 Red Hat Insights release that would give end users an easy and flexible way to filter for the systems in the context they care about.
Our main use case was to add an extra layer of filtration to browse cloud.redhat.com and allow our users, system administrators, to select for only SAP systems. Our design team planned to accomplish this by creating a view that would filter results for SAP infrastructure, allowing system administrators an easy way to observe, monitor, and remediate infrastructure specific to an SAP-only environment.
Designing and implementing this solution would elevate the user experience for Red Hat Insights, potentially appealing to more of the 180,000 SAP Enterprise Resource Planning (ERP) customers who have to migrate to SAP High-performance Analytic Appliance (HANA) by 2027. SAP HANA’s in-memory database runs on Linux, giving Red Hat Enterprise Linux (RHEL) the chance to gain customers as they migrate platforms. When Red Hat customers run RHEL, Red Hat Insights helps them identify and remediate security, compliance, and configuration risks in the RHEL environment.
Our business reason drove us to set and pursue our design goal: Enhancing the Red Hat Insights interface provided with RHEL subscriptions.
After contextualizing our goals for this design solution, we defined our design challenge.
Red Hat Insights is known for having many applications which each solve a different customer problem, such as recommending optimizations or fixing infrastructure vulnerabilities. With these multiple user goals in mind, we needed to design a filter view that would perpetuate throughout the application and allow the end users to provide filters based on a specific infrastructure. The context selector component, as we decided to name it, works as a generic way to filter the entire application by whatever the user needs.
As designers, we had to experiment with various questions, possibilities, and alternatives throughout the design process. Let’s explore those questions and how they helped us refine our design solution.
Where should we display the context selector on screen so that it can fit into each Insights application?
Our first challenge was to figure out the best location for the context selector, from both a hierarchical and functional perspective. We considered two layouts, placing the context selector:
- At the top of the web application.
- In the left side navigation.
After several team discussions, we opted for the first layout and placed the context selector at the top area of the web application, because it worked well from the hierarchical perspective but also this area of UI could work well for all of the applications.
How would the overall context selector look, behave, and work with our design system?
When creating new components or solving the customer tasks, we always tend to compose the components from pre-existing pieces in our open source design system, PatternFly. For this component, we aimed to combine the capability to select tags with the capability to select environments.
We considered several options including the pre-existing component and design concepts for new ones:
We weighed a lot of visual options for how the component would look in context. In terms of hierarchy, the component should feel distinct on the page. We juggled design questions like: Should it behave as a dropdown or as a tab menu item? Should it look like a clickable radio button? Should it have a blue rounded or rectangular border? Should that button have a title in front of it? Or should we approach it even differently and show an icon as a visual indicator that the user is located within this filter on the page?
We built mockups of several design options throughout the exploration stage:
What would the interaction actually look like and feel like?
Our initial interaction mockup featured two separate filters. On the left side, this mockup shows a dropdown where the user can select the SAP option from a list. The second dropdown offers an option to select tags — this functionality was already implemented in the product.
But then as we still considered these two filters as separate ones, it dawned on us: Why are we complicating this interaction? Could the filters fit into one dropdown?
As we considered different visual styles for the active filter, we thought of using a pre-existing component: a selection chip. The new iteration showed two active filters: Blue for SAP infrastructure, and gray for tags. On top of that, we included a search area that truncated in its inactive state and expanded upon use.
Then, we handed an updated context selector mock off to engineering for development:
The first part shows the truncated search area in its inactive state. The second part shows the expanded dropdown — note that the search area expands to a wider width when selected. When the workloads are selected, they turn into blue chip components. Selected tags populate the second part of the dropdown on the right, where they become grey labels. As we cannot fit all the content into this tiny dropdown, the user can view more tags by clicking Manage tags. Based on later feedback we renamed Manage tags to View more, as it better describes the action triggered when clicked.
We were nearing the final look and feel of our context selector component, but as with any UX design process, our work was far from over. With this particular iteration, further feedback sparked deeper considerations about our design choices, namely our decision to include an active chip for All workloads, a default selection made by applying no filters. By adding this chip, we hoped to align our current context selector design with our roadmap, preparing the component to factor in additional workloads in future iterations.
Did users really need an active chip to communicate all workloads were selected?
This question became pivotal as we approached our final iterations. While contributing to this design, my aim was to always communicate selections made by the user, so our design displayed Workloads — All when all workloads were selected. This active chip, however, went against our design system. We discussed the benefits and drawbacks to this design feature, namely the fact that this was the only instance we showed a visual indication of selecting all options in our application.
In the interest of consistency both with our design system and our product, we chose to dispose of the All workloads chip filter entirely. We also discarded the blue Workloads chip filter and changed all radio buttons to checkboxes to stay consistent with our pre-existing tag filter design.
For applications that have SAP environments, the context selector’s filter is enabled and active. Users can click the Filter by tags field to select their desired workloads from the filter dropdown list.
For applications that don’t have SAP environments, the context selector appears in a disabled state. Hovering on the disabled component surfaces a tooltip that indicates global filtering is not applicable for this page.
Even as our design progressed through implementation, new design challenges, use cases, and changes arose.
Throughout our iterative process, we encountered new questions surrounding our design system, product-specific goals, and design decisions. While the intent for our context selector remained consistent from ideation to implementation, its various features and functions underwent different variations and changes.
As we approached release, our design team still needed to be nimble, adaptable, and diligent. After we established our final design, we still needed to adjust empty states, tooltips, and other application functions impacted by our context selector design.
During usability testing, we discovered some bugs and issues that we hadn’t caught before.
We wouldn’t have discovered several improvements and recommendations without testing the context selector prototype, including:
- Search should not be case sensitive.
- The context selector component should not be sticky. Users found it challenging to see it when it was scrollable with the rest of the content.
- Long tag names were cutting off, and there was no other way to figure out how to show longer tag names in limited space, therefore we added tooltips to display needed info.
If you can, always incorporate user testing into the design process. Any kind of feedback is always greatly appreciated, but the user test uncovers something unexpected every time.
Nevertheless, we reached our end goal. The context selector was successfully integrated into the latest Red Hat Insights release!
As our context selector made its journey from design to development, we met new requirements. Our team worked hand in hand with engineers to create new mocks that addressed their specific needs. The importance was placed on consistent behavior between the applications.
Thanks to the collaboration across our design, development and engineering teams, the current implementation of the context selector component is consistent and functional across Red Hat Insights.
Karel Hala, the front-end engineer, shares his experience.
“An interesting part about the context selector was that we were building on an already existing component, which made it much easier to implement,” he said. “When I was handed the mockups, after it got implemented we realized there were still missing use cases that the feature needed to have.”
Karel said advanced platform processes allowed for very quick component implementation across Red Hat Insights.
“Considering this was a platform wide UI change, the adaptation of the component was very quick,” Karel said. “The component needed to be adapted in 7 applications and it turned out to be a very quick process. Usually, this takes a month for all the applications to adapt; however, in this case we were successful in like two weeks with fixing bugs included. The platform team prepared the component and its adaptation, and then each application was able to get it running in their environment.”
The entire team learned valuable UX lessons throughout this journey. For me, carrying the context selector from ideation to implementation highlighted my favorite parts of the design process.
I love diving into new projects to sketch out design concepts, play outside of the box, and produce the first visuals that lead to quality discussions with product management and engineering. It would be beautiful to have a perfect list of use cases and requirements at the beginning of the design process, but that situation only exists in design utopias — as we move through it, our iterative design process uncovers major use cases for end users.
I also enjoy the process of finding balance between perfect and functional design. I’ve grown to love compromising with front-end engineers when it’s technically challenging to adjust the component to our ideal design specifications.
In my time as a UX designer, I’ve learned and embraced that our design feedback loop is never ending.
Comments and insights from engineers, designers, and customers can confirm, challenge, and transform our prototypes. It’s fun and challenging to balance feedback-based adjustments and necessary changes.
But one of the nicest things about my role is seeing actual designs as they get implemented.
And as the product went live in November, we will start another feedback loop on the actual implementation from the real end users.
I hope this case study on our context selector component has inspired you to think critically, ask questions, and embrace iteration in your own design processes. As with any successful design solution, a business purpose drives its creation, but an actionable, user-centered result drives its impact.
Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.
