About the Founder of Human Experience Reform

Document status: Official HXR provenance and founder narrative

First published: August 4, 2026

Substantively expanded: August 9, 2026

Founder and creator: Sean Arenas

Naming continuity: The project was initially developed and published in 2026 as User Experience Reform (UXR) before adopting the name Human Experience Reform (HXR) on August 18, 2026.

Why this page exists

Founder attribution establishes provenance, but a name and résumé do not explain why User Experience Reform exists. HXR grew from a much older question about human-made systems: why do obvious, correctable burdens remain in place even when the people experiencing them and the institutions operating them can see that something is wrong?

There is no single dramatic origin story. Arenas describes HXR as the cumulative result of decades spent noticing unnecessary difficulty, helping people navigate systems, reporting problems, watching some problems persist, and asking what would let one person's effort become useful to everyone who encounters the same burden later.

The childhood question: why does the broken thing stay broken?

Long before HXR had a name, Arenas recalls noticing ordinary problems that remained visible for days, months, or years: a sidewalk hazard, vegetation narrowing a path, a vehicle blocking a pedestrian route, or public equipment left in a visibly deteriorated state. The important observation was not that every example caused major harm. It was that people could notice a correctable problem and still lack a practical path by which noticing it reliably caused correction.

The question became: Everybody can see that this is broken. Why is it still broken?

That question eventually grew into a distinction HXR now treats as central: a formal complaint channel is not the same thing as practical agency. Practical agency requires a credible relationship between a person's action and a consequential outcome.

Games create obstacles. Tools should remove them.

In the 1990s, another distinction sharpened the idea. Games deliberately create obstacles, puzzles, and constraints between a player and an objective. That difficulty is part of the product. A tool has the opposite job.

“Games deliberately put obstacles between a person and their objective. Tools are supposed to do the opposite.”

If software exists to help a person accomplish something, why should an ordinary goal feel like solving a puzzle? That question became one of the earliest conceptual roots of HXR's goal-centered approach.

It also explains a later HXR proposal, Goal-Oriented Documentation. A feature manual explains what a function does. A goals manual asks how a person actually achieves an objective from beginning to end. Writing the second kind of manual can expose friction that the first kind leaves invisible: handoffs, duplicated steps, prerequisite knowledge, workarounds, subsystem boundaries, and recovery burdens.

Decades on both sides of software

Arenas's account of his professional background spans software development, documentation, training, telephone technical support, field support, internal support, network and software maintenance, and direct work with users and developers. That work included roles involving Phoenix Technologies, Hewlett-Packard, and Ralph M. Parsons, along with years of teaching people how to use software and writing instructional material.

The recurring lesson was not that users were incapable of learning systems. It was that ordinary people were repeatedly required to learn system architecture in order to accomplish goals that should not have required that knowledge.

HXR later generalized that lesson beyond software. The same burden can appear in healthcare, banking, insurance, government, transportation, commerce, property administration, physical infrastructure, and other human-made systems.

No villain is required

HXR was not built on the assumption that every bad experience results from malicious intent. Many burdens can emerge from locally defensible decisions. One department optimizes its workflow. One vendor adopts a specialized standard. One policy reduces one organization's risk. One software team builds a boundary around its own component. Each choice may have an explanation while their combined effect transfers time, coordination, uncertainty, compatibility work, or error recovery onto the person trying to accomplish a goal.

This matters because reform becomes harder when criticism depends on proving that somebody intended harm. HXR instead asks what the system does, which burdens are necessary, who controls them, who bears them, what evidence supports the explanation, and what correction would demonstrate improvement.

When reporting teaches people not to report

Another part of the founder's experience involved the cost of trying to correct systems. A person notices something wrong, believes action may matter, spends time reporting it, and then watches the effort disappear into a process that produces no visible learning or correction. Repetition can change future behavior.

HXR treats this as a potential form of learned nonparticipation at the system level. No institution needs to intend to teach helplessness. A system can nevertheless teach people that participation is ineffective when effort repeatedly fails to produce a credible relationship to outcome.

That leads to a design requirement for HXR itself: reporting unnecessary burden should not itself require unnecessary burden.

“I view it as a fight for everyone.”

Arenas describes a different calculation when deciding whether to spend personal time pursuing a problem:

“I don’t view my fight as an individual fight. I view it as a fight for everyone.”

Thirty minutes spent correcting a problem may not make economic sense for one person if the only result is one individual remedy. The equation changes when the effort can become a durable case, attract matching experiences, preserve evidence, produce a reusable workaround, help an institution identify a failure, and eventually document a reform that improves future interactions for many people.

That is one of HXR's core purposes: build infrastructure that allows one person's finite effort to become useful to other people instead of vanishing when the interaction ends.

HXR as leverage, not a demand that people fight harder

Institutions usually enter an interaction with continuity, records, staff, procedures, automation, legal resources, and accumulated knowledge. An individual usually enters with one problem and a finite amount of time, attention, money, health, patience, and emotional capacity.

HXR is intended to change that leverage relationship. The objective is not to make people become better bureaucratic combatants. It is to multiply the effect of the effort they can reasonably give by preserving evidence, matching recurrence, carrying institutional memory forward, identifying responsibility, publishing reform criteria, and verifying what changes.

Institutions are not the enemy

Arenas has repeatedly rejected a model in which HXR succeeds only by becoming an adversary of every institution it measures. The project should be useful to institutions that genuinely want to improve. A company should be able to study recurring cases, identify expensive friction, improve a process, demonstrate the reform, receive credit for it, and give other organizations a model worth copying.

This is also why HXR's anti-capture rules matter. Institutions should be able to change their results by changing human outcomes. They should not be able to change the ruler by funding, pressuring, or privately negotiating the standard. The One-Way Authority Rule preserves that direction of influence.

A healthy HXR system should make genuine improvement the most advantageous way for an institution to respond strategically.

The capacity returned by reform does not stop with one person

HXR's developing research proposes that unnecessary friction consumes more than clock time. It can consume attention, memory, emotional endurance, physical effort, money, fuel, battery life, trust, care capacity, and practical agency. Removing the friction can return several forms of human capacity at once.

The founder's interest in these effects is civilizational as well as individual. A receptionist who has spent less of her own day fighting unnecessary systems may have more attention and patience available for the next person she helps. A worker who recovers an hour may use some of it for paid work, family care, exercise, study, sleep, creation, civic participation, or leisure. A reform that saves minutes across millions of future interactions can continue producing value long after the original case closes.

HXR therefore treats proposed Human Time, Capacity, Agency, Attention, Emotional, Memory, Trust, Care, Resource, Economic, Public Revenue, Health, Civic, Dignified Treatment, Reform, and Propagation dividends as research hypotheses to define, publish, challenge, measure, and revise. They are not assumed findings. The project intends to state the proposed mechanisms, invite academic and practitioner commentary, identify possible measures and confounders, and describe what evidence would strengthen, weaken, or falsify each proposal.

The point is not that every returned minute must become economically productive. Part of treating people with dignity is recognizing that returned time belongs to the person again.

HXR must be understandable enough to use

One of the founder's strongest concerns is not only that HXR could be captured or misused. It is that HXR could become rigorous, ethical, and technically sound while remaining too difficult for ordinary people to understand or use.

A lever nobody can pick up has little practical leverage. HXR therefore cannot require someone to study its entire taxonomy, governance model, evidence architecture, or scoring theory before saying, “This happened to me too,” learning a workaround, following a case, or understanding what reform is being requested.

The rigor belongs underneath the interaction. Comprehensibility is not decoration. For a project intended to restore practical agency, comprehensibility is part of the architecture.

The future HXR is trying to build

The objective is not a frictionless utopia. Necessary friction exists: safety checks, diagnosis, due process, learning, maintenance, fraud prevention, and other legitimate constraints can require time and effort. HXR asks whether a burden is necessary, proportionate, well designed, and borne by the appropriate party.

It also does not exist only to catalog failure. HXR should be able to document excellent experiences, preserve successful reforms, give institutions deserved credit, help other organizations copy what works, and gradually shift its public record from a library of recurring burdens toward a library of demonstrated better practice.

The underlying proposition remains simple: Life does not have to stay harder than it needs to be.

The founder's current role and limits

Arenas currently serves as HXR's founder, primary author, and framework-development lead. That includes developing the constitutional core, taxonomy, evidence model, governance safeguards, case architecture, public documentation, research proposals, and future operational standards.

Founder attribution establishes provenance and responsibility for the work. It does not place the founder above HXR's safeguards. The One-Way Authority Rule, evidence discipline, causal humility, versioning, public criticism, and anti-capture architecture are intended to constrain future service organizations, funders, advisors, leadership, and the founder alike.

HXR welcomes criticism, research, counterevidence, and public review. Agreement with the founder is not a condition of participation.

---

Copyright © 2026 Sean Arenas. Human Experience Reform (HXR). All rights reserved. See the HXR Copyright, Attribution, and Reuse Notice for permitted uses and limitations.