Identity friction is service friction
Authentication can be technically correct while still producing a terrible human experience.
VA Community
Experience
Reducing fragmentation across a regulated public-service experience.
The challenge wasn’t simply improving screens. It was reducing the burden created by multiple accounts, inconsistent language, fragmented workflows, accessibility requirements, and platform constraints.
AS–IS / ORGANIZATIONAL HISTORYMultiple registrationsMultiple accountsDifferent languageRepeated identityFragmented reconciliation
→TO–BE / COHERENT SERVICERegister onceSingle sign-onOne profileConsistent patternsConnected support + routing
The problem
Fragmentation had become part of the service.
Veterans encountered organizational history as extra registrations, passwords, inconsistent terminology, unclear status, and disconnected touchpoints.
Staff experienced the same fragmentation as queues, missing context, failed attachments, and difficult reporting.
Account AAccount BAccount C
↓Different languageDifferent statusDifferent process
↓Veteran becomes integration layerWhat changed my mind
Modernization can preserve the mess perfectly.
Take an undocumented, fragmented process, rebuild it in Salesforce, and call that transformation.
Internal language leaks outward
Statuses that work for analysts can be meaningless to the person waiting for help.
Accessibility cannot be downstream QA
Ticket-by-ticket remediation guarantees the system will keep recreating the same failures.
Three decisions
01
Structure the intake before asking for answers.
Instead of asking business owners to “send everything,” discovery was framed around statuses, attachments, flow variants, knowledge, queues, escalation, reporting, and exceptions.
02
Map the AS-IS honestly before designing TO-BE.
The transformation could only become credible after the current fragmentation was visible. The service model became both evidence and design constraint.
03
Make accessibility a property of the system.
508 compliance moved upstream into tokens, semantics, component behavior, content requirements, and defaults rather than recurring cleanup.
The service model
The interface was only the visible layer.
01Identity
02Language
03Workflow
04Accessibility
05Platform
06Governance
Every layer shapes whether a veteran understands what is happening, whether staff can act, and whether the service holds together under real constraints.
What became real
Reconstruct the logic. Never invent the interface.
Controlled environments prevented public use of production UI, so the portfolio shows sanitized service logic rather than suspiciously glossy “confidential” screens.
Public-safe artifacts include the community presentation, talking points, flow comparison, opportunity mapping, sanitized schematics, and system-level accessibility recommendations.
Community presentationFlow comparisonOpportunity mappingSanitized schematicsAccessibility recommendations
Reflection
What I’d protect earlier next time
A CRM can encode a broken process with astonishing efficiency.
Status copy changes whether people understand what is happening to them.
The component system should make the compliant choice the easy choice.
The most expensive UX problems in public service are often the ones the interface inherited from somewhere else.