HXR for Designers, Builders, and System Owners

HXR is for people who design, build, operate, maintain, regulate, procure, or improve systems.

That includes software teams, engineers, service designers, product managers, clinicians, administrators, tradespeople, operations leaders, accessibility specialists, policy designers, support organizations, and people responsible for physical spaces or public infrastructure.

HXR Extends Beyond Interface Design

Traditional UX often examines whether a person can use an interface effectively. HXR also examines the institution around the interface: staffing, policies, incentives, handoffs, records, appeals, recovery, access, and the burden transferred when the designed path fails.

HXR Evaluations examine how a design works in people’s lives. Cases and other evidence can show a successful interaction, a failure, or different results under different conditions. The aim is to identify what preserves dignity and practical agency, what deserves improvement, and which demonstrated practices another team could learn from.

Questions for Builders and System Owners

• What objective is the person trying to accomplish?
• What time, effort, repetition, attention, or risk does the system require?
• Which burdens serve a necessary purpose?
• Which burdens exist because of internal silos, legacy systems, poor ownership, or metric incentives?
• Can people understand their choices and consequences?
• Can they correct an error without starting over?
• Does the system preserve context across channels and departments?
• Who absorbs the cost when the system fails?
• What does the organization measure, and what behavior do those measures reward?
• What works well enough to preserve or share?
• Who benefits from this practice, and who may still be excluded?

Make Good Experiences Understandable and Repeatable

Look at successful paths as closely as recovery paths. What helped the person understand the choices, keep control and reach the intended outcome? What did the organization provide, and did the benefit depend on an exceptional employee or work the person had to supply? Preserve the conditions that made the experience work so the organization can maintain it and other teams can test whether it transfers. Show organizational benefits where they are supported, without treating a completed task as proof of dignity, satisfaction or commercial success.

Design for Recovery, Not Only Success

A humane system cannot assume that every record is correct, every user understands the process, every channel works, or every employee has complete context.

Recovery paths, contestability, accessible assistance, continuity, explanation, and proportionate remedy belong in the design rather than being treated as exceptions after launch.

Measure the Human Cost

Internal savings may reflect shared efficiency, or they may represent work transferred downstream. Builders should measure not only completion rates and operating costs but time lost, repeated work, abandonment, correction burden, inaccessible choices, delayed outcomes, and preventable escalation.

What HXR Needs From Builders

HXR needs practical criticism from people who understand real constraints. Identify where its standards ignore safety, fraud, law, staffing, technical limits, operational tradeoffs, or unintended consequences. Share examples where a humane design also improves performance, and cases where an attractive reform merely moves the burden elsewhere.

HXR Taxonomy · Friction, Pain, Harm, and Invisible Taxes · How HXR Creates Accountability · Contributing to HXR