Document Request — Letter of Credit

1. Challenge

Context

Letters of Credit are used in international trade to lower risk. Payment only gets released once certain conditions are met, which makes them complex by nature. There are strict rules, exact terms and conditions that carry legal weight. The document request is the part that defines the exact documents a seller has to provide before they get paid.

Problem

Two things were true at the same time. The content was expert level and carried legal weight, so I couldn’t reword it or cut it. However, the person filling it in was the importer applying for the Letter of Credit, who are not necessarily Trade Finance experts.

The old paper forms threw everything at them as one dense block of fields with no structure. That made mistakes easy and hid them when they happened. A mistake here delays payment or releases it when it shouldn’t. So the problem was never about making it simpler. It was about getting a non-expert through something genuinely complex without losing any of the detail that mattered.

Constraints

The document request step had to be handled carefully. While it might seem like something that could be simplified, it wasn’t an option here.

The exact legal wording had to stay

Some information had to be displayed in a specific order

Content couldn’t be moved to other steps even if a section felt heavy

The Design System presented some limitations

So the brief set the challenge. Keep every requirement, every term and the original order while making it something a first-timer could get through in a flow where mistakes are costly.

Approach

My design thinking process was shaped by the one-month window timeframe. Some stages ran deep, like competitive analysis and sketching, while others ran lean, relying on proxy research and close collaboration with the PM and engineering team instead of user research. The structure below shows where the effort went.

Design thinking process — Challenge through Discover, Define, Ideate, Prototype, Test and Implement stages with sub-activities at each step

2. Discover

Stakeholder interviews

I worked closely with the business PM and engineering team throughout, using their input on legal, business and technical constraints to shape realistic design decisions early rather than treating engineering as a final handoff.

Competitive analysis

I reviewed how banks currently handle this on paper. Every form followed the same pattern: one dense block of fields, no grouping, no guidance and nothing to catch a mistake before submission.

East West Bank — Application and Agreement for Commercial Letter of Credit, dense multi-section paper form

SMBC — Application for Commercial Letter of Credit, grid-based form with documents required checklist

UOB — Standby Letter of Credit application form, numbered sections with applicant, beneficiary and purpose fields

CBI — Issuance of Import Letter of Credit application, multi-page form with shipment and document fields

Proxy research

This project moved within a one-month window, so there was no access to importers for primary research. I used the strongest available inputs instead: support tickets, RFP requirements, client calls and patterns from similar trade finance journeys.

3. Define

User definition

The user was the importer applying for the Letter of Credit. They run a business that buys goods from abroad, but trade finance isn’t their world and some are even doing this for the first time. They’re handed the seller’s requirements and expected to get them right, in a process where one mistake can hold up payment or the whole deal.

Insights synthesis

The paper forms had already shown where this goes wrong: unclear requirements, missed details and no check before submission. That became the brief for the design:

Clarify document requirements
Reduce missing or incorrect documents
Support review before submission

4. Ideate

Sketching

Since I couldn’t reduce the information, I focused on how it was structured instead. Two decisions shaped it:

1. Every Letter of Credit needs a different mix and number of documents. One big fixed form would be mostly empty fields you don’t need and not in the best order. So instead the user builds their list one document at a time. That matches how the request actually works.

2. Each document is its own little form with its own details like originals, copies and instructions. So I treated each one as a self-contained unit rather than a row in a list. Once you confirm a document it folds up into a summary card on the same page. That way you keep the whole list in view instead of losing your place as you move from screen to screen.

I sketched both decisions until the structure held: grouped documents, add one at a time and confirmed entries folding into a stack.

Sketches — transportation and commercial document groups with method or doc-type rows

Sketches — transport documents summary with completion checkmarks and stacked doc-type cards

Sketches — transportation documents step with mode, add-document actions and commercial docs, plus detail views

Sketches — expected document cards, list navigation pattern and expanded transportation or commercial entry

5. Implement

The final flow puts those decisions to work. The user adds a document, fills in its details and confirms it. The confirmed document becomes a summary card showing the key info and any card can be edited in place without losing progress.

This creates a clear interaction pattern:

Add a document

Define its requirements

Confirm and review it as a summary

Edit or remove it if needed

One document at a time
Each document is completed in isolation, reducing the need to process multiple requirements at once.

Certificate of origin — focused form for document type, originals and copies, country, issuer and instructions

Insurance policy — focused form for document type, coverage percentage and risks covered

For example, transport method changes which documents exist and what each one asks for, so the form adapts to the selection rather than showing every field at once.

Wireframe flow for transportation documents: sea transport and bill of lading versus multimodal document, showing how selections change the form

Cards you can scan, not click open
Key information is surfaced in a compact card, allowing users to verify details without reopening the form.

Commercial invoice — summary card showing originals, copies and additional instructions, with edit and delete actions

Add, review or remove as you go
Each document is treated as a repeatable unit, making it easy to add, review or remove items as the list grows.

New import Letter of Credit — Documents step showing expected documents as a stack of summary cards plus an in-progress entry

Edit any card without losing your place
Users can update individual documents without affecting the rest of the flow, maintaining a sense of control.

Edit and delete actions on a document summary card

The result keeps the overview you get from a full form and the focus you get from doing one thing at a time. It drops the dense wall of fields from the old version and it avoids the lost context you get from a step-by-step wizard. In a flow where a small mistake can delay the deal or make it fall through, the confirm and review step works as a safety check rather than a hassle.

New import Letter of Credit — Documents step: transportation documents summary and commercial invoice form

Expected documents with transportation and commercial invoice summaries, packing list form in progress

Stack of document summary cards with insurance policy fields open for entry

Full list of expected document summaries and other documents free-text entry

Document list with inspection certificate form expanded

Document list with certificate of origin form expanded

As more documents are added, the layout remains easy to scan due to clear separation, consistent structure and predictable interactions, preventing the experience from becoming overwhelming.

6. Outcome

It was adopted across 3 client implementations. The structure was built to cut down on mistakes and reduce how much manual checking was needed in a step where accuracy decides whether payment goes out. It kept the full complexity of the requirements intact while making it something a non-expert could actually complete.