case study № 02 · enterprise ux · john deere · 2026

john deere credit hub — guarantor

role
sole ux designer, embedded with product & engineering
responsibilities
design exploration, interaction & interface design, stakeholder presentation
outcome
four directions explored, one recommended + shipped
1 — strategy · the brief

When a dealer adds a guarantor to a financing application, the analyst needs to select a guarantee type before making a credit decision. The existing interface had no way to handle it. I needed to add that capability without disrupting a dense, daily-use interface.

the process

1strategy
2explore
3evaluate
4recommend
5implement
context

Guarantors appear on Canada installment and lease applications only — a small percentage of cases, but a required step when they do. Analysts working the Involved Parties tab had no place to record the guarantee type and no path to a decision without it.

the options

Three guarantee types needed to be selectable: Guarantee Already on File, Unlimited Guarantee and Limited Guarantee. The question was where and how to surface these options without adding friction to an already steady workflow.

2 — explore

I spoke with a credit analyst to understand how the guarantor workflow operated before designing anything. From there I explored four directions.

01

Banner + separate section

A prominent alert at the top of the tab, with a dedicated guarantee section below

Banner + separate section
02

Cards

Guarantors grouped into expandable cards, with the guarantee type input inside each card

Cards
03

Integrated table row

Guarantors added as rows inside the existing Involved Parties table, with guarantee type as a column

Integrated table row
04

Inline dropdown

A dropdown placed directly inside the expanded applicant row, where the guarantor's information already appeared

Inline dropdown
3 — evaluate

Each option solved the problem, but not equally. The banner and separate section added a new layer of navigation. The cards introduced a UI pattern that didn't exist elsewhere within the platform. The integrated row created visual ambiguity between applicants and guarantors. The inline dropdown required nothing new: no new section, patterns, nor relearning.

4 — recommend

I recommended the inline dropdown. It kept the guarantee type selection in context, next to the guarantor it applied to, inside the table analysts were already using. I presented all four options to the PM with rationale for each. We both agreed the dropdown was the best solution.

recommended — inline dropdown
Inline dropdown — recommended solution
5 — implement

The final design included a validation state: if an analyst attempted a credit decision with a guarantor present but no guarantee type selected, the system surfaced a warning and blocked them from proceeding. With this addition, the feature shipped to production.

decision modal — guarantor warning
Decision modal with guarantor warning
takeaway

In a dense, daily-use interface, the solution that requires the least relearning serves the user most reliably. The dropdown won not because it was the most elegant option, but because it was the most respectful of the context it was entering.

next up

Plume HomePass Ecommerce Store