04 / Digital surety bonds · Operational platform

ASERTA

Digitizing onboarding and issuance with a clear experience.

Improving an existing platform to digitize procedures, organize client records and support operational work. The design connects documents, review, signatures and surety bond issuance.

Outcome: Incremental implementation

Risk confirmation modal (Spanish UI) with three editable risks, a selector to add more and a button to create the requests and continue. — Portfolio reconstruction · sample data (Spanish UI).

Role: Product Designer
Scope: Client onboarding and surety bond issuance
Delivery: Incremental MVP · reviews after each sprint
Evidence: Design cuts for development · handoff · frontend observations

The challenge

The challenge: Digitizing the process without passing its complexity on to people

The goal was to digitize onboarding and issuance, store client records and make operational work more efficient through a better experience. The platform already existed; the redesign addressed its workflows, information needs and conditions for moving forward.

The experience challenge was continuity: organize documents by participant, show what needed review, enable corrections and explain how to handle exceptions.

My contribution

My contribution: From operational knowledge to handoff

I contributed to improving the experience of an existing platform. My work began by translating the business team’s operational discovery into an actionable view for design: actors, documents, rules, exceptions and dependencies.

I contributed to designing the onboarding and issuance workflows, with their states and exceptions, and to supporting MVP-based development: design cuts for development, handoff notes and frontend observations in the reviews after each sprint.

Value proposition

Value proposition: Clear stages, reviews and recovery

Digitize onboarding and issuance, organize records and support operational continuity through clear stages, reviews and error recovery.

Decisions and evidence

Decisions and evidence: Making rules and exceptions understandable

Operational discovery as the starting point

The business team had already explored the operational process. That knowledge became the foundation for understanding the procedure before changing the interface.

01 · Business discovery
Process background, operational needs and critical points.
02 · Handover to design
Sessions to make language, roles, rules and edge cases explicit.
03 · Process model
Stages, decisions, documents and owners connected in one journey.
04 · Workflow design
Screens, states, recovery and handoff aligned with operations.

Designing an operational platform meant modeling the system, not just screens

Actor
Applicant, participants and internal teams.
Record
Documents, validity and review status.
Rule
What enables, blocks or requests authorization.
Recovery
How to correct, save and resume.

Portfolio synthesis. Visual examples in this case use sample information.

Onboarding · Make each stage visible

Navigation separates document upload, verification, summary and signature. Documents are grouped by participant, with upload actions beside each requirement. The proposal makes the stages and outstanding documents visible.

Onboarding screen (Spanish UI) with the stages document upload, verification, summary and signature; the principal’s documents are grouped, with an upload action for each requirement.

Onboarding · reconstructed from the original design with sample data and adapted typography (Spanish UI).

Issuance · Keep human review in the workflow

The sequence connects the source document with risks and policy wording, preview and issuance. The document and the interpreted information appear on the same screen, with options to edit fields, reprocess the document or replace it. Extracted information is a starting point that people review and correct.

Issuance screen (Spanish UI) with a sample source document on the left and interpreted beneficiary and document data on the right, plus options to reprocess or re-upload.

Issuance · portfolio reconstruction with a sample document, sample data and adapted typography (Spanish UI).

Review before moving on

Risks detected in the document appear as an editable list. People can remove any that don’t apply or add others before creating the requests.

Reconstructed risk confirmation with sample data. Internal codes omitted.

Exceptions · Designing for what can go wrong

The files cover missing documents, inconsistencies, correction requests, waiting states and failures at different stages. Each piece defines what people are told and which action they can take.

Correction request modal (Spanish UI) with a field to describe the information to correct and Cancel and Send buttons. — **Correcting during signature** If someone spots incorrect information, they can describe it and send a correction request without leaving the process.

Authorization required modal (Spanish UI) with sample reasons and buttons to leave the operation pending or request authorization. — **Authorization required** When a condition blocks issuance, the modal explains why and offers two paths: leave the operation pending or request authorization.

Onboarding and issuance reconstructions (Spanish UI). Reasons and system name generalized.

Handoff · Defining behavior for development

Design accompanied MVP-based development and the reviews after each sprint. Design cuts for development and frontend observations preserved decisions about fields, actions, conditions and states, supporting continuity beyond the initial handoff.

Handoff note (Spanish) for the risk confirmation modal: it describes the content, the actions and when the main button is enabled.

From design to behavior

The note sits next to the screen and specifies what the modal contains, what each action does and when the main button is enabled or disabled.

Adapted excerpt from a handoff note in the issuance file (Spanish). Internal system names omitted.

Impact and actual scope

Impact and actual scope: From operational processes to incremental implementation

Development was delivered incrementally by MVP, with reviews after each sprint. Workflows and rules moved into implementation step by step; handoff notes and frontend observations document the continuity between design and development.

Implementation evidence

Onboarding: Design cut for development · 18 Dec 2024
Issuance: Design cuts for development · 1 Apr and 9 Jun 2025
Process: Incremental MVP delivery, with a review at the end of each sprint

Learnings

Learnings: Exceptions are part of the experience

Digitizing a procedure means defining what is requested, who reviews the information and how work resumes after an error. Extracted data needs a visible human review step and a way to correct it.

Documenting corrections, authorizations and state changes brings the workflow’s behavior into the handoff, alongside its screens.

What can’t be claimedwithout measurement

What can’t be claimed: Incremental implementation, impact not measured

There are no post-implementation metrics: no time savings, error reduction, adoption or business results are claimed.
Design cuts for development document deliveries and their sequence, not production performance.
Screens are reconstructions with sample data; they don’t reproduce internal rules or real documents.