Allegation Referral Intake System (ARIS)
Social Security Administration (SSA)
UX Research · Service Design · Journey Mapping · Personas · Interaction Design · Prototyping
January 2018 - September 2020
The Challenge
ARIS was created to replace SSA's outdated e8551 fraud referral process, which employees used to report suspected fraud and potential violations to the Office of the Inspector General (OIG).
The existing process had changed very little since 2001. Employees across different roles and offices were expected to use the same lengthy form, even though their fraud-reporting needs, experience, and frequency of use varied significantly. The process was cumbersome, provided little visibility into what happened after submission, and did not adequately support the data and tracking needs of SSA and OIG.
Business goals
SSA needed ARIS to do more than replace an outdated form. The new system needed to:
-
Modernize the e8551 fraud referral process
-
Capture better data for analysis, trends, and fraud detection
-
Provide real-time referral and case status
-
Route a single referral to multiple destinations when needed
-
Reduce duplicate allegation reporting
-
Support communication during emergencies and continuity-of-operations events
Understanding the Current Experience
Understanding the people behind the process
We began with a broad research effort to understand how fraud referrals actually worked across SSA. Over 40 interview sessions were conducted with employees representing Field Offices, Disability Determination Services (DDS), Cooperative Disability Investigations (CDI), the Office of Anti-Fraud Programs (OAFP), and the Office of the Inspector General (OIG).
I participated in ~35 of the 40 sessions, facilitating approximately 15 and serving as note taker for the others. I reviewed recordings of the remaining sessions so I could contribute to synthesis across the full body of research.
Different roles, very different needs
The research revealed that there was no single “ARIS user.” The people responsible for fraud referrals varied significantly in their roles, expertise, frequency of use, and what they needed from the process. Some employees might submit only an occasional allegation and needed guidance throughout the process, while others handled referrals regularly and needed speed, flexibility, and support for more complex reporting scenarios.
Along with the UX team, I synthesized these differences into personas representing the primary user groups and personally created the persona and journey map artifacts. Each persona paired the user's needs and pain points with a current-state journey, helping the team see where the existing process broke down for different types of users.
Personas
Jim, Field Office Technical Expert: infrequent user who needs guidance and reassurance.
Garrett, OAFP Analyst: high-volume expert who needs efficiency and support for complex referrals.
Kate, CDI Disability Analyst: frequent specialist who needs prepopulation, appropriate routing, and referral tracking.
Mapping where the process broke down
The personas helped us understand who was using the process. The current-state journey maps showed what they experienced while trying to complete it.
Across roles, we found recurring problems with navigating a long and complex form, understanding what information was required, saving work during interruptions, and knowing what happened after a referral was submitted. At the same time, the severity and impact of those problems varied by user. Someone who submitted a referral occasionally needed much more guidance than an analyst completing hundreds each year.
Mapping those experiences made it clear that simply improving the existing form would not be enough. ARIS needed to support different workflows while giving users clearer guidance, better continuity, and visibility throughout the referral process.
Current-state journey maps
Jim’s Current-State Journey · An infrequent user struggles with unclear terminology, limited guidance, and a process that provides little support when he needs it.
Garrett’s Current-State Journey · A high-volume user works around a rigid process that makes complex, multi-person fraud referrals inefficient and difficult to track.
Kate’s Current-State Journey · A frequent specialist navigates unnecessary steps and repetitive data entry with little visibility into referral status.
The existing e8551 reflected many of the problems we heard in research. It presented users with the same long, static sequence of questions regardless of their role, experience, or reporting scenario. Employees had to work through sections covering the complainant, subject, claim, victim, and allegation summary, even though the information relevant to a referral could vary considerably.
For users who completed fraud referrals infrequently, the process offered little contextual guidance. For frequent users managing more complex allegations, it lacked the flexibility, efficiency, and tracking they needed. Users also described losing work when sessions timed out and having little visibility into a referral after submission.
One form was trying to serve everyone
Although the e8551 looked like a paper form, it was actually an early web-based form used to submit fraud allegations. Users worked through the same long, static sequence of sections regardless of their role, experience, or reporting scenario, and even the terminology and section headings could be difficult for infrequent users to understand.
Guidance wasn't built into the experience. A help link opened a separate Word document containing field-by-field instructions for completing the form. The e8551 also had no way to save work in progress and sessions timed out after 60 minutes. Users described drafting lengthy allegation summaries in Word before entering them into the form because a timeout could mean losing their work and starting over.
Research showed that users needed more than a cleaner version of the existing form. They needed contextual guidance, the ability to save and return to their work, support for different reporting scenarios, and visibility into their referrals after submission.
An early web form with little support
The existing e8551 web form
The paper-like interface provided little contextual guidance, and users relied on a separate instruction document to understand portions of the referral process.
Page 1: Section 1 Complainant and Section 2 Subject
Page 2: Section 2 Subject, continued and Section 3 Claim
Page 3: Section 3 Claim, continued and Section 4 Victim
Page 4: Section 4 Victim and Section 5 Summary
Page 5: Section 5 Summary, continued and Submit
Designing the New ARIS Experience
Turning research into product requirements
The research gave us a clear direction for ARIS. Rather than recreating the e8551 in a newer interface, we began designing an experience around the different ways employees actually reported and managed fraud allegations.
The new experience needed to reduce unnecessary data entry, guide users through only the information relevant to their referral, provide help within the workflow, preserve work in progress, and give employees a way to return to and track their allegations after submission. It also needed to accommodate more complex reporting scenarios without making the experience harder for occasional users.
Key experience requirements
-
Guide users through relevant questions and workflows
-
Provide contextual help where users need it
-
Prepopulate information already available from SSA systems
-
Save work and allow users to return later
-
Support both simple and complex fraud allegations
-
Provide a dashboard for managing and tracking referrals
-
Allow users to review and edit information before submission
-
Provide clear confirmation and an ARIS allegation number after submission
Envisioning the future experience
Before translating these requirements into detailed screens, I used future-state journey maps to show how ARIS could change the experience for each user type. The maps connected the problems identified in research with specific opportunities for the new system, helping the team envision how different users could move through the referral process with less friction and greater support.
Rather than forcing everyone through the same experience, the future-state journeys reflected the different needs we had identified, including contextual guidance for infrequent users, more efficient workflows for frequent users, the ability to save and return to work, and greater visibility into referral status.
Future-state journey maps
Jim’s Future-State Journey · Contextual help, saved progress, and referral tracking provide greater support for an infrequent user.
Garrett’s Future-State Journey · More flexible reporting, saved allegations, and status visibility support a high-volume, complex workflow.
Kate’s Future-State Journey · Prepopulated information, streamlined routing, editing, and referral tracking reduce repetitive work.
Evolving the design across releases
ARIS evolved through multiple rounds of research, prototyping, testing, and development. What began as an effort to replace the e8551 grew into a much broader product experience, with workflows for creating, saving, reviewing, submitting, and tracking fraud allegations.
As Lead UX Contractor, I managed the primary Axure prototype and translated evolving requirements, research findings, and stakeholder feedback into testable interactions. I worked closely with our federal UX Lead and coordinated design work across the contractor UX team, while collaborating with product owners, developers, architects, and other stakeholders throughout the iterative design process.
MVP · January 2020
Initial ARIS release established the foundation for the new fraud referral experience.
Release 2 · August 2020
Continued refinement of the experience based on evolving requirements and feedback.
Release 3 · In progress when my work ended in September 2020
A broader redesign continued to evolve the information architecture, navigation, claims workflows, review experience, search, and other areas of ARIS.
Protecting the experience through implementation
As the MVP moved into development, I compared the implemented screens against our Axure prototype and SSA's User Experience Framework (UEF) standards. That review uncovered significant differences between the approved designs and what was being built, including inconsistencies with established UEF patterns.
I documented the discrepancies and helped demonstrate the differences between the prototype and the developed experience to project leadership. The implementation approach was subsequently restructured, and the existing pages were redeveloped by a new development team with stronger experience using the UEF.
The experience reinforced the importance of treating design as an ongoing part of delivery, not simply handing off screens and moving on.
Prototype-to-code comparison during MVP development
Design verification surfaced differences between the approved UEF-based experience and the implementation.
Evolving ARIS beyond the original form
By Release 3, ARIS had evolved well beyond the structure of the original e8551. The experience centered on a dashboard where users could create, return to, and track allegations, with a progressive workflow that organized complex referral information into manageable sections.
The prototype incorporated prepopulated information, contextual guidance, conditional questions, saved progress, review and editing, and status visibility. Instead of asking every user to navigate the same static form, the experience could respond to the information entered and guide users through the parts of the process relevant to their allegation.
Fully functioning, clickable, testable Axure prototypes
My Allegations · A central dashboard gave users a place to create, return to, and track fraud allegations.
Reporter Information · Prepopulated employee information reduced repetitive data entry, while persistent navigation made the larger workflow visible.
Suspect Claim Information · Conditional questions and contextual guidance helped users navigate complex claim-reporting scenarios.
Review · Users could review completed sections and return to edit information before submitting the allegation.
Closing the loop after submission
The experience did not end when a user submitted an allegation. The prototype provided clear confirmation that the referral had been received and immediately assigned an ARIS Fraud Allegation Number. Users could then return to the ARIS dashboard, where allegations and their status could be viewed over time.
This addressed one of the recurring problems identified in research: employees wanted to know what happened after they submitted a referral rather than sending information into a process with little visibility.
Submission confirmation · Users received immediate confirmation and an ARIS allegation number, creating a clear connection between submitting a referral and tracking it afterward.
Outcome & Continuation
Where the work went next
My work on ARIS ended in September 2020 when project funding and priorities shifted during the COVID-19 pandemic. At that point, the Release 3 redesign was still in progress, including changes to the information architecture, navigation, claims workflows, review experience, and other areas of the product.
ARIS continued to evolve after my involvement. Because I was no longer part of the team, I don't have visibility into which elements of our designs ultimately carried forward or metrics from the later production experience. Today, however, ARIS is an operational SSA system used in the agency's fraud referral process.
ARIS today
Current SSA operating policy confirms that ARIS remains part of the agency's fraud referral process. SSA's June 2026 Program Operations Manual instructs employees to complete referrals of suspected criminal activity through the Allegation Referral Intake System.
My contributions to ARIS
As Lead UX Contractor, I worked across research, synthesis, experience strategy, interaction design, prototyping, testing, and implementation throughout my time on ARIS. I partnered closely with the federal UX Lead while leading much of the hands-on design work across the contractor UX team.
-
Participated in 35 of 40+ initial user interviews, facilitating approximately 15 sessions and supporting synthesis across the full research effort
-
Created the personas and current- and future-state journey map artifacts that translated research into shared models of users, workflows, and pain points
-
Led and managed the primary Axure prototype, creating functioning interactions with variables, conditional states, and realistic workflows
-
Translated research findings and evolving requirements into information architecture, navigation, workflow, and interaction-design decisions
-
Coordinated contractor UX design work and collaborated with the federal UX Lead, product owners, developers, architects, and stakeholders throughout iterative releases
-
Supported usability research and continued design refinement across MVP, Release 2, and the Release 3 redesign
-
Verified implementation against approved prototypes and SSA UEF standards, documenting and escalating significant design-fidelity and standards issues