User Journey to Load Scenario Translation Prompt

This prompt is designed for performance engineers and SDETs who need to convert raw user flow descriptions, product analytics data, or session recordings into precise, executable load test scripts. The core job-to-be-done is bridging the gap between product behavior and infrastructure testing: taking a high-level user journey like 'a shopper searches for a product, adds it to a cart, and checks out' and translating it into a virtual user script with concrete steps, realistic think times, data parameterization points, pacing controls, and exit conditions. The ideal user has access to user session traces, analytics funnels, or UX flow diagrams and needs to produce workload models that reflect actual production behavior, not idealized happy-path scripts.

You should use this prompt when you have a defined user journey and need to generate a load test script for tools like k6, Locust, JMeter, or Gatling. The prompt requires several structured inputs to produce a reliable output: a [USER_JOURNEY] description of the steps a user takes, [SESSION_DATA] with real user timing and drop-off statistics, [TARGET_SYSTEM] details including endpoints and authentication methods, and [LOAD_PROFILE] parameters like target virtual users and ramp-up time. The prompt works best when you provide real analytics data—average think times between steps, page load time distributions, and step completion rates—rather than guessing. It is not suitable for generating tests for systems where you have no production traffic data to validate against, or for testing backend services in isolation without the user-facing flow context.

Before using this prompt, gather your source material: user journey maps, analytics exports showing step durations and drop-off rates, API endpoint documentation, and any existing session replay samples. The prompt includes validation instructions that compare generated think times and step sequences against real user session traces, so having that ground truth data available is critical. After generating the scenario, you must run a validation pass where the model checks for unrealistic modeling—such as zero think times between authenticated steps, missing data parameterization for unique constraints like usernames or order IDs, or pacing that doesn't match observed user arrival patterns. The output should be treated as a first draft that requires human review against actual traffic patterns before being promoted to a load test suite.

The prompt below is designed to convert a high-level user journey, session trace, or analytics funnel into a detailed, parameterized load test script specification. It forces the model to reason about think times, pacing, data parameterization, and exit conditions before producing a structured output. Use this template as a starting point for your own performance engineering workflows.

textCopy
You are a performance engineer converting user behavior data into executable load test scenarios.

## INPUT
User Journey Description:
[JOURNEY_DESCRIPTION]

Supporting Analytics or Session Trace Data:
[ANALYTICS_DATA]

Target Environment Context:
[ENVIRONMENT_CONTEXT]

## TASK
Translate the provided user journey into a step-by-step virtual user script specification. For each step, define the action, expected response conditions, think time distribution, and any data that must be parameterized from external sources.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "scenario_name": "string",
  "description": "string summarizing the modeled user behavior",
  "entry_conditions": ["list of preconditions before the journey starts"],
  "steps": [
    {
      "step_id": "integer",
      "action": "string describing the user action or request",
      "endpoint_or_target": "string identifying the system component exercised",
      "method_and_payload": "string describing HTTP method, gRPC call, or message type with key payload fields",
      "expected_response": {
        "status_codes": ["list of acceptable status codes"],
        "response_time_budget_ms": "integer",
        "required_content_checks": ["list of assertions on response body or headers"]
      },
      "think_time": {
        "distribution": "string (e.g., 'normal', 'uniform', 'fixed')",
        "min_seconds": "float",
        "max_seconds": "float",
        "mean_seconds": "float (if applicable)"
      },
      "parameterization": [
        {
          "field": "string identifying the dynamic value",
          "source": "string (e.g., 'CSV file', 'random generator', 'correlation from step N')",
          "constraints": "string describing valid ranges or uniqueness requirements"
        }
      ],
      "exit_conditions": ["list of conditions that would cause the virtual user to abort or branch"]
    }
  ],
  "pacing": {
    "strategy": "string (e.g., 'fixed interval', 'arrival rate', 'open model')",
    "value_description": "string explaining the pacing parameter"
  },
  "data_dependencies": ["list of external data files or sources required"],
  "validation_rules": ["list of rules to validate the scenario against real user session traces"]
}

## CONSTRAINTS
- Think times must reflect realistic user behavior; do not use zero think times unless the step is an automated redirect.
- Every dynamic value must have an explicit parameterization source; no hardcoded test data.
- Exit conditions must cover both expected branches (e.g., out-of-stock) and error paths (e.g., timeout).
- Pacing must be consistent with the provided analytics data; if session inter-arrival times are provided, use them.
- If the journey includes authentication, the first step must handle token or session acquisition.

## VALIDATION CHECKLIST
Before finalizing the output, verify:
1. Does the step sequence match the described user journey without missing interactions?
2. Are think time distributions justified by the analytics data or industry defaults?
3. Do exit conditions cover the failure modes visible in session traces?
4. Are all correlated values (e.g., session tokens, product IDs from search results) properly linked across steps?
5. Would this scenario produce load that matches the throughput and concurrency profile in the analytics data?

To adapt this template, replace the square-bracket placeholders with your actual data. The [JOURNEY_DESCRIPTION] should contain a narrative of the user flow—for example, 'User lands on homepage, searches for a product, views details, adds to cart, and checks out.' The [ANALYTICS_DATA] placeholder accepts session duration distributions, step-to-step drop-off rates, or raw trace samples. The [ENVIRONMENT_CONTEXT] field should describe the target system's authentication mechanism, API gateway, and any known bottlenecks. If you have specific load test tooling (k6, Locust, JMeter), you can add a [TARGET_TOOL] constraint to shape the output toward that tool's scripting conventions. For high-risk production tests, always run the generated scenario through a peer review and validate it against a sample of real user session traces before execution.

This prompt is designed to be a core component in a performance engineering pipeline, not a standalone chat interaction. The primary integration point is an automated script generation workflow where user journey artifacts—such as session replays, analytics funnels, or product requirement documents—are fed into the prompt to produce executable load test scripts. The implementation harness must treat the prompt output as a structured artifact that requires validation, parameterization, and human review before execution against a live environment. The harness should accept a user journey description, a target load profile, and a set of tooling constraints as inputs, then assemble the final prompt with the correct placeholders for [USER_JOURNEY_STEPS], [ANALYTICS_DATA], [TARGET_TOOL], and [SLA_REQUIREMENTS].

A concrete implementation should wrap the prompt in a validation pipeline. After the model returns the load scenario, parse the output against a strict JSON schema that enforces the presence of required fields: virtual_user_script, think_times, pacing_config, parameterization_points, and exit_conditions. Each step in the virtual_user_script must include an action type (e.g., http_request, click, wait), a target identifier, and a correlation rule for dynamic data. If the output fails schema validation, trigger a retry loop with a repair prompt that includes the specific validation errors. Log every prompt attempt, the raw output, and the validation result for traceability. For high-risk environments, route the generated script to a human reviewer through a review queue before it is committed to the load testing repository. The harness should also compare the generated think times and pacing against real user session traces stored in your analytics warehouse; flag any scenario where the synthetic think time distribution deviates by more than two standard deviations from observed user behavior.

When wiring this into a CI/CD pipeline, treat the prompt output as a build artifact. Store the generated load test script alongside the prompt version, model version, and input parameters in a versioned artifact repository. This allows you to reproduce any load test scenario and debug discrepancies between expected and actual system behavior. Avoid running generated scripts directly against production without a canary stage: first execute the scenario against a staging environment with scaled-down infrastructure, validate that the virtual user behavior matches the original user journey, and check for missing correlation rules that could cause script failures. The most common production failure mode is a script that passes syntax validation but fails at runtime because a dynamic token—such as a session ID or CSRF token—was not properly extracted and replayed. Your harness should include a dry-run mode that executes the script with assertions disabled and reports any HTTP 4xx or correlation failures before the full load test begins.