Who is your target persona?

RHDH's End Users (Developers, NOT Platform Engineers)

Note: End users are not Platform Engineers. Most of our documentation (and it's hierarchy) targets Platform Engineers. End users would normally outnumber Platform Engineers by 100:1. Having end user documentation is crucial for a successful rollout and scale operation.

What stage of the user journey are you targeting?

Learn

Why is this content important?

• Empower End-Users for Self-Service: Developers (end-users, not platform engineers) can independently learn the fundamental aspects of RHDH, such as navigation, catalog usage, and template consumption, directly within the product.
• Reduce Onboarding Friction: Platform teams can more easily onboard hundreds or thousands of developers by providing a single, accessible source of truth for end-user product interaction. Novice users should be enabled to learn the basic parts of the RHDH experience like navigation, header, templates, and catalogs quickly.
• Reduced Support Burden for Platform Teams: By empowering end-users to self-serve for common questions, platform teams can focus on higher-value activities and troubleshooting complex issues.
• Improve Product Engagement: Encourage more confident end-users to explore and engage with advanced topics like TechDocs writing, template building, and dynamic plugin creation through structured, product specific guides.
• Encourage confident end users: to engage on more advanced topics like template building, techdocs writing, and creating dynamic plugins (perhaps via docs and tutorials)
• Enhance Rollout & Scale: Address large customer concerns regarding documentation gaps for scale operations, supporting successful RHDH rollouts and sustained adoption. Simply having one URL link that points to all relevant end user documentation will be a huge bonus.

What is the main user goal aka job to be done?

There should be a new "top level" category added to the documentation. That category should be "Using." That category should contain documentation covering the following end user topics:

• Getting started with RHDH
  • What is RHDH and why is it useful?
  • Logging in to RHDH
• Navigating the standard UI
  • Using the Global Header
  • Using the Left Hand Navigation
• Understanding & using the Software Catalog
  • What is the catalog and why is it useful?
  • Using the catalog (filtering etc.)
  • Adding new items to the catalog
• Understanding & using Techdocs
  • What are TechDocs and why are they useful?
  • Finding and viewing techdocs
  • Writing TechDocs & adding TechDocs to a component
• Understanding & using APIs
  • What are APIs and why are they important?
  • Finding and viewing APIs
  • Testing APIs
  • Adding APIs to a component
• Understanding & using templates
  • What are Templates and why are they useful?
  • Finding and using templates
  • Writing and adding new templates to the catalog
  • Templates reference with key syntax and samples
• Using search
  • From the header
  • From the left hand navigation
• Understanding & using Extensions (plugins)
  • What are Extensions (plugins) and why are they imporant?
  • Plugins in the left hand nav (use an RHDH example)
  • Plugins in the catalog entities (use a common RHDH example)
  • Coding plugins getting started guide
    • Converting backstage plugins to dynamic plugins
    • Working with admins to enable plugins
• Using Developer Lightspeed
  • Starting a chat
  • Getting help with Developer Hub
  • Appendix: List of documentation embedded in Lightspeed

What high level steps does the user need to take to accomplish the goal?

1. Add new top level category for end user documentation
2. Gather together existing end user documentation
3. Add missing end user documentation

What is the general sentiment of users towards this goal?

Large customers have concerns that they will struggle to rollout and scale RHDH to their large development teams (some numbering into the 000s). Currently the documentation does not cater well to this need for end user enablement, and while a limited amount useful information exists today, it is not structured in a way that makes this documentation easy to find and access.

What pain points are the user likely to encounter when accomplishing this goal?

End users struggle to understand RHDH, learn it's GUI, and engage with its features. This impacts end users ability to self-serve, causing them frustration and adding to the burden of the platform engineering teams who support these users. Ultimately this friction could end in failed adoption, underwhelming use, and possible churn of RHDH subscriptions - damaging the product's reputation and Red Hat's business.

What other feedback do users have around this goal?

Sales teams also have issues with negative feedback from customers where rollouts have been impacted by the lack of simple documentation on key features. By fixing this situation we can hand Sales teams a strong positive counterpoint to customer concerns regarding the products documentation and ease of use.

Are there any additional opportunities you can also implement for the user when documenting this goal?

There is also the opportunity to include the same end user content directly inside the product by (additionally) releasing the content simultaneously in TechDocs format on GitHub with a catalog-info.yaml file so that customers can import it and share it with their teams. Doing so would also make the documentation appear in search results.

Links to existing content 

• About software templates
• About software catalogs

People:

• SME: rh-ee-bwilcock 
• QE: 

Release Note: Yes

Documentation Outline

• See above for details