Usability testing
A reproducible study protocol for new integrators; no completed independent study is claimed.
This manual targets 0.1.0-beta.3. Read the source and availability policy before installing. Historical reports retain their original scope.
Automated tests establish reproducibility, not that a new person understands the product. Run this study before claiming independent usability or consumer-wallet compatibility. No external participant results are claimed in this document.
Participants and tasks
Recruit at least three developers who have not worked on PPOps. Give each the same release archive and README. Observe without explaining the commands.
- Explain what PPOps does and which host holds spending authority.
- Start the wallet-free demo, create an order and observe one fulfillment.
- Find the supported network/token, install path and payer requirements.
- Integrate the merchant example and identify how retries preserve an order.
- Diagnose a missing config file and an expired intent using the reported hint.
- Explain what PARTIAL after expiry and a duplicate webhook mean.
For an independently authorized real pilot, separately record merchant setup, initial synchronization, payer preparation, payment submission and confirmation. Do not combine those times into an unsupported “fifteen-minute payment” claim.
Record
Use participant pseudonyms. Record release/OS/Node, task completion, time, documentation jumps, error codes, requests for help and the participant’s own description of the confusing step. Never collect keys, provider credentials, request URLs, payment identifiers or commercial data.
Acceptance targets
- Every participant completes the local demo without editing source or acquiring blockchain credentials.
- At least two of three complete the integration exercise without maintainer intervention and correctly explain idempotency and fulfillment.
- Everyone distinguishes a simulation, a detected transfer and a confirmed payment.
- Each setup failure has a documented corrective path that the participant can find.
- Real scan/payment latency is reported as observations with versions and conditions, not guaranteed by a passing local test.
Log failures as concrete product work, then rerun the failed task with a fresh participant after correcting it. The external pilot runbook provides the checklist for external testing.
PayIn payer cohort (beta.3 UX)
Separately recruit at least five consenting payers who already have spendable private liquidity. Real-value testing requires its own explicit authorization, amount limits and recovery plan; the wallet-free demo does not establish these results. Use the exact source commit, wallet version, network and request workflow under test.
Ask participants to open a request, verify whom they intend to pay, inspect their readiness, review the fee, authorize once and recognize completion. Also show pending-balance, insufficient-balance, partial, late, expired and interrupted connection scenarios. Prefer synthetic scenarios for error-comprehension exercises.
Targets, not results:
- At most three primary actions: open request → Pay → Confirm.
- Under 60 seconds to submission for an already-ready payer, not to final acceptance.
- At least 80% complete without assistance.
- At least 80% correctly explain why an unready payment cannot proceed.
- Zero RAILGUN concepts required in the happy path. Count terminology the participant must understand, including any CLI/runbook detours, not just text hidden by the page.
The current reference-payer setup still has technical steps. Do not report the three-action target as achieved by counting only checkout clicks. Record wallet handoff failures separately from readiness, submission, finality and privacy-check latency. Do not introduce telemetry or session replay to measure these targets.