A system for the quantitative assessment of well blowout risk during the operational phase of the well.
Europe & Brazil
Location
Product Designer
Role
2024 - 2026
Date
DNV is an independent assurance and risk management specialist operating in more than 100 countries. Driven by the purpose of safeguarding life, property and the environment, it empowers its customers and their stakeholders with trusted data and insights, so that critical decisions can be made with confidence.
WHAT IT IS
in partnership with
Well integrity engineers use the tool to make critical decisions about barrier failures during production, intervention and temporary abandonment phases — decisions that can prevent environmental accidents and save lives.
BEFORE
Something already existed when I took over the project. But all of it was hard to understand. It demanded a lot of effort.
We needed to translate the risks of a well into clear visual decisions that are easy to perceive.
PROCESS
01
Product discovery
Sessions with the client and engineers to understand the business rules and the domain before any design decision.
02
Persona definition
Mapping the user profiles. Their contexts, needs and access levels inside the platform.
03
Initial ideation
Exploring solutions for the challenges, focused on simplifying complex flows without losing functionality.
04
Architecture and scope
Defining the system modules and how they connect, making sure the structure could hold the complexity.
CONCLUSION
Carlos Mendes
Integrity manager
He has technical knowledge. He makes sure no well under his management shows risk or evidence of leakage. He needs to:
Access critical information quickly and precisely
Spot problems without having to interpret the data
Ricardo Alves
Operations manager
He has no technical background. He doesn't understand the system, the reports or the analyses the engineering team produces. He needs to:
Understand the impact of a failure before it happens
Read executive reports without technical complexity
In other words, the old system solved neither the engineer's problem nor the manager's.
How do you translate a probabilistic model into clear visual decisions for technical engineers?
How do you cut the time it takes to read a well without hiding the analytical depth the engineer requires?
How do you create a single visual language for something that only existed as numbers and tables?
How do you design for two audiences with completely different backgrounds?
How do you let engineers test hypotheses without putting the real well data at risk?
To replace the table view, we created visual representations of each well — 2D plans that show its containment barriers spatially and intuitively. The engineer stopped interpreting data and started seeing the well.
The problem becomes something you locate, not deduce.
Interactive elements with details on every barrier
Immediate visual location of the problem
To fix information overload without hierarchy, the interface started using color and ambiance as its main language. The whole screen changes state — green, yellow, red — reflecting the real situation of the wells.
The engineer grasps the scenario before reading any data.
Overall state perceived in seconds, no reading required
Visual hierarchy that guides attention to the problem
To let engineers test hypotheses without impacting the real environment, we created a switch that toggles between the operational and the test environment. In simulation mode you can change barrier states and observe how the well would behave.
A decision tool that simply did not exist before.
Hypothesis testing without impacting real data
Anticipating consequences before changes to the well
Low fidelity to validate the logic of the screens before spending time on visuals. We tested where each piece of information should sit, with no color and no distraction.
Flows validated with engineers before the visual layer
Navigation tests straight with the people using the system daily
We created templates covering the most common well types — the structure barely changes between them. Each plan starts from a template and only gets the specific adjustments.
5 templates covering the main well types in the operation
Targeted redraws instead of rebuilding the whole plan every time
Reusable components to handle 100+ screens without each one becoming its own special case. They came from the product's real needs, not from an off-the-shelf kit.
Patterns created from real cases in the platform
Consistency across modules without redoing work on every screen
Final application of the system on the production screens. Focused on information density without turning into visual noise.
Visual hierarchy designed for fast decisions under pressure
Color and ambiance as part of the language, not decoration
RESULT
WHAT I LEARNED
To design a complex product, understanding comes before designing. Before touching a single screen, I had to understand how a well worked, what counted as risk, why it counted and when it counted.
Mapping pain is not enough. You have to understand why each pain exists, otherwise you solve the wrong symptom. Or make what was already bad worse.
That is the level of technical fluency that separates a design that only looks good from a design that solves. On this project, most of the work was not arranging screens, it was building up enough technical context to know exactly what each pixel had to carry, and why.
