The Methodology

The Core Idea

Traditional E2E tests ask: "Does feature X work?"
Persona-driven tests ask: "Can user type Y accomplish their goal?"

Instead of testing isolated features, you validate entire user workflows from different perspectives. Each persona represents a distinct user archetype who would use your application differently.

The Persona Definition

Every persona has four essential attributes:

• 1

  Name and Role

  A memorable identifier (e.g., "Alex - Trial Evaluator")

• 2

  Background

  Who they are, their context, and experience level

• 3

  Goals

  What they're specifically trying to accomplish on your site

• 4

  Behaviors

  How they typically interact with software (heavy searcher, skimmer, keyboard user, etc.)

Test Structure

File Organization

Create one test file per persona in a dedicated personas/ directory within your tests folder. Also create a shared utility for collecting observations and metrics.

Test File Anatomy

Each persona test file contains:

1. Persona definition at the top as a JSDoc comment and exported object
2. A serial test suite (tests run in order, simulating a continuous session)
3. Shared observation collector instantiated once for all tests
4. Lifecycle hooks:
   • beforeAll: Start the observation session
   • beforeEach: Attach console error listeners
   • afterAll: End session and save observations
5. 4-6 task-based tests representing realistic user goals
6. One free exploration test at the end simulating open-ended browsing

Task Tests

Each task test follows this pattern:

1. Track start time for duration measurement
2. Initialize success flag as false (prove success, don't assume it)
3. Navigate to starting point and capture a screenshot
4. Attempt the task as the persona would naturally try it
5. Evaluate outcomes:
   • Goal achieved: mark success, note what worked
   • Partially achieved: mark success with friction observations
   • Blocked: keep failure, add frustration observation
6. Capture result screenshot with context
7. Record the task with success/failure, duration, and notes

Free Exploration Tests

Every persona ends with a free exploration test that simulates realistic browsing without a specific goal. This catches issues that task-focused tests miss.

Structure

1. Start on the main page
2. Define actions the persona would naturally take (scroll, click interesting things, try different sections)
3. Execute each action with error handling so one failure doesn't stop exploration
4. Capture screenshots at interesting moments
5. Always mark as successful (observations matter more than pass/fail)

The Observation Collector

A shared utility class that captures everything during test execution:

Session Metrics

• Start and end timestamps
• Page load count
• Click and search counts
• Back navigation count (high numbers indicate confusion)
• Console errors captured automatically

Screenshots

• PNG files saved to disk
• Base64 encoding for vision model analysis
• Associated URL, page title, name, and context description

Task Results

• Task name and success boolean
• Duration in milliseconds
• Free-form notes about what happened

Output

The collector saves a JSON file per persona containing all metrics, task results, observations categorized by type, and screenshots with metadata and base64 data.

Observation Types

Use these consistently across all tests:

Vision Model Analysis

The most powerful aspect of this methodology is using a vision-capable AI model (like Claude) to analyze the captured screenshots.

How It Works

After tests complete, feed the observations.json file (which contains base64 screenshots) to a vision model along with:

• The persona definition (background, goals, behaviors)
• The task being attempted when each screenshot was taken
• Context description for each screenshot
• Observations already recorded by the test

What the Vision Model Can Identify

Prompting the Vision Model

When asking a vision model to analyze screenshots, provide context:

"Here are screenshots from a user journey test.
The persona is [name], who [background].
Their goal was to [goal].
They typically [behaviors].

Analyze each screenshot and identify:
1. UX issues that would frustrate this specific persona
2. Accessibility problems visible in the interface
3. Design inconsistencies
4. Whether the user's goal appears achievable
5. Specific recommendations for improvement"

Key Implementation Details

Serial Execution

Tests must run in serial order (not parallel) to simulate a continuous user session where state carries over.

Screenshot Strategy

Capture screenshots at:

• Start of each task
• Key decision points
• Results/outcomes
• Anything confusing or problematic

Base64 Encoding

Screenshots are saved both as PNG files on disk and as base64-encoded strings in the JSON output. The base64 format allows the observations file to be self-contained and directly processable by vision models.

Flexible Selectors

Use realistic selectors that a user would conceptually understand. If searching for a "Votes" section, look for headings containing "Vote" rather than test IDs that users can't see.

Graceful Failures

Wrap actions in try/catch so one failure doesn't cascade. Record what went wrong and continue the exploration.

Realistic Timing

Use realistic timeouts. If a user would give up after 3 seconds of waiting, set that as your timeout. This catches performance issues that pass/fail tests miss.

Analyzing Results

Automated Analysis

Review the observations.json files for each persona. Look for these patterns:

When to Use This Approach