Neura Market Adversarial UX Test Reference

Purpose

The Adversarial UX Test identifies real user friction by roleplaying a worst-case user, then filtering complaints through a pragmatism layer to separate genuine issues from persona noise.

When to Use

Use this test in the following situations:

• Before demos or launches
• After shipping a batch of features
• When you need to find friction, not just bugs
• To test cold-start and new-user experiences

Capabilities

The test agent can perform the following:

• Generate a specific adversarial persona based on the product's target audience
• Simulate browsing as that persona to test core workflows
• Capture screenshots of every pain point
• Check the browser console for JavaScript errors on every page
• Produce in-character feedback rant
• Apply a pragmatism filter to categorize complaints (RED, YELLOW, WHITE, GREEN)
• Create actionable tickets for RED and GREEN items only
• Deliver a report with rant, filtered assessment, tickets, and screenshots

Prerequisites

Before running the test, ensure you have:

• Access to the app URL (staging or deployed, not local dev)
• Browser tools for navigation and screenshot capture
• Ability to check the browser console for JavaScript errors
• Project documentation for app context and URLs
• Ability to register as a new user (if applicable)

Parameters

Parameter	Meaning	Required
URL	The URL of the app to test (staging or deployed, not local dev)	Yes
Persona type	Optional description of the adversarial user (e.g., "grumpy 58-year-old S&C coach"). If omitted, the agent generates one based on the product's target audience.	No
App name	The name of the product being tested	Yes

Procedure: Run Adversarial UX Test

Initiate the Test

Tell the agent using one of these exact commands:

"Run an adversarial UX test on [URL]"
"Be a grumpy [persona type] and test [app name]"
"Do an asshole user test on my staging site"

Replace the bracketed placeholders with your actual URL, persona type, or app name.

Step 1: Define the Persona

If no persona is provided, the agent generates one by answering these questions:

• Who is the HARDEST user? (age 50+, non-technical, experienced with old way)
• What is their tech comfort level? (low — WhatsApp-only, paper notebooks)
• What is the ONE thing they need to accomplish? (core job, not feature list)
• What would make them give up? (too many clicks, jargon, slow, confusing)
• How do they talk when frustrated? (blunt, sweary, dismissive, sighing)

The persona must be specific enough to stay in character for 20 minutes.

Step 2: Become the Asshole (Browse as the Persona)

• Read project docs for context and URLs
• Fully inhabit the persona
• Navigate to the app
• Attempt the persona's ACTUAL TASKS (not a feature tour):
  • Can they do what they came to do?
  • How many clicks or screens does it take?
  • What confuses them?
  • What makes them angry?
  • Where do they get lost?
  • What would make them give up?
• Test these friction categories:
  • First impression
  • Core workflow
  • Error recovery
  • Readability
  • Speed
  • Terminology
  • Navigation
• Take screenshots of every pain point
• Check the browser console for JavaScript errors on every page

Step 3: The Rant (Write Feedback in Character)

Write feedback AS THE PERSONA in their voice. Use this exact template:

[PERSONA NAME]'s Review of [PRODUCT]

Overall: [Would they keep using it? Yes/No/Maybe with conditions]

THE GOOD (grudging admission):
- [things even they have to admit work]

THE BAD (legitimate UX issues):
- [real problems that would stop them from using the product]

THE UGLY (showstoppers):
- [things that would make them uninstall/cancel immediately]

SPECIFIC COMPLAINTS:
1. [Page/feature]: "[quote in persona voice]" — [what happened, expected]
2. ...

VERDICT: "[one-line persona quote summarizing their experience]"

Step 4: The Pragmatism Filter (Critical — Do Not Skip)

Step OUT of persona. Evaluate each complaint using these criteria:

• RED (REAL UX BUG): Any user would have this problem. Apply if:

  • A 35-year-old competent-but-busy user would have the same complaint
  • It is a genuine accessibility issue
  • More than 5 clicks to accomplish the persona's ONE task (almost always RED regardless of persona tech level)

• YELLOW (VALID BUT LOW PRIORITY): Real but only for extreme users. Apply if:

  • It is a real workflow inefficiency but not critical

• WHITE (PERSONA NOISE): "I hate computers" talking. Apply if:

  • The complaint is "I want it to work like paper" resistance
  • Fixing adds complexity for 80% of users

• GREEN (FEATURE REQUEST): Good idea hidden in complaint. Apply if:

  • There is a missing onboarding moment

This filter is MANDATORY. Never ship raw persona complaints as tickets.

Step 5: Create Tickets

For RED and GREEN items only:

• Clear actionable title
• Persona's verbatim quote
• Real UX issue underneath
• Suggested fix
• Tag "ux-review"

For YELLOW items: Create one catch-all ticket with all notes.

WHITE items appear in the report only, no tickets.

Limit: Maximum 10 tickets per session — focus on the worst issues.

Step 6: Report

Deliver the following:

• Persona rant (from Step 3)
• Filtered assessment (from Step 4)
• Tickets created (from Step 5) with links
• Screenshots of key issues

Constraints and Caveats

• One persona per session — do not mix perspectives.
• Stay in character during Steps 2 and 3; break character only at Step 4.
• Test the CORE WORKFLOW first — do not get distracted by settings pages.
• Register as a NEW user when possible — do not use pre-seeded admin accounts.
• Test on staging or deployed app, not local dev.
• Maximum 10 tickets per session — focus on worst issues.
• The pragmatism filter (Step 4) is MANDATORY — never ship raw persona complaints as tickets.
• Screenshots are required for every complaint.
• If the persona has zero complaints, the persona is too tech-savvy — make them older, less patient, more set in their ways.
• Zero WHITE items is a signal, not a failure — it means the product has real UX problems.
• Check known issues in project docs AFTER the test — if the persona found a known bug, that is damning (the team knew but never felt the user's pain).
• Subscription or paywall testing is critical — test with expired accounts, not just active ones.
• Count clicks to accomplish the persona's ONE task — if more than 5, almost always RED regardless of persona tech level.

Failure Modes

• Persona is too vague or tech-savvy — produces no useful friction.
• Skipping the pragmatism filter — leads to shipping "print this page" buttons for every screen.
• Testing on local dev instead of staging or deployed — misses real-world issues.
• Using pre-seeded admin accounts — misses cold-start friction.
• Mixing multiple personas in one session — dilutes findings.
• Creating more than 10 tickets per session — loses focus on worst issues.

Pragmatism Filter Threshold

When applying the pragmatism filter, remember that fixing a WHITE item adds complexity for 80% of users. This threshold helps distinguish between persona noise and genuine improvements that benefit the majority.

Example Personas

The following are example personas that illustrate the level of specificity required:

• CRM: Retirement home director, 68, filing cabinet is current CRM
• Photography SaaS: Rural wedding photographer, 62, books by phone, invoices on paper
• AI/ML Tool: Department store buyer, 55, burned by 3 failed tech startups
• Fitness App: Old-school gym coach, 58, paper notebook, thick fingers, bad eyes
• Accounting: Family bakery owner, 64, shoebox of receipts, hates subscriptions
• E-commerce: Market stall vendor, 60, cash only, smartphone for calls
• Healthcare: Senior GP, 63, dictates notes, nurse handles computer
• Education: Veteran teacher, 57, chalk and talk, worksheets in ring binders