Role and responsibilities

Process

Agile sprints: design, test and deliver repeated sprint by sprint until each workflow was release ready

What the business asked for

Challenges

Pain points we uncovered

1. 1

   Every product had its own application, so users logged in separately to sell a product and again to check its status.

2. 2

   Health history, applicant details and signatures were collected again for every product, which was redundant and slow.

3. 3

   Users could not add multiple products to one enrollment.

4. 4

   Getting a quote meant filling in long forms first.

5. 5

   There was no easy record of the e-kits that had been sent.

6. 6

   Four signature processes, each handled differently, made signatures hard to store and hard to track.

Design process

Key solutions

Select any screen to view it full size.

Dashboard

Start any task from one home screen

Quotes, e-kits and case status sit together, so brokers see what needs attention the moment they sign in.

Rate quotes

Quotes without starting an enrollment

Brokers can price any product at any time using a few basic details. One set of inputs returns quotes for every product, turning the tool into a true one-stop shop.

E-kits

Send and track e-kits on one page

Sending an e-kit automatically records it in a searchable history, so follow-up actions like editing or resending take fewer clicks.

My cases

Case status with the next action beside it

Brokers see every case’s status at a glance and can complete signatures, email the case, read its summary or delete it once complete.

Plan eligibility

Every eligibility question on one page

Applicants learn whether they qualify for all products without separate logins or channels.

Health history

Enter health history once

One health history now applies to every product, and history for each family member is captured on the same page.

Payment information

Flexible electronic payments

Users save bank details once and assign any account to any product with the payment method they prefer.

Agent information

Customization built for agents

Agents split commission by product, choose how policy documents are delivered and keep notes for future reference.

Signature process

Four signature types, one smooth step

In-person, voice, email and secure-question signatures now live in a single guided screen, so users finish their task without switching processes.

Impact

After launch, the unified platform changed how brokers started and finished their work.

Overview

Delta is consistently recognized for excellence, from passenger experience to customer service, and wanted the same care for travelers with lost or damaged bags. The airline spends around $10 million a year on damage claims.

The Enterprise Mobility team set out to build a damage report application that captures analytics on damaged bags, helps agents resolve baggage issues with the right information, and reduces the money spent on claims.

Role

I led the complete design strategy, partnering with a business analyst, developers and subject matter experts from the first interview through to the live pilot.

Process

Discover

I interviewed SMEs who had previously worked in the roles we were designing for, which gave us a rare mix of business and real-user perspective. Together we identified ramp agents and baggage service agents as the primary users.

We explored every scenario where the app would be used. For example, a ramp agent loading an aircraft who finds a damaged bag opens the app and submits a report on the spot. To encourage reporting, the business wanted a standalone tool with anonymous submissions.

We then went into the field to learn how the baggage process really works and the words agents use for everyday objects.

Pain points from the ramp

1. 1

   No way to track or report bag damage, which made it hard to resolve issues with upset customers.

2. 2

   Difficult to know when, where and how the damage occurred.

3. 3

   Hard to identify which type and part of the bag was damaged.

Design

I created a workflow diagram so the whole team could follow the user journey. At this stage we spotted missing scenarios and adjusted the flow before any screens were built.

Question tree

I drafted a decision tree so everyone understood the question structure and which choices appear after each answer. Try it below. Each answer moves you forward, just like in the app.

Reporting flow, part one

Reporting flow, part two

User testing was the most effective way to gather meaningful feedback.

Removing the scan icon

A scan icon beside the input was meant to nudge agents toward the scanner gun. Rather than debate it internally, I proposed testing it. Agents tapped the icon instead of using the scanner, so we removed it.

Readable in full sunlight

The app is used outdoors, and bright light washed out our first dark palette. I designed three color variations and tested them on the ramp. The light palette won, and it is the one shown in the visual design above.

Before

After

A success screen people can read

The success message originally flashed and disappeared. Agents were unsure what number they had just seen, so we added a home button that keeps the confirmation visible until they move on.

Before

After

From toggle to radio buttons

Selecting Aircraft opens an inbound or outbound choice. Agents wearing gloves struggled with the toggle, some slid it instead of tapping, and others found it unclear. We switched to radio buttons, which succeeded when retested.

Before

After

Performance testing and benefits

We tested the app in real time and captured the analytics the business expected, from station and area to item type and damaged part.

UX approach

Our team’s end-to-end UX process.

Method: user interviews

We ran 11 time-boxed interview sessions across 5 user groups to understand and validate the current process.

Current process, as it happens today

A task analysis of how an SLA moves between merchants, assortment planners (AP) and channel management (CM).

1. Merchant + AP
   1

   AP partners with merchants to plan an SLA strategy by category. After merchant approval, AP emails the SLA request to CM.

2. CM
   2

   CM replies by email with the SKUs to onboard and the proposed building list.

3. AP + Merchant
   3

   AP reviews the building list with merchants and shares a spreadsheet of SKU count, target SLA, building count and locations.

4. AP
   4

   AP confirms the plan back to CM.

5. CM
   5

   CM onboards the SKUs, adds them to its SLA dashboard and can report status for each SKU and building.

6. AP
   6

   AP monitors CM’s dashboard, while AP analysts track shared and onboarded data in a separate tracker.

Maintenance process

1. 1

   AP submits a form with a spreadsheet template of proposed SLA data.

2. 2

   The form stores the data and template in a shared repository.

3. 3

   A data table combines form data, CM onboarding status and other SKU details.

4. 4

   AP analysts pull CM data to see which SKU is assigned to which DC.

5. 5

   AP queries the data for a holistic view of SLAs.

Challenges in their own words

Initial opportunities

Main findings

Next steps

1. 1

   Share research with the supply chain network team.

2. 2

   Partner with them to understand how CM uses AP’s proposed SLA values.

3. 3

   Map the database flow to see what information is available and where.

4. 4

   Sketch future state ideas, then validate with peers, stakeholders and users.

Appendix: domain knowledge

Context I documented to help the wider team speak the same language.

A store-only SKU becomes shared once it is stocked in fulfillment centers, so the category depends on where the SKU is available.

SLA framework

The SLA depends on the delivery method, parcel or truck, and the SLA drives how many buildings a SKU must be stocked in.

Affinity mapping

We captured every interview on a shared board, organized notes by question and participant, then clustered them into themes and set aside what was out of scope.

Themes that emerged

What merchants told us

Persona

Built from the online merchant interviews. Name and details are fictional.

Scenario mapping

We mapped what merchants do, think, see and feel while trying to get visibility today, and marked where the pain concentrates, since that is where the biggest need lives.

User need statements

As an online merchant, I need…

1. 1

   …visibility into what is stocked where, by which supplier, and how much, so I can understand my entire portfolio’s standing.

   Chosen for ideation
2. 2

   …to view and differentiate national and regional assortment, so I can tell what products are where and how they reach customers.

   Chosen for ideation
3. 3

   …to analyze the performance of all my assortment types by units, margin, dollars, cost and retail, so I offer the best products in the best locations.

4. 4

   …to reduce the time it takes to gather assortment data, so I can make informed decisions quickly.

   Chosen for ideation
5. 5

   …to manipulate my data and see my category by attributes such as color and size, so I can curate my assortment and avoid over-penetration.

Ideation storyboards

Working from need 1, the team sketched how a merchant would get to the answer step by step.

Impact and feasibility

We plotted each idea by user impact and effort to decide what to take forward with users.

How the assistant fits the end-to-end process

A simplified view of how a broker submission moves from inbox to underwriter, with the assistant doing the heavy lifting.

Research approach

User journey map

The journey map framed the study: where underwriters feel pressure during new business intake, and where the assistant could help most.

Key usability themes

1. 1

   Accuracy is essential for adoption. Time savings disappear if underwriters must check every value.

2. 2

   Everyone sees potential, if it reduces processing time.

3. 3

   Prioritization must be transparent, with visible scores, before underwriters will work from the console.

4. 4

   The console is overwhelming, with too many items and no way to remove or focus them.

5. 5

   The external research risk meter is a major time saver. Buildings at one address should be grouped.

6. 6

   Underwriters still prefer email to prioritize work and open documents.

7. 7

   All participants preferred the redesigned submission summary.

Conclusion and recommendations

Data accuracy is the critical success factor. Underwriters value external research and workups, but usefulness depends on trust in the data, and prioritization must fit a workflow that stays centered on broker relationships and email.

• 95%+data accuracy before relying on automation
• 1–2 weeksdefault console window with only actionable items
• High · Med · Lowtransparent, color-coded priority levels, each with a reason
• 1 addressgrouped buildings with combined TIV and count
• Outlookdesigned alongside, not as a replacement