Helping customers overcome cyber security incidents

One dashboard. Two completely different users.

Cloudforce One REACT (Respond, Evaluate, Assess, Consult Team) provides services to help organisations with active and past cyber security incidents. The core content challenge was that services provided for active incidents and past incidents were both to be offered as part of the same product, however the people reaching for them would be in radically different states of mind.

Starting with empathy mapping

The project began with a content strategy workshop to map the emotional and cognitive state of each user type before making any decisions about structure, hierarchy, or copy.

Two content principles emerged clearly from this session and shaped every subsequent decision:

• 01

  Emergency CTAs must be clear and linear

  A user in a panic needs to find the right service fast. The user should not have to hunt to find help. Any additional context or options had to come after the action, not before it.

• 02

  Urgent and non-urgent services must live in separate spaces

  Placing both service types in the same view risks overloading a panicked user with options that are not relevant to their needs. Keeping emergency contact and non-urgent advisory services separate ensures that a user is not overloaded with options.

From wireframes to high-fidelity content iteration

Following the workshop, I translated the content principles into low-fidelity wireframes. These established the general content patterns that the product designer could then translate into high-fidelity designs.

Emergency incident dashboard

For the emergency contact dashboard, the content work focused on reducing friction to zero. The primary action of contacting a REACT responder needed to be reachable in as few steps as possible, with no surrounding copy that required reading before acting.

Post-incident and advisory services form

The non-urgent services form presented a different content design challenge. The service covers a broad range of offerings, such as proactive threat hunting, tabletop exercises, incident readiness assessments, and post-incident support. Each of these requires different information from the customer.

Rather than presenting a single long-form request, I helped design a multiple-choice selection at the start of the form. This structure serves two purposes: it gives users a clear overview of what services are available, and it allows the form itself to change dynamically based on the service selected, surfacing only the fields relevant to that specific request.

Throughout the high-fidelity design phase, I continued to iterate on both copy and content structure in parallel with design, refining labels, adjusting hierarchy and ensuring that the language accurately reflected what each service delivers without overpromising or creating ambiguity about scope.

Results

• Users who requested emergency incident support took a median time of 8.5 seconds to request help after opening the dashboard. Optimising the content path with follow up testing may reduce this number even further.

• Confusion between emergency and non-emergency services was not observable in usage data. This could possibly mean that this confusion did not occur frequently for customers, or that the tracking for this data requires additional review. Customer feedback should be reviewed when available.