Clair Ridge platform, West of Shetland in the North Sea — one of BP's largest and long-running operations.
British Petroleum
Risk Toolkit
BP has a suite of four safety applications used by teams who inspect and monitor offshore oil rigs in the Gulf of Mexico, the North Sea, Azerbaijan, Angola, and elsewhere.
The suite, called Risk Toolkit, covers different phases of the same job: assessing risk before a well starts, verifying the rig itself, monitoring safety during active operations, and tracking issues over time.
I was brought in to work on Rig Verification (RV). BP safety personnel use it during 24 to 36 hour on-site inspections of offshore platforms. These inspections happen before BP moves onto a leased rig, before drilling begins, and periodically throughout the contract.
The Work
- Two angles on the same process. I interviewed a Rig Verifier — someone with 20+ years of offshore experience who physically boards platforms to inspect equipment, barriers, and safety systems — and the developer who built the application around that workflow.
One knew what happens on the rig. The other knew what happens in the system. That combination — the domain expert and the technologist — is at the heart of most good product work. I filled in gaps with secondary research and worked with another researcher to round out what the interviews couldn't cover.
From all of that I built a service blueprint: a map of every step in the verification process, who does what, what gets produced, what systems are involved, and where things hand off between BP and the rig operator.
- Built it to hand off. Rig Verification was the first of four planned blueprints covering the full Risk Toolkit. The structure (swimlanes, role profiles, application states, output documents) was set up so the remaining three could follow the same template.
Other designers could pick them up, and we could start looking for overlapping or bottleneck areas across the full toolkit.
One knew what happens on the rig. The other knew what happens in the system. That combination — the domain expert and the technologist — is at the heart of most good product work. I filled in gaps with secondary research and worked with another researcher to round out what the interviews couldn't cover.
From all of that I built a service blueprint: a map of every step in the verification process, who does what, what gets produced, what systems are involved, and where things hand off between BP and the rig operator.
Other designers could pick them up, and we could start looking for overlapping or bottleneck areas across the full toolkit.
The Stakes
Rig verification isn't paperwork. It's the process that finds the gaps before someone gets hurt, or before something much larger goes wrong.
The Deepwater Horizon discharged for 87 days and affected 1,300 miles of Gulf Coast. BP made commitments after that spill about how well operations would be managed, monitored, and verified. The Well Delivery Workbench is part of how those commitments get kept.
Live Links
Risk Toolkit Landing Page
Interactive Service Blueprints (not fully functional)
Expand Details ►
Research Methodologies
- Stakeholder Interviews
- Service Blueprint
- Secondary Research
The Situation
The work started in 2021, during a period when BP was modernizing its digital tooling across well operations. The Risk Toolkit was part of a larger program called the Well Delivery Workbench, built to bring all the digital tools for well operations into one coherent system. Four tools, four different user groups, four different phases of the same safety lifecycle.
Rig Verification is the most field-intensive of the four. Risk Assessment happens at a desk. The Risk Register accumulates data over time. Rig Verification puts people on helicopters and sends them to platforms in the middle of the ocean, working offline, coordinating with crews they've never met, under pressure to resolve issues before drilling starts.
BP doesn't own the rigs. They lease them from contracted operators. That means every handoff, approval, and sign-off in the verification process crosses an organizational boundary. The people doing this work knew their process. They'd been doing it for years. What nobody had, verifiers or the teams around them, was a way to see the whole thing at a glance. Salesforce was the backbone of the application. It held the data but didn't show the shape of the work. That's what the blueprint gave them.
Next Steps
Given more time the engagement would have continued with:
- Interviews with active Rig Verifiers and Well Delivery Team members to pressure-test the blueprint against real field experience
- Blueprints for the remaining three Risk Toolkit tools, each following the same structure
- A stakeholder map showing the full relationship network: BP, contracted operators, regional teams, regulatory bodies
- Opportunity mapping to identify the handoffs with the most friction
- A research cadence feeding findings back into the RV application itself