Edvard Osnaya ← Back to portfolio
Selected Work · Energy / Oil

The software behind a nation's crude logistics

New national regulations changed how hydrocarbon distribution had to be measured, calculated and reported. For Mexico's largest state-owned energy company, that meant purpose-built software — four specialized desktop products for the calculation chain. I led the UX team across all four, and owned the executive reporting product end to end.

Energy / Oil Enterprise desktop software Regulatory compliance Lean UX · staged delivery
RoleLead Designer — UX team lead
Duration2017 – 2019
Scope4 products, one stage at a time
OwnershipReporting product, end to end
4
Specialized products designed and delivered
1
Product I owned end to end, including data analysis
Lean UX
Methodology, applied one product at a time
Desktop
Built for the client's controlled environment
Context

When the regulation changes, the math changes

Mexico introduced new national rules for how hydrocarbons are distributed and how that distribution is calculated. For the country's largest state-owned energy company, compliance wasn't a reporting exercise — it changed the underlying operational math, and the existing tools couldn't produce it.

What the business needed wasn't a dashboard. It needed software that could hold the entire calculation chain — nominations, physical stock, operating ranges, transport capacities, validation, balances and reporting — with enough precision that the numbers could stand up to a regulator, and enough clarity that a logistics executive could act on them.

The Problem Space

One chain, seven links, zero tolerance for drift

Every stage feeds the next. A rounding decision at nomination surfaces as a discrepancy at balance — which is exactly why the products had to be designed as a family rather than as separate tools.

Nominations planned volumes Stock physical volume Operating ranges allowed limits Transport capacity what can move Validation rules applied Balances reconciliation Reports executive view MY PRODUCT precision carried forward at every step — a discrepancy anywhere surfaces at the end
The Work

Four products, designed as a family

Each product handled a section of the chain, but they shared a navigation model, a data language and an interaction pattern for dense tabular work — so an engineer moving between them didn't have to relearn anything.

Products 1–3

The calculation products

The operational core: capturing nominations, tracking physical stock across batteries and tanks, setting and validating operating ranges and transport capacities, and reconciling balances — all with the precision the new regulation demanded.

Owned end to end
Product 4

The executive reporting product

A report visualizer for hydrocarbon logistics executives. I was responsible for this product from end to end — including the information analysis and the database work behind what it could show and how fast it could show it.

Constraints

Designed for a controlled environment

These weren't web products with room to breathe. They were desktop applications inside a state-owned operator's environment, and several design decisions were made by the constraints rather than by preference.

Technical limitations

Desktop application constraints shaped what was possible in layout, interaction and rendering — the design had to work within them, not around them.

Security requirements

Operating inside a state-owned company's environment meant security rules that limited how data could move, be exported and be displayed.

Domain precision

Volumes, densities, API gravity, sulphur, salinity, pressure, temperature — every field carried operational and regulatory weight. No field was decorative.

Density as a requirement

Specialists needed many rows visible at once. Simplifying by hiding data would have made the products slower to use, not easier.

Method

Lean UX, one product at a time

Four products against a regulatory deadline could not be designed in parallel by a small team. We staged them — building, validating and shipping one before opening the next, so each product inherited what the previous one had already proven.

Work beside the engineers, not from a brief

I spent years working directly with the client's specialist engineers. In a domain this technical, requirements can't be handed over in a document — the design had to be built from their working knowledge of how hydrocarbons are actually measured and moved.

Build, measure, learn — per product

Each stage ran the Lean UX loop with the specialists as the validating users: assumptions made explicit, designs tested against real operational cases, and corrections folded in before the next product started.

Carry the patterns forward

Every solved problem — table density, validation feedback, navigation between modules — became a pattern the next product started from. Staging turned sequence into an advantage instead of a delay.

Lead the team through it

I led the UX team across the four products, keeping the shared language consistent while each designer went deep on their own part of the chain.

The Interface

Dense data, made legible

The design language stayed deliberately quiet: a persistent module rail, a fixed action bar, a period selector, and cards that group tables by location or by stage — so attention stays on the numbers.

Landing screen with notification centre and module navigation
01

Entry point & notifications

The module rail on the left, the period selector above it, and a notification centre that surfaces what needs attention — with the export action to the operator's own logistics system kept at the top right.

Crude nomination screen with header data and detail table
02

Nominations

Header records above, line-by-line detail below: reception point, quantity received, water content, API gravity, sulphur, salinity, pressure and temperature. Out-of-range values are flagged in the cell itself, where the correction happens.

Crude stock screen with tank tables grouped by location
03

Stock

Tank inventory grouped into cards per location, each with gross, net and cushion volumes — comparable at a glance, editable in place, and scannable without scrolling through a single monolithic table.

Outcome

What the engagement produced

A compliant toolchain
Four products covering the full calculation chain, built so the operator could meet the new national distribution rules with numbers it could defend.
A shared design language
One navigation model, one data language and one set of table patterns across all four products — so specialists moved between them without relearning the interface.
Full ownership
On the reporting product I carried it end to end — research, information analysis, database work and design — not just the screens.
A team led through it
The UX team stayed aligned across a multi-year, multi-product engagement in one of the most technically demanding domains I've worked in.
Reflection

What I took from it

This project taught me that in a technical domain, the designer's first job is to earn the domain. You cannot simplify a calculation you don't understand — and the specialists could tell immediately whether I had done the work. Sitting with the engineers for years is what made the designs credible, and it's why I still start by learning the math before touching the interface.

The highlighted line is a placeholder in your voice — replace it with the lesson that feels most true to you.

Selected work

WinItAll — an app redesigned in four weeks

→
Selected work

Provider platform redesign

→