Simplifying Injury Reporting
Transforming a phone-dependent claims process into a guided, measurable self-service experience.
- Role
- Product Design Lead
- Platform
- Responsive web
- Scope
- End-to-end product design, strategy and prototyping
- Partners
- Product, engineering, content, research and compliance
Completion, after launch and continued iteration — a 4.4 percentage-point improvement.
Reporting an injury used to mean talking to an adjuster. GEICO needed medical, employment and expense detail; customers arrived stressed, often without it, and unsure what any of it was for.
I led the end-to-end design of a guided self-service path — sequencing a large set of claims requirements into steps that explain themselves, then building an evidence loop after launch that separated design friction from technical failure. The work later expanded to no-fault forms in five states.
Overview
Reporting an injury after an accident is emotionally demanding. Customers may be managing pain, medical appointments, missed work or the effects of a traumatic event while being asked to recall detailed information for an insurance claim. Before Injury Intake, much of that reporting depended on direct conversations with adjusters. Customers had limited visibility into what information was needed, whether they had reported everything accurately or what would happen next.
Injury Intake introduced a guided self-service path for documenting injuries, treatment, healthcare providers, lost wages, expenses and supporting evidence. My role was not simply to design a collection of forms. I helped shape the digital capability: translating operational and legal requirements into a coherent customer journey, aligning cross-functional partners and establishing ways to learn from customer behavior after launch.
How might we digitize a sensitive, legally complex injury-reporting process without transferring the insurer's operational complexity onto the customer?
The challenge
GEICO needed enough detail to begin handling an injury claim: affected body parts, medical treatment, healthcare providers, work impact, expenses and supporting documentation. Customers, however, did not always have every detail available when they entered the experience. They could also be uncertain about what qualified as an expense, whether reporting an injury could affect their rates or whether the information they provided would be considered sufficient.
The digital experience therefore had to do more than capture accurate data. It had to reduce cognitive burden, explain unfamiliar requirements in plain language and provide reassurance without making promises the claims process could not support. At the same time, the team was working within an infrastructure that limited how questions could be grouped, sequenced and summarized.
My role
As Product Design Lead, I owned the end-to-end digital experience, including design direction, interaction strategy, prototyping and alignment with the product roadmap. I translated complex requirements into understandable concepts, managed shifting priorities and guided designers through iterations.
I partnered closely with product and engineering to define scope and feasibility; with content design to make insurance language more understandable; with research to surface customer concerns and satisfaction; and with compliance partners to account for legal and insurance requirements. I also advocated for behavioral monitoring through Quantum Metric, which gave the team greater visibility into abandonment, technical failures and unexpected customer behavior after launch.
Names the time cost and every category of information the journey will ask for, so the customer can decide whether to start now or come back when they have their details.
Shaping the digital journey
The first leadership challenge was determining how a previously conversational process should work as self-service. An adjuster can respond to ambiguity, ask follow-up questions and explain why information matters. A digital experience has to anticipate those needs through structure, content and conditional logic.
I worked across disciplines to turn a large set of claims requirements into a sequence customers could navigate. The journey had to accommodate different circumstances: a customer might have several injuries, multiple healthcare providers, more than one employer, medical expenses, lost wages or documents to upload. Their earlier answers could also change what appeared later in the experience.
Ask only what is relevant to the customer’s situation, using earlier responses to shape later questions.
Use plain language and supporting guidance to explain unfamiliar insurance concepts.
Preserve customer progress where possible so the journey does not have to be completed in one sitting.
Make downstream actions clear, including when supporting documents or adjuster follow-up may be needed.
Treat mobile as a primary context rather than a scaled-down desktop experience.
Working within platform constraints
The platform could not always support the experience I believed customers needed. The team was limited in how multiple questions could be combined on a screen, and the infrastructure did not support a clear progress indicator across the full journey. This mattered because customers were being asked to complete a lengthy process without a reliable sense of where they were or how much remained.
I advocated for an introduction that set expectations and for a stepper or similar orientation mechanism. While not every recommendation could be implemented, documenting these gaps helped distinguish experience debt from intentional design decisions and kept future improvements visible to the team.
A generic "Injury" header and a bare question. Nothing explains what counts as an injury or what happens if the customer does not know.
An eyebrow header names the section, guidance explains the (+) affordance, and an explicit skip cue makes Next a legitimate answer rather than a dead end.
Selection is deferred into a modal so the step itself stays short, and the Next and Back actions disable while the modal owns the screen.
Six fields typed from memory. This is where sessions showed customers pausing or leaving to look up an address, creating timeout and return risk.
Search and autocomplete fill the address and phone number. Manual entry stays available rather than being removed, so an unlisted provider is not a wall.
The five-day threshold arrives with no rationale, and the screen has nowhere to put a second employer.
Says why the threshold matters, states plainly that the answer does not affect coverage, and lets employment stack instead of assuming a single job.
A visual solution under scrutiny
One of the most visible features was an interactive Body Map that allowed customers to identify injured areas. The hypothesis was straightforward: a visual interface could help customers locate an injury when they did not know the correct anatomical term. Implementing that idea was considerably more complex. Engineering had to support front and back views, left and right orientation, zoom behavior and more than 250 selectable areas.
The early results challenged the assumption that a more visual interaction would automatically be more usable. The Body Map initially produced greater abandonment than the existing dropdown, and the experience was particularly difficult on mobile — the primary context for many customers. It took months of iteration before the Body Map outperformed the dropdown, and even then the team continued to question whether the added complexity produced a meaningfully better experience.
A solution can be innovative, technically ambitious and stakeholder-supported without being better for customers. The design had to earn its place through evidence.
The premise: point at where it hurts instead of naming it. Next stays disabled until an area is chosen.
Selections echo back as named chips, so the customer can check that what they tapped matches what the claim will record.
The back view reverses left and right. Getting that legible in one line of copy — on a phone, on a small figure — was a large share of the difficulty.
The existing dropdown. Lower ceiling, but no laterality to explain and no zoom to fight, which is why it outperformed the Body Map for months.
These wireframes abstract the interaction rather than reproduce it. The figure is drawn as simplified greybox zones to show the pattern — area selection, laterality and the front/back toggle. The production interface used a detailed anatomical illustration with more than 250 selectable regions, which is where much of the engineering cost sat.
Building an evidence-based iteration loop
Launch metrics could show where customers left the experience, but they did not always explain why. I advocated for using Quantum Metric to observe customer behavior within the flow. Session evidence helped the team identify broken paths, timeouts and infrastructure problems that would otherwise have appeared only as unexplained abandonment. It also surfaced areas where customers paused, left the experience or struggled to complete required information.
Customer feedback added important context. Some customers were unsure which expenses they could report, including transportation, gas, housekeeping or in-home support. Others felt pressure to provide enough evidence to make their injuries credible. These findings reinforced that the experience needed to communicate purpose and eligibility — not merely present more fields.
Customers paused or left while entering provider details.
They may have been searching elsewhere for provider information, creating timeout and return risk.
Provider search and autocomplete reduced a localized source of effort.
Customers struggled with Lost Wages and multiple employers.
The structure and quantity of employment information were difficult to understand.
The team reviewed sequencing and guidance, while documenting platform limitations.
Sessions exposed broken paths and technical failures.
Some abandonment reflected infrastructure problems rather than customer intent.
Evidence was shared with engineering to diagnose and repair the affected flows.
These changes were important, but they were not the strategic center of my work. Their value was that they demonstrated a repeatable operating model: observe behavior, distinguish design friction from technical failure, prioritize the right intervention and measure again.
Connecting supporting documents to the journey
Customers who reported lost wages, medical expenses or treatment details could be directed to upload supporting evidence such as pay stubs or related documents. Document Upload existed as a separate experience, so Injury Intake had to provide a clear transition rather than imply that the customer was still inside the same flow.
The confirmation experience used customers' earlier responses to identify relevant next steps, including supporting documents and other claim actions. This helped the journey end with direction rather than a generic submission message, although the absence of a full review page remained a limitation.
Next steps are generated from what the customer actually reported — the documents prompt is highlighted because they entered lost wages and expenses.
Document Upload is a different experience, so the transition says so outright rather than implying the customer is still inside the injury report.
Outcomes
Following launch and continued iteration, completion increased from approximately 25.8% to 30.2% — a 4.4 percentage-point improvement. The digital experience also reduced the amount of injury-intake correspondence that had to occur directly between customers and adjusters, while giving the organization a reusable foundation for additional injury-related capabilities.
The work later expanded to support state-specific no-fault forms across New York, Maryland, Delaware, Hawaii and Pennsylvania. That expansion required mapping overlapping and state-specific requirements so the team could reuse common patterns without overlooking compliance differences.
- 25.8% → 30.2%
- Completion after continued iteration
- 5 states
- No-fault form expansion
- 1 evidence loop
- Behavioral monitoring after launch
What I would improve
I would prioritize clearer journey-level orientation. Customers were asked to complete a long and emotionally demanding flow without a consistent way to understand their progress. A visible stepper, time expectation and stronger save-and-return cues would reduce uncertainty and help customers decide whether they were ready to continue.
I would also continue testing the Body Map against lower-complexity alternatives on mobile rather than treating its implementation as settled. Finally, I would add a true review experience so customers could confirm injuries, providers, employment details and expenses before submission.
Simplification is not the removal of necessary complexity.
It is the sequencing of complexity so customers only have to understand the decision directly in front of them.
This project reinforced the importance of measuring ambitious design ideas after launch. The most visually distinctive solution is not always the most usable, and leadership sometimes means questioning a solution the organization has already invested in.
My contribution was helping the team move beyond a set of digital forms toward a measurable product capability — one that could respond to customer behavior, expose technical failures and evolve as claims and regulatory requirements changed.