Lightspeed design guidelines
Author: Ran Elimelech | Last edit: February 20, 2025 | Design type: Navigation, Notification drawer, Onboarding, Quick starts, Side drawer, ChatBot | Product area: Ansible, HAC, OpenShift, RHEL, Red Hat Developer Hub
Virtual Assistant default display on landing on the product
The Virtual Assistant (VA) should be open by default when landing on the product.
This of course excludes smaller screens.
Launching the Lightspeed Virtual assistant
The launch button should be placed on the masthead.
This is preferred over using the floaty button.
Only use the float button when the masthead does not allow it.
The reason for this is:
- Avoid obscuring content.
- Avoid competing with other buttons
- Create consistency.
Side panel Framework
It is recommended to use the same side nav framework. So the panel is saved in the chat history.
Suggested: The Lightspeed panel framework offers the following options for sizing the panel, setting Lightspeed preferences, etc.
From left to right
- Side panel history drawer.
- Chat sessions history
- Pre-defined help pages
- Quick starts and other side panels.
- Product name as approved by branding.
- Menu
- Display modes, terms and conditions, settings etc.
- Close button
Example of quick start as it is displayed using the PF6 side panel framework header.
Chat history can list highlighted, or predefined pages such as “Getting started, Help” etc.
It can also list other resources such as quick starts as this drawer is global for the entire side panel and not just the VA.
New chat session / Conversation Starter
A new chat session should help users learn about the capabilities of LS, using the conversation starters component.
It is recommended to not over saturate the user with too many options. 3-5 options is a good start.
Those recommended actions can be leveraged for smart recommendations, meaning, the recommendations are adaptive to the user's state in the product.
Ideally, each new session will suggest prompts that are sensitive to the user’s location in the service or app on the console or the situation their project is undergoing. Love this guidance.
Listing internal resources in the VA
The VA should strive to embed results in the response body. For example, if the user asks a how-to question, it’s better to embed the instructions in the panel. This gives users a chance to interact with the response and refine their questions
If that’s not available, , the VA can also provide links to resources such as manuals or quick starts or knowledge base articles.
Listing external resources in the VA
External resources should be opened in a new browser tab. These should bear the “External” icon at the end of the string.
Quick Starts and other side panels
Documentations, such as Quick Starts, should be displayed in the body of the conversation as a response. The chat interface should allow rendering the Quick Start functionality, as shown in the image. The response should also render link to open the quick start in external side panel.
The steps of the quick start should capture the same structure of the original quick start as shown in the image.
Resuming back to quick start
The Lightspeed model should detect when user had opted into a quick start.
In case users had prompted something after opting into the quick start, users will be presented with an option resuming back via:
- An inline banner at the top of the chat.
- Recommended quick actions.
Side panel framework for products that use side panel tabs
Products who utilizes tabs should consider nesting the Lightspeed chat interface in a fixed tab.
Lightspeed placements within the product pages
As a rule of thumb teams should avoid overwhelming the product with Lightspeed placements.
More specifically, avoid too many LS icons and CTAs to use LS.
The approach should be “LS should be there to help if you need it”
The guideline is to proceed with caution.
Launching the VA
[image of using LS in the context of a page]
It is recommended to establish association between actions that are powered by lightspeed and the side panel. This means to render the command in the VA.
Note: This off course excludes complex actions that require a dedicated wizard and such.
The request should be reflected in the VA feed, and rendered as a prompt by the user.
This is done to educate users on how to use the VA. It will also suggest uses to follow-up in the VA.
Action menu items
[image of a menu dropdown]
Lists and tables should list actions powered by LS under the actions menu.
The LS actions should be branded with the LS logo. (Yes, it is less than ideal in small sizes. We are working on it. It is better to unify and change it later across the board.)
The icons should reflect dark and bright modes.
If multiple LS actions are stacked, designers should consider creating a section for LS.
The string next to the icon should be implicit in what the action is.
Inline notifications
[image of a standard inline notification] CHANGE
An inline notification should be utilized when LS has something substantial to say or recommends an action.
The inline notification should be the basic PF one but branded with LS.
It can also use a “Powered by Red Hat [product] Lightspeed”. (see more in the branding section.)
Only show the inline notification on the details page, not the list page (too much noise, like marketing drawing attention to a row -- if it feels like a commercial, don’t use it). Banner should be tied to a particular instance of a problem that Lightspeed could address.
What if the notification could pass thru a severity of the event that lightspeed is able to address? Show the notification and severity in a banner on the list page? Needs follow up.
Can tie lightspeed finding/event to a notification that appears in drawer. This is optional. (do we have Pfly guidance on what should be a notification?)
Banner should be tied to a particular instance of a problem that Lightspeed could address. Banner title should be issue description. CTA (link or button): resolve this with [product] Lightspeed.
Notification Drawer
It seems we need to be extra careful with this topic, especially when it borders with how users feel comfortable with LS. Seems that other products offer their AI as “help when you need it.”
Currently, It is not recommended to have LS proactively push recommendations to users.
If we must, then it is recommended to use the default notifications drawer.
[image of a LS notification on the notifications drawer]
There’s no need to brand the notification with LS in the main drawer/notification title. Instead, add the Lightspeed icon to the kebab menu options when there’s a Lightspeed-powered solution.
However, the actions offered should be branded.
Branding
For more information check out this slide deck:
Red Hat Lightspeed – Brand Guidelines