Designing trust into automated climate risk
Climate risk, reimagined from the ground up
Arbol is a parametric climate risk platform that uses real-time weather data, AI-driven underwriting, and blockchain-anchored smart contracts to deliver insurance payouts automatically — no claims, no adjusters, no delays.
I joined the product team as a senior product designer with a mandate to make the AI/ML underwriter and smart contract execution flow legible, trustworthy, and operable for a diverse set of users: agricultural brokers in rural Texas, energy traders, and enterprise risk managers at global banks. These were not typical SaaS users.
"The system was technically remarkable — but users had no window into how it was making decisions. We had a trust problem wrapped inside an opacity problem."
Automated decisions that no one understood
Arbol's core technical infrastructure was formidable: petabyte-scale climate datasets from NOAA, NASA, and ESA fed into ML pricing models, and Chainlink oracles triggered smart contract payouts on-chain when weather thresholds were crossed. It was genuinely novel technology.
But the user experience around it had been designed by engineers, for engineers. Brokers enrolling a cotton gin in West Texas couldn't interpret a pricing curve. Underwriters couldn't explain to a client why a contract was priced the way it was. And no one had a clear mental model of what would actually happen and when if a triggering weather event occurred.
The result was friction at the point of sale, erosion of trust at the point of payout, and an inability to scale into new verticals without heavy hand-holding from Arbol's internal team.
- Opaque pricing logic. The AI underwriter output a premium price with no legible rationale — brokers were expected to trust a number that materialized from a black box.
- Invisible contract state. Once a policy was bound, users had no live view of how close weather conditions were to triggering a payout.
- Smart contracts without a human narrative. Blockchain execution was technically verifiable but experientially inert — users received no meaningful confirmation or explanation when payouts executed.
- Mismatch in user sophistication. The same platform served commodity traders and first-generation farmers. Existing UI assumed the former.
Listening before designing
Before touching wireframes, I ran three rounds of contextual inquiry and concept testing over eight weeks. I interviewed fifteen brokers and agents, four enterprise risk managers, three of Arbol's internal underwriters, and three clients from the agriculture vertical including a cotton gin operator in Lamesa, Texas who had already received a payout.
They needed to sell confidence
Brokers weren't just purchasing a product — they were endorsing it to their clients. They needed the platform to give them language and logic they could hand across a table. A premium they couldn't explain was a premium they couldn't sell.
They needed audit trails
Risk managers at banks and energy firms needed payout documentation that satisfied internal compliance. Blockchain finality was irrelevant to them — what mattered was a paper trail that read like a legitimate insurance settlement.
They needed simplicity and reassurance
First-time parametric insurance users — small farmers, co-ops, gin operators — didn't need to understand the mechanism. They needed to feel certain the product would work and that someone would tell them when it did.
"The insight that reframed everything: users weren't afraid of automation. They were afraid of being invisible inside it of having no way to know what was happening or whether anyone would tell them."
Three distinct problems requiring distinct solutions
Explainable AI pricing
How do you surface machine learning pricing logic to a non-technical broker in a way that builds confidence rather than confusion?
Contract state visibility
How do you give users a live sense of where they stand relative to a weather trigger without overwhelming them with data they can't act on?
Smart contract as human event
How do you translate an on-chain execution event into a communication artifact that feels meaningful, auditable, and emotionally complete?
Multi-tier user mental models
How do you design a single platform that serves users across a spectrum from commodity trader to subsistence farmer without patronizing either end?
What I built, and why
| Decision | Approach | Rationale |
|---|---|---|
| AI Pricing Explainability | I introduced a pricing breakdown panel that decomposed each premium into weighted contributing factors: historical event frequency, geographic risk index, coverage window length, and selected trigger threshold. Each factor was rendered as a plain-English sentence and a proportional visual bar — not a formula. | Brokers needed to internalize and then re-externalize the logic to a client. Giving them a structured narrative they could read aloud was more useful than numerical precision they couldn't translate. |
| Trigger Proximity Monitor | I designed a persistent contract status widget — present on the client dashboard throughout the active policy period — showing current weather conditions against the contracted trigger threshold. It updated on a 24-hour delay to match data refresh cycles and used a single, unambiguous proximity indicator rather than a dashboard of raw weather metrics. | Users didn't need meteorological literacy. They needed to know one thing: how close is this to paying out. The single-metric approach reduced cognitive load and support volume significantly. |
| Smart Contract Settlement UX | When a Chainlink oracle confirmed a threshold crossing and a payout executed on-chain, the platform generated a Settlement Record: a human-readable document combining plain-language event description, the specific data source and timestamp that confirmed the trigger, the smart contract transaction hash, and the payout amount. Delivered by email and available in-platform as a downloadable PDF. | The blockchain transaction was verifiable but not legible to most users. The Settlement Record served as the "official document" that users needed for records, compliance, and their own sense of closure. |
| Progressive Disclosure by Role | I introduced a role-aware information architecture that surfaced different levels of detail based on whether the logged-in user was a broker, an enterprise risk manager, or a direct client. Brokers saw pricing model inputs; enterprise clients saw compliance-ready documentation; direct clients saw weather-to-payout narratives. | The same underlying data had vastly different utility depending on who was reading it. Designing one universal information density was a false economy — it served no one well. |
| Contract Builder Interaction Model | I redesigned the contract parameterization flow from a form-first to a map-first experience. Users began by selecting a geographic location on a satellite map, which then seeded historical weather data visualizations specific to that location — rainfall distributions, temperature ranges, historical payout frequency. Contract parameters were set against this location-anchored context. | Abstracting location into a coordinate field stripped all context. Grounding the configuration flow in a visible, specific place made risk feel concrete and made contract parameters feel consequential rather than arbitrary. |
Working across hard boundaries
This project required sustained collaboration with three teams whose professional vocabularies didn't naturally intersect: the data science team building the ML pricing models, the blockchain engineering team maintaining the smart contract infrastructure, and the commercial team selling to brokers and enterprise clients.
I ran weekly translation sessions meetings where I would present back to engineers what I understood their systems to do in plain language, and they would correct me. Those corrections became the source material for interface copy, explanatory UI patterns, and the Settlement Record language.
I also embedded myself in three broker sales calls during the research phase. Watching how the commercial team narrated the product to prospective clients gave me the clearest possible picture of what the interface needed to say on their behalf.
- Ran 15 user interviews across broker, enterprise, and direct client segments — with sessions conducted remotely and on-location in agricultural contexts.
- Delivered 4 rounds of prototype testing, from low-fidelity concept validation through high-fidelity usability testing with live data.
- Produced a component library covering data visualization patterns, contract state indicators, and settlement documentation templates.
- Authored an AI explainability content guide that became the standard for how the data science team communicated model outputs to non-technical stakeholders across the organization.
What changed after the work shipped
The redesigned AI underwriter and smart contract UX rolled out across the broker portal in Q3 2023 and was incrementally extended to the direct client dashboard through Q4. Outcomes were tracked across a mix of quantitative platform metrics and qualitative broker feedback.
Broker & Client Impact
Percentage improvements post-launch
Payout Comprehension
Clients who understood their settlement logic
Beyond metrics, the design work materially changed how Arbol presented itself to new verticals. The map first contract builder was specifically cited by the commercial team as a pivotal sales tool in expanding into energy derivatives and travel verticals categories where the risk-to-geography relationship was central to a prospect's ability to imagine the product working for them.
The Settlement Record format also became a template used by the commercial team in prospect demonstrations showing a completed payout document from an actual agricultural client was a more effective sales artifact than any pitch deck slide.
What this project taught me
Designing at the intersection of AI and financial automation required me to resist two common failure modes: over engineering transparency (turning every model weight into a visible knob) and under engineering it (hiding complexity behind false simplicity).
The right level of explainability isn't determined by what's technically possible to surface it's determined by what users actually need to do next. A broker needs to sell. An enterprise risk manager needs to file. A farmer needs to feel certain. The design challenge was building systems that served all three without treating any of them as the default user.
Smart contracts, in particular, presented a design problem I hadn't encountered before: how do you make an event that happened entirely outside human action feel human? The answer, I came to believe, was in the documentation layer not in making the contract mechanism visible, but in giving the outcome meaning through language, context, and format.
Algorithmic trust is a design problem
When AI makes a consequential decision and a smart contract executes it without human intervention, the design of the surrounding experience — what users see, read, and receive — is the entire trust infrastructure. There is no human adjuster to compensate for an interface that fails to communicate. The design is the relationship.
Earlier collaboration with compliance
The Settlement Record format went through three revision cycles with the legal and compliance teams after initial design — a friction point that delayed the feature. In retrospect, embedding a compliance review at the research phase rather than the review phase would have saved significant iteration time and likely produced stronger documentation standards from the start.