Simplifying Cloudflare's web application security

From individual products to a unified solution

Cloudflare's application security features had grown across separate product spaces, each with their own dashboard, terminology, and navigation. To find the right tool, users first had to know which product it belonged to, then relearn an entirely new UI layout each time. Investigating a single security event often meant switching contexts between multiple dashboards.

The goal of the dashboard unification project was to identify the common user journeys between these tools, then bring them together into a single experience based on the user's needs. Organised by the threats they address rather than the product lines that built them.

Research and guidelines

Before any copy could be written, I conducted a language audit across the existing dashboard. This involved mapping where terminology was shared across products, where it diverged, and where introducing new terms could create friction for existing users.

In parallel to auditing the existing dashboard terminology, I talked with customers and engaged in workshops with colleagues to understand how these security tools are used.

Clear guidance on a complex security posture

We implemented a security posture recommendation system along with the new dashboard, providing customers with insights and recommendations on how to improve their web application security. Providing clear and succinct guidance on what a user should do, where they need to go to do it, and why they should even care requires strong content design.

With dozens of recommendations spanning each area of security, I developed a content guideline for insights and recommendations to make sure insights were clear and recommendations were easy to follow.

Helping users mitigate security threats

Security rules allow users to configure how Cloudflare protects their websites and applications from malicious web traffic. Previously, many of these rules were intiially seperated across different pages based on the product they were bundled with (For example, API rules would be on a page that is seperate from Bot traffic rules). Merging the rules pages to simplify the dashboard also meant bringing together a lot of different use cases into one space, each with their own complextities.

In order to guide users on how to use security rules, we paid close attention to the discovery phase and the rule creation phase.

Discovery

Users come to the rules page from different starting points. Those who want to learn may arrive through documentation. Those already familiar with rules dive straight into the creation flow. Those who want a quick starting point reach for templates. The content strategy was designed to serve all three without requiring users to navigate between them.

Creation flow

Rules are grouped by their primary function. After pressing the create rule button, a list of available rule types is shown, each accompanied by a tooltip and a brief description of its purpose. Once inside the creation flow, the user sees a longer description alongside a documentation link specific to that rule type.

Templates

The templates sidebar presents ready-made rule templates grouped by their primary function. Each template card title is written to describe the outcome the rule provides, with a supporting description explaining how it works. The writing approach here prioritised outcome-led language so users could quickly identify the template relevant to their situation without needing to understand the underlying rule mechanics first.

Documentation strategy for a gradual change

When the new dashboard launched as a beta, our existing documentation did not match new experience. Our docs team were now supporting two different versions of the security experience at the same time. Step-by-step guides only described the old dashboard, and searching for docs became more difficult due to naming changes. A completely new docs IA was the right long-term answer, but during the period when both the old and new dashboard were available at the same time, the goal was to close the most critical gaps first.

Documentation priorities

• Introductory descriptions were updated to reference new feature names where they existed, either inline or as a note on the page
• Dashboard procedures were updated so that both old and new dashboard instructions existed side by side, using a tabbed format to separate them cleanly
• Search synonyms were added for new terminology so users searching with old product names could still find the right page
• The security dashboard proxy tile was prepared for the new dashboard so its content could be made fully searchable

Creating documentation tabs for the new and old experience

For pages with long dashboard guides, we introduced a tabbed structure separating old and new dashboard instructions. This preserved existing content for users still on the old dashboard while giving new dashboard users a clear, up-to-date path. After the new dashboard experience becomes the default, the content under the old dashboard tabs can then be placed elsewhere.

For pages with only minimal dashboard guidance, a simpler inline approach was used, adding a short bullet pointing users to the equivalent location in the new dashboard without restructuring the full page.

Results

• Users were 42% more successful at deploying security rules on the new dashboard

• 86% of users who opted in continued using the new dashboard without ever opting out

• Users who viewed the security insights showed a 170–2200% improvment in sucessfully improving their security posture (varies based on the type of insight)