User experience
and interface design
in Washington, D.C.

Consumer product design assumes a user who can leave. Internal tools, compliance systems and mandated portals have no such pressure, and design practice built on the consumer assumption transfers badly.

The absence of choice changes what good means. Delight matters less. Time to complete, error rate and recovery matter far more. A screen that a person will open four hundred times a year should be optimised for the four hundredth time, and not the first.

That argues for a different balance than onboarding-led design. Experienced users want density, keyboard paths and predictable positions. Novices want guidance. Serving both usually means a stable layout with progressive help, and not a simplified interface that slows the expert down permanently.

Error handling carries more weight here than anywhere else. When a person must complete a task and the system refuses, they cannot abandon it. They call somebody. Every unclear error is a support cost and, often, a workaround that undermines the data the system was built to protect.

Research access is the usual obstacle. The users may be in another organisation, on restricted networks, or difficult to reach for legitimate reasons. Where direct observation is impossible, the support log becomes the research material. It records real failures with real frequency, which is better evidence than a session with a volunteer.

Measuring is also different. Engagement is meaningless when attendance is compulsory. Task completion, time per task, support tickets per hundred users and workaround prevalence tell the actual story.

The last point is ethical rather than technical. A captive user cannot signal dissatisfaction by leaving, so the responsibility to look for their problems sits with the team. Nobody else will raise it.

In procurement-led purchases the evaluator, the buyer and the user are three different people. The design has to satisfy all three. They want different things.

The evaluator reads a specification and checks boxes. The buyer weighs cost, risk and stability. The user wants to finish a task. Design only for the third and you lose the contract. Design only for the first two and the product ships, then gets worked around.

The practical response is to design for the user and to document for the evaluator. Accessibility conformance, security posture, audit trails and administrative controls are real requirements, and they can be built properly rather than bolted on. When they exist genuinely, the documentation writes itself.

Demonstrations deserve their own attention. The evaluator often sees the product once, for an hour, in a room. What they see should be the real product with real data shapes. The path through it should cover the cases they were told to check. A demo environment that diverges from production creates an expectation the delivery cannot meet.

Pilots are where the gap between approval and use becomes visible. A short pilot with actual users, measured rather than surveyed, tells you what the evaluation missed. It is also the moment when a difficult finding is still cheap to act on.

Where the three audiences genuinely conflict, say so in writing rather than splitting the difference silently. A stated trade-off can be argued with. A quiet compromise gets discovered later by the people who have to live with it.

Interfaces are tested in a quiet room by somebody who intends to finish. Real use is different. The phone rings or a colleague arrives, and the task is abandoned at step four and resumed the following afternoon, or never.

An interface that assumes continuous attention punishes that. The form clears, the session expires and the wizard restarts at the beginning, and the person decides it is not worth doing again.

Save continuously and say so. A draft saved every few seconds, with a visible timestamp, removes the anxiety that makes people rush. The timestamp matters as much as the saving, because the reassurance is what changes behaviour.

Make state visible on return. Somebody coming back a day later needs to see where they stopped and what remains. A progress indicator that survives the gap is worth more than one that only exists during the session.

Session expiry deserves a deliberate decision. Where security requires a short window, warn before it closes and preserve the work behind the login. Discarding entered data at sign-out is the harshest thing an interface can do.

Long tasks should be divisible. Sections that can be completed and submitted independently let somebody make progress in ten minutes. One long form with a single submit requires an uninterrupted hour, which many people never get.

Confirmation emails carry the resumption. A link back to the exact step, valid for days, converts an abandoned task into a finished one more reliably than any reminder inside the product.

Test this deliberately. Start a task, close the browser, come back tomorrow, and try to finish. Most teams have never run that test on their own product.