Americas Car-Mart — (app) cLAIMS
INDUSTRY
Automotive / Consumer Finance
ROLE
UX Designer
team
5 in total
PRODUCT
Internal Claims Management
Year
2023
project overview
Americas Car-Mart (ACM) is a used vehicle retailer and finance company serving customers across the United States. As their business scaled, inefficiencies across internal operations began surfacing as real customer pain, none more critical than their Accident Protection Plan.
APP is an optional add-on purchased at the time of sale. If a customer's vehicle is stolen or declared a total loss due to an accident or fire, Car-Mart cancels the remaining loan balance, protecting customers from paying off a vehicle they no longer have.
The problem was operational. As APP claim volume grew, average resolution time frequently exceeded 100 days, with some cases extending beyond 12 months. Customers were left without functional vehicles and with unresolved loan balances. The internal team knew something was broken. They just didn't know exactly where
the challenge
The core challenges were:
Identifying which internal processes were creating the most friction and why
Understanding how different roles experienced the same broken system differently
Designing a solution path without defaulting to building new UI before understanding root causes
Working within constraints that prevented direct access to end customers
The environment required a careful, evidence-based approach. Building screens without first diagnosing the system would have solved the wrong problem.
MY ROLE & Scope
I led the Discovery, Research Strategy, and Strategic Solutioning phases of the project, working directly alongside the internal ACM team responsible for APP claims management.
Responsibilities included:
Designing and managing the project workflow
Mapping existing internal systems and process flows
Creating and iterating an interview script for stakeholder research
Synthesizing interview data into UX research artifacts
Facilitating the Affinity Mapping process
Mentoring a junior team member through the Design Thinking methodology
Translating findings into strategic solution recommendations
I collaborated with a Business Research and Delivery Director and a junior team member who was new to UX — which made this an opportunity to lead through teaching as much as through doing.
APPROACH
The approach followed a structured discovery process grounded in Design Thinking. Rather than jumping to solutions, the goal was to first understand the system deeply, its flows, its failures, and the people navigating it every day.
Before any research began, I set up a Trello board to manage tasks, track progress, and keep the team aligned throughout the engagement. With multiple stakeholders and a tight process to unpack, having a shared operational structure was essential from day one.
PHASE 2 — SYSTEMS MAPPING
The first research question wasn't about users, it was about the system itself.
I mapped all existing internal flows to understand how tools and processes were currently configured, where handoffs happened, and where potential failure points existed. This allowed me to form early hypotheses and identify what to probe in interviews, without jumping to UI solutions prematurely. These are some of the artifacts:
PHASE 3 — STAKEHOLDER INTERVIEWS
Because only internal personnel were permitted to conduct interviews with ACM staff, I designed an iterative interview script that the Business Researcher could run independently, and that could be refined between sessions as new information emerged.
The script was designed to evolve. Each round of interviews informed the next, sharpening the questions and deepening the insights over time.
Participants spanned a range of roles and experience levels across the APP and CARE teams, including coaches, managers, agents, and champions, both tenured staff and new hires. This cross-section was intentional: it allowed me to identify where problems were systemic versus where they were tied to onboarding or role-specific knowledge gaps.
PHASE 4 — SYNTHESIS & USER PERSONAS
With interviews complete, I synthesized the findings into structured user personas covering:
Pain points and frustrations
Goals and needs
Mental models and role responsibilities
Tech preferences
Design considerations grounded in real data
This step moved the project from assumptions to evidenc, giving the team a shared, data-backed picture of who was struggling and why.
PHASE 5 — AFFINITY MAPPING
I led the team through a multi-stage Affinity Mapping process to move from raw interview data to actionable insight.
Stage 1 — Capturing Pain Points: All frustrations and friction points from the interviews were extracted and documented.
Stage 2 — Thematic Coding: I identified the most frequently repeated words and concepts across all pain points and organized them into thematic codes. Each code represented a category of shared struggle. I found 15 distinct codes, each assigned a frequency score based on the number of times it appeared across participants.
The code with the highest occurrence was "Missing Information" — a clear signal that ACM team members were consistently blocked by incomplete or inaccessible data.
Stage 3 — Isolation & Customer Impact Mapping: The highest-frequency codes were isolated and subcategorized, allowing the team to also identify how each internal blocker was translating into a customer-facing problem.
Stage 4 — Root Cause Identification: The synthesis pointed to a clear root cause: Dynamics 365, the platform ACM used to manage customer-related operations, was misconfigured and missing critical information fields. A powerful tool — but one that had never been set up to support the actual workflow demands of the APP claims process.
The system wasn't broken by design. It was broken by neglect.
PHASE 6 — Bringing Structure to a Fragmented Claims Workflow
Understanding the Existing Interface
My first step was to conduct a thorough audit of the existing claim UI within Microsoft Dynamics 365, the platform used to manage all APP claim activity. Rather than jumping into solutions, I needed to understand what was already there, how it was organized, and where the gaps were.
I performed a detailed sections breakdown of the interface, documenting every data point, labeling each container, and mapping what information lived where. This exercise quickly revealed a core structural problem: data was scattered throughout the screen without a clear organizational logic. Related data points were separated, unrelated ones were grouped together, and several critical pieces of information were either missing entirely or ambiguous in purpose.
Reorganizing the Information Architecture
With the audit complete, I reorganized all data points into logical groups based on their relationship to the claim process. The original interface surfaced 12 loosely defined categories. Through analysis, I consolidated these into 8 distinct groups: Customer Info, Dealership Info, Vehicle Info, Incident Info, Claim Info, Financial Info, Blackbook Info, and Loan Info. Each with a clear purpose and a defined role within the workflow.
This was not a visual exercise. It was a structural decision that would drive every design choice going forward.
Identifying Missing Information & Wireframing the New Structure
In parallel with the reorganization work, I mapped the missing information items that had surfaced during the audit. I identified critical gaps: co-buyer information, dealership address, lawyer's information, driver's insurance, GPS data, incident type classification, and payment status visibility, none of which existed in the current experience but were essential for agents to manage claims effectively.
These missing items were incorporated directly into a low-fidelity wireframe, where I validated the new structure in context. This step confirmed that the reorganized data groups held up against real workflow needs, that the layout supported how agents actually move through a claim, and that all critical information was reachable without unnecessary navigation. Only once this foundation was solid did the work move toward high-fidelity design.
FROM STRUCTURE TO SOLUTION
The research, audit, and information architecture work I led directly informed the design of the new claim intake experience. Rather than continuing to rely on a fragmented Dynamics 365 interface where agents navigated scattered data under pressure, the solution took shape as a structured, step-by-step claim intake flow.
The tool guides agents through the entire process from the moment a customer calls — verifying identity, capturing incident details, collecting insurance and third-party information, and closing the interaction with clear next steps. Each step maps directly to the data groups I had defined during the reorganization phase, ensuring that nothing critical was missed and that the workflow followed the natural progression of a claim.
My contribution was not the visual execution of this interface, but the strategic and structural foundation it was built on. The groupings, the sequencing logic, and the identification of missing information items all originated from the audit and IA work I conducted. This is what shaped what got built.
results
& impact
The structural and strategic work invested in redesigning the APP claims experience delivered measurable results across the entire operation. By bringing clarity to a fragmented process, the transformation directly accelerated settlements, reduced case backlogs, and dramatically cut the time it takes to onboard new agents into the workflow.
Some customer love ❤️
Conclusion
Working on the APP claims experience taught me that the most impactful design decisions rarely happen on a screen. They happen before that, in the moments when you slow down, audit what exists, ask uncomfortable questions about why things are structured the way they are, and resist the urge to jump straight into solutions.
The existing system wasn't broken because of bad design. It was fragmented because it had grown without a clear information strategy behind it. My job was to bring that strategy, to make sense of the chaos before anyone opened a design tool.
What stayed with me most was how directly structure affects people under pressure. Claims agents work in high-stakes moments, often alongside customers who are stressed and need answers fast. Every misplaced data point, every missing field, every unnecessary click compounds that pressure. Getting the architecture right wasn't a UX exercise, it was a service to the people using the system every day.
This project reinforced something I care deeply about: that great UX leadership means knowing when to design and when to first understand. The screens come last. The thinking comes first.