Back to Designs page

Service landing pages

Design type: Navigation, Onboarding | Product area: Hybrid Cloud Console
Mary Shakshober avatar

Author: Mary Shakshober
Last edit: July 11, 2023

About landing pages

What is a landing page?

In the perspective of ConsoleDot, a ‘landing page’ is a top level page that provides high level information, context, and actions related to more detailed pages. Landing pages can occur at various levels of the console information architecture (in this case, navigation sections), but so far we only have formalized documentation on ‘service’ level landing pages. We define a service broadly as a discrete group of functions that work together to help the user achieve outcomes. Examples: Insights Advisor; OpenShift Clusters; Hybrid Cloud Console User Access.

In general, service level landing pages should orient the user by answering:

  • What is this group of functionality that I've navigated to? What outcomes and use cases does it help me (the user) address?
  • How do I get started using it? Are there prerequisites?
  • Are there ways I can learn more about all the things that this service can do for me?

Landing pages will most often be dynamic because they will change what content they show once the user has configured the service and begun using it. We refer to the orientation state of the landing page as the “day 0” page. We refer to the landing page state that appears after that as the “day 1” page (which will often become a dashboard showing how the service is operating).


 Levels of landing pages can include (in order of highest level to most narrowed focus)…

  1. ConsoleDot landing page
    1. Console homepage
  2. Bundle landing pages, for example …
    1. Application and Data Services overview page
    2. Insights dashboard
  3. Service overview pages (what this documentation is for), for example …
    1. Drift | Red Hat Insights
    2. Data Science
  4. Maybe others in the future!

Elements of a day 0 service-level landings page

  1. Header section
  2. Tabs section (only use if necessary)
  3. CTA section
  4. Pricing section (only use if necessary)
  5. Benefits / use case section / about section
  6. Recommended content section

Related links

  • Landing page sketch template. Get the template.
    • ‘Add as library’ > [In Sketch app] Add > Templates > ConsoleDot-DesignTemplate > Service landing page > [Choose which works for you]
  • ‘Gold star’ examples’. See the examples.

1. Header section

Is the main call to action persistent after Day 0?
In other words, will someone regularly repeat this action?

YES
Users will repeat this action beyond Day0 (ie. a user might want to ‘Create cluster’ even after their Day0 experience, so we can keep this high level action in the header at all times)

NO
Once users do this action once, and then their journey will look different beyond Day0

RECOMMENDATION

RECOMMENDATION

Use the ‘With button’ variant of the landing page header symbol. This header should have these elements …

  1.  Name of service 
  2.  A 1-2 sentence ‘elevator pitch’ of your service should go here to help set context of page.
  3.  A ‘Learn more’ link that should open a new tab to provide more context for what the service is. We recommend having this URL destination be one of the RH websites (ie. related product page on developers.redhat.com or redhat.com)
  4.  High level main action that can be repeated beyond Day0. Use the CTA style button.

Example

Use the ‘Basic’ variant of the landing page header symbol. This header should have these elements …

  1.  Name of service 
  2.  A 1-2 sentence ‘elevator pitch’ of your service should go here to help set context of page.
  3.  A ‘Learn more’ link that should open a new tab to provide more context for what the service is. We recommend having this URL destination be one of the RH websites (ie. related product page on developers.redhat.com or redhat.com)

Example


2. Tabs section (only if needed)

Show a tab only when your page transitions to day 1; put the overview content (still relevant day 0 stuff) on a tab called “Overview.” (will explore more in Day 1). 


3. CTA section

Make most important CTAs prominent. Use the marketing CTA button for the 1 or 2 prominent CTAs. Try to avoid showing every possible way to get started with your services on this day 0. (too much noise, too many bold buttons). 

Include a prerequisite that transitions to a CTA when the prereq is done. If you can’t do that, show a sequence of steps. For example:

Prerequisite: register your platform or system or whatever with console

How many ways do you want to recommend that a user gets started?

1 main way to get started

2 main ways to get started

3+ ways to get started

RECOMMENDATION

RECOMMENDATION

RECOMMENDATION

Create a full-width card with …

  1. ‘Get started with <Service Name>'
  2. Body copy to help the user gain context of what the main action is, 
  3. A blue marketing style CTA, and 
  4. A right-aligned spot illustration (be intentional with these images -- don’t use anything too general)

Example

Do side by side, 2-card layout. The actions should use the blue outline marketing style CTA style (or one filled in blue style if it is recommended). Use icons that indicate which CTA is a:

  • (we provide) Trial
  • Connects to existing subscription
  • Kicking off a process that doesn’t require a subscription (cuz you already registered systems or you can create an instance of something free like a cluster)

Example

We suggest that you collaborate with your PMs to determine 1-2 main actions so that we can take an opinionated stance on the best way to get started.

Other possible ways to get started can be detailed in the 'Features / use cases' section.


4. Pricing section (only if needed)

Is it imperative that users be able to access pricing information for your service?

YES
Users should be able to access pricing if needed.

NO
There isn't any reason to show pricing / there is no pricing info

RECOMMENDATION

Use the hint pattern to give ~1 sentence of context and link out to a marketing page that has pricing. 

Example

RECOMMENDATION

Don't include this in your design - move onto the next section.


5. Benefits / Use cases / About section

This section can contain several things. This section can detail things like …

  • Key features of the service
  • Other possible actions (beyond the main CTAs) that a user might want to take
  • Important structures in your service’s architecture  to understand
  • Use cases for your service 

The display of this section should be consistent though, using an expandable list with the first list item defaulting to being in its expanded state. Use the presentation table below to determine how you should present the content that you have available. 

Do you have any key use cases, features, important structures, or additional important actions that a user could take (beyond the main CTAs)?

YES
I have things to populate in this section

Sort of
I have one or two items that could go in this section, but not much

NO
This service is very small, new, or otherwise a bit unknown to us -- we do not have these things flushed out enough to surface to the user

RECOMMENDATION

Create a full-width accordion with icons in the toggle headers (this variant has been requested to PatternFly - view the GitHub issue). Each use case / benefit / feature should have it's own accordion section, with the following information:

  1.  Relevant icon
  2.  "<Use case or benefit>" in the header
  3.  Description of the use case, feature, benefit, etc. and a ‘Learn more’ link that goes out to other RH website to describe it more.
  4.  (Optional) If there is a relevant action that a user could take to actually DO something (not just learn more) with a given feature / benefit /use case, you can include this in the far right of its toggle header. 

Example

RECOMMENDATION

Create a 50% width accordion with your 1-2 items (in same style as the previous column) AND a 50% width static card with this content:

  1.  "About <Service name>" in the card  header
  2.  A ~1 paragraph detailed description of what the service provides. See the ‘About’ copy example below for inspiration.

Arrange the accordion and the card such the the accordion is on the left and the card next to it on the right. 

Example

RECOMMENDATION

Create a full-width accordion with just one accordion item in it. Use a relevant icon in the toggle header (this variant has been requested to PatternFly - view the GitHub issue) that has this content:

  1.  Relevant icon
  2.  "About <Service name>" in the toggle header
  3.  A ~1 paragraph detailed description of what the service provides. See the ‘About’ copy example below for inspiration.

Example

Example ‘About’ copy:

Instead of this: 

Red Hat Advanced Cluster Security for Kubernetes is the pioneering Kubernetes-native security platform, equipping organizations to more securely build, deploy, and run cloud-native applications anywhere.

Lowering cost?
(uses sales oriented words like pioneering, is a high level description)

Try this:

Red Hat Advanced Cluster Security (ACS) improves the security of the application build process, protects the application platform and configurations, detects runtime issues and facilitates response. It is a Kubernetes-native security platform that empowers organizations to securely build, deploy, and run cloud-native applications. ACS helps protect containerized Kubernetes workloads in all major clouds and hybrid platforms.


6. Recommended content section

How many helpful resources does your service have?
These could be, but are not limited to ... documentation, learning paths, quick starts, videos, demos, etc.

1 piece of learning content

2+ pieces of learning content

RECOMMENDATION

Create a full-width card with the following content:

  1.  “Recommended content” as the card title with font size 20
  2.  <Title of learning item> with font size 16 (medium, not regular weight)
  3. 1-3 sentences to ‘preview’ to the user what this piece of learning content will teach them and why it is valuable to them.
  4. Arrow link to interact with the learning item (ie. ‘Begin Quick start’, ‘Read the documentation’, etc.), that opens any external URLs in a new tab and directly moves user to the learning item if it is internal to console (ie. Quick starts) 

Example

RECOMMENDATION

Start with a section header that says “Recommended content” at font size 20

Then create a three-column table with the following content:

  1.  <Title of learning item> with font size 16 (medium, not regular weight)
  2.  A label with the content type
    1.  Documentation (orange)
    2.  Quick starts (green)
    3.  Learning paths (cyan)
    4.  Other content types (purple)
  3.  An action-oriented link (ie. ‘Begin Quick start’, ‘Read the documentation’, etc.), that opens any external URLs in a new tab and directly moves user to the learning item if it is internal to console (ie. Quick starts)

Example