From PDF chaos to digital clarity—making risk data work for engineers
Turning complex, hard-to-search risk data into an intuitive digital platform, giving engineers & operators quick access to critical information for enhanced safety on site.
Before
After
Confidential
4 months
Oil & Gas
Product Owner
3 in-house developers
Workflow Designer
Jr Service Designer
Process Safety Eng
Scrum Master
System Architect
Change Manager
Value Engineer
“I want to know what has occurred, what it could lead to, & what my cumulative risk is”
- Plant Maintainer
A digital platform that cleansed & digitised LOPA data, transforming it into an easily searchable & interpretable format.
This platform empowers users to access & understand critical risk information quickly, reducing reliance on manual search methods and enhancing overall site safety.
A Layers of Protection Analysis (LOPA) is a comprehensive study that assesses potential risks across a facility & identifies the barriers, or ‘layers of protection,’ in place to prevent those risks from materialising. LOPA is a global standard in hazardous industries.
These resource-intensive studies are performed every five years & can take months to complete.
Research objective
LOPA data is valuable for a large range of processes & decisions. So, the research plan focused on trying to identify the different use cases for LOPA data & understand the pain points for each user group.
17
Use case assessments
21
Interviews
3
Workshops
Use Case Mapping
When exploring who uses LOPA data and why, we discovered there were over 17 different internal processes that required it.
It wasn't realistic for us to thoroughly deep dive into each of these processes, so we developed a light touch approach using the template to the right.
High-level process map, a value formula with estimations, key notes/ pain points, key stakeholders and links to any resources we found.
This allowed us to prioritise which were the most valuable use cases and ultimately influence our development priorities.
Current State Data Journey
Since we didn’t have the time to map out 17 different user journeys in detail, we instead mapped out a ‘data journey’ which followed the lifecycle of LOPA data. We dove into how people capture, utilise & maintain LOPA data.
Use case mapping template
Current State Data Journey Map
What we found…
Capturing LOPA data was labour intensive. Time pressure & limited resources lead to a conservative approach & inaccurate data.
Engineers & Operators would spend at least 30min searching 100s of pages in multiple PDF reports & risk missing important information due to variation in terminology & misspelt words.
Updating the LOPA involved manually marking up, scanning, emailing & approving—often leading to people not updating it at all.
Design
Future State User Journey
This Future State Map created by our junior service designer with my guidance.
For stakeholder management purposes, we created a simplified version of the future state map (below).
It clearly outlined the high-level process & key change areas.
Simplified future state
Low-Mid Fidelity
Initial user testing involved low-fi sketches & card sorting to validate user mental models to inform application workflows & information hierarchy.
I had built strong relationships with my users, so often I would send them a Mural link with a bunch of screen shots and get them to add feedback. This allow for an asynchronous working style, which suited my users that were time poor.
"This is world leading in the industry as far as I know"
- Ops Manager
Mid-fi UI review and card-sorting activity, results of card sorting
High Fidelity
High-fidelity designs were created for the MVP features (not all MVP features were finalised)
Restricted by data structure (which was sometimes poor) - like longggg headings
SO. MUCH. Data.
"I want to see everything" - every engineer ever
What does 'value' mean?
As we were preparing to begin development, the company had a pivot. They were cracking down on cost per barrel, which saw a drastic shift in what they defined as a valuable initiative. Since this product was heavily focused on risk management rather than reducing cost, our funding was not renewed.
"If someone were to ask me... 'what is the most valuable tool we could have for engineering right now?'...I would say this!"
- Frontline Process Engineer
Some reflections…
The process worked—although it is not ideal for a product to be cancelled, at least it got cancelled early. We completed the discovery phase, put together a value case & unfortunately it didn't stack up—but thats better than continuing to funnel resources into it only to be defunded later.
Maybe it should have been pitched differently—in hindsight, we should have pitched the app’s strategic potential rather than just focusing on OPEX reduction, highlighting how it could enable better maintenance strategies across 17 other processes.
The Value Framework needed work—The value framework wasn’t consistently followed, leading to decisions based on gut feel rather than strategy, leaving POs feeling disempowered and often surprised by outcomes.
