Sekal
Sekal
Sekal
Tackling a dashboard to optimize drilling operations and reduce risk in the Norwegian oil & gas sector.
Tackling a dashboard to optimize drilling operations
and reduce risk in the Norwegian oil & gas sector.
Tackling a dashboard to optimize drilling operations and reduce risk in the Norwegian oil & gas sector.
Role
Role
Product Designer
Product Designer
Project Industry
Project Industry
Oil and Gas Drilling Technology
Oil and Gas Drilling Technology
Platform
Platform
Desktop Application
Desktop Application
Timeframe
Timeframe
June 2023 to June 2024
June 2023 to June 2024
Working Team
Working Team
Cross-Functional Team
Cross-Functional Team
Tools
Tools
Visit Website
TL;DR
TL;DR
•
•
Served as the main Product Designer on an international, cross-functional team, working fully remotely with stakeholders in Bergen, Norway.
Served as the main Product Designer on an international, cross-functional team, working fully remotely with stakeholders in Bergen, Norway.
•
•
Owned end-to-end design for the Time-Based Graph Viewer over ~3 months, iterating back-and-forth until the track-and-trace experience stabilized for real-time interpretation.
Owned end-to-end design for the Time-Based Graph Viewer over ~3 months, iterating back-and-forth until the track-and-trace experience stabilized for real-time interpretation.
•
•
Helped regain stakeholder trust through clear design articulation, including proactive clarifying questions, careful note-taking, and written alignment with the PO before execution.
Helped regain stakeholder trust through clear design articulation, including proactive clarifying questions, careful note-taking, and written alignment with the PO before execution.
•
•
Built a scalable component foundation for DrillScene, then later contributed design tokens for Sekal’s unified product work that had not launched yet.
Built a scalable component foundation for DrillScene, then later contributed design tokens for Sekal’s unified product work that had not launched yet.
Context and Constraints
Context and Constraints
Sekal is the market leader in real-time drilling engineering. DrillScene supports real-time monitoring by combining live well data with sophisticated modeling to surface minor deviations early.
Sekal is the market leader in real-time drilling engineering. DrillScene supports real-time monitoring by combining live well data with sophisticated modeling to surface minor deviations early.
When my design manager and I took over, the project carried meaningful constraints:
When my design manager and I took over, the project carried meaningful constraints:
Trust-Recovery Context
Trust-Recovery Context
Stakeholder confidence was low after prior inconsistencies and a fragile UI foundation.
Stakeholder confidence was low after prior inconsistencies and a fragile UI foundation.
Complex, Precedent-Light Domain
Complex, Precedent-Light Domain
The work had limited design references, and the subject matter was highly technical.
The work had limited design references, and the subject matter was highly technical.
Remote-First Delivery
Remote-First Delivery
I worked fully remotely with stakeholders in Bergen, Norway, which increased miscommunication risk across time zones.
I worked fully remotely with stakeholders in Bergen, Norway, which increased miscommunication risk across time zones.
Data-Dense UI
Data-Dense UI
Small hierarchy or interaction flaws could slow down decision-making.
Small hierarchy or interaction flaws could slow down decision-making.
Limited Analytics Maturity
Limited Analytics Maturity
The product did not keep consistent usage analytics, which reduced opportunities for data-driven UX validation.
The product did not keep consistent usage analytics, which reduced opportunities for data-driven UX validation.
Vendor-Style Collaboration Boundaries
Vendor-Style Collaboration Boundaries
Influence depended on clarity, alignment, and trust rather than formal authority.
Influence depended on clarity, alignment, and trust rather than formal authority.
Users and Use Cases
Users and Use Cases
DrillScene is primarily used by drilling engineers and real-time operations teams who monitor live well data to detect early deviations, assess risk, and decide the next operational action.
DrillScene is primarily used by drilling engineers and real-time operations teams who monitor live well data to detect early deviations, assess risk, and decide the next operational action.
In practice, the dashboard supports 3 common jobs:
In practice, the dashboard supports 3 common jobs:
•
•
maintaining situational awareness across multiple signals
maintaining situational awareness across multiple signals
•
•
identifying abnormal trends before they escalate
identifying abnormal trends before they escalate
•
•
sharing context through annotations so teams can align quickly during time-sensitive drilling operations.
sharing context through annotations so teams can align quickly during time-sensitive drilling operations.
Ultimately, the dashboard is not just for viewing charts. It is for making confident decisions under uncertainty.
Ultimately, the dashboard is not just for viewing charts. It is for making confident decisions under uncertainty.
My Role and Team Setup
My Role and Team Setup
I worked as a Product Designer in a distributed delivery model spanning Norway and Thailand.
I worked as a Product Designer in a distributed delivery model spanning Norway and Thailand.
•
•
Design Team: 5 designers across the Norway-based team and the Bangkok-based team.
Design Team: 5 designers across the Norway-based team and the Bangkok-based team.
•
•
Delivery Partners: PO coverage from Norway, plus a Bangkok-based cross-functional team (PO, QA, and full-stack developers).
Delivery Partners: PO coverage from Norway, plus a Bangkok-based cross-functional team (PO, QA, and full-stack developers).
•
•
My Scope: end-to-end UX and UI for the Time-Based Graph Viewer and its supporting patterns, plus foundational component improvements to enable scalability.
My Scope: end-to-end UX and UI for the Time-Based Graph Viewer and its supporting patterns, plus foundational component improvements to enable scalability.
Although I was not the formal design lead, I owned key feature decisions and partnered closely with product and engineering to keep delivery predictable in a remote, English-only environment.
Although I was not the formal design lead, I owned key feature decisions and partnered closely with product and engineering to keep delivery predictable in a remote, English-only environment.
Design Process Overview
Design Process Overview
I followed a Double-Diamond approach, then delivered through weekly backlog refinement with the cross-functional team. Throughout the work, I treated product as the intersection of Desirable, Feasible, and Viable decisions by validating user needs for real-time interpretation, checking technical feasibility early with engineers, and staying aligned with the PO on priorities and delivery reality.
I followed a Double-Diamond approach, then delivered through weekly backlog refinement with the cross-functional team. Throughout the work, I treated product as the intersection of Desirable, Feasible, and Viable decisions by validating user needs for real-time interpretation, checking technical feasibility early with engineers, and staying aligned with the PO on priorities and delivery reality.
Product Framing and Success Criteria
Product Framing and Success Criteria
Early on, I reframed the work around a single product question:
Early on, I reframed the work around a single product question:
How might we help drilling engineers interpret time-series signals quickly, confidently, and consistently during real-time monitoring?
How might we help drilling engineers interpret time-series signals quickly, confidently, and consistently during real-time monitoring?
From there, I aligned on success criteria that balanced product value and delivery reality:
From there, I aligned on success criteria that balanced product value and delivery reality:
Fast Orientation
Fast Orientation
Users understand what each track shows without guessing.
Users understand what each track shows without guessing.
Relevant Default Time Context
Relevant Default Time Context
The dashboard opens with a useful time window for operational awareness.
The dashboard opens with a useful time window for operational awareness.
Progressive Control
Progressive Control
Users filter time, manage templates, and toggle details without losing focus.
Users filter time, manage templates, and toggle details without losing focus.
Scalable, Predictable System
Scalable, Predictable System
Components and interactions stay consistent across tracks, traces, and states, so the viewer can grow without redesigning from scratch.
Components and interactions stay consistent across tracks, traces, and states, so the viewer can grow without redesigning from scratch.
Domain Model and Dashboard Anatomy
Domain Model and Dashboard Anatomy
The team already used industry-standard terminology, so I kept the language consistent across design artifacts and handoff notes. To make the viewer easier to interpret and implement, I treated the dashboard as a track-and-trace system driven by Settings.
The team already used industry-standard terminology, so I kept the language consistent across design artifacts and handoff notes. To make the viewer easier to interpret and implement, I treated the dashboard as a track-and-trace system driven by Settings.
In the UI, each trace appears as a time-series graph of its signal. That graph follows the configuration defined in Settings, such as unit, scale behavior, range, and visual style. As a result, configuration changes translate directly into what users see on the dashboard.
In the UI, each trace appears as a time-series graph of its signal. That graph follows the configuration defined in Settings, such as unit, scale behavior, range, and visual style. As a result, configuration changes translate directly into what users see on the dashboard.
A Concrete Example: Track, Trace, and Signal Configuration
A Concrete Example: Track, Trace, and Signal Configuration
To ensure the viewer scaled across drilling scenarios, I designed the dashboard around consistent track-and-trace rules. For example, the Bit & Weight track grouped 3 traces that engineers could read together:
To ensure the viewer scaled across drilling scenarios, I designed the dashboard around consistent track-and-trace rules. For example, the Bit & Weight track grouped 3 traces that engineers could read together:
•
•
ROP (m/h), solid-line trace with auto-scale enabled
ROP (m/h), solid-line trace with auto-scale enabled
•
•
Bit Depth (MD) (m), solid-line trace with a fixed 0 to 1,000 m range
Bit Depth (MD) (m), solid-line trace with a fixed 0 to 1,000 m range
•
•
HK Height (m), dashed-line trace with auto-scale enabled
HK Height (m), dashed-line trace with auto-scale enabled
This structure made the dashboard easier to interpret because users could rely on stable rules for how traces behave, how they are differentiated, and how settings translate into the on-screen graph.
This structure made the dashboard easier to interpret because users could rely on stable rules for how traces behave, how they are differentiated, and how settings translate into the on-screen graph.
Design Discovery
Design Discovery
Because the domain had few external design precedents, I relied on structured conversations and iterative artifacts to replace missing references. I focused on:
Because the domain had few external design precedents, I relied on structured conversations and iterative artifacts to replace missing references. I focused on:
•
•
Who uses DrillScene day-to-day, what decisions they make, and what “good” monitoring looks like
Who uses DrillScene day-to-day, what decisions they make, and what “good” monitoring looks like
•
•
Where interpretation breaks down, such as ambiguous labels, overloaded legends, or unclear time scope
Where interpretation breaks down, such as ambiguous labels, overloaded legends, or unclear time scope
•
•
Which operational edge cases matter, including missing data, partial data, and annotation density
Which operational edge cases matter, including missing data, partial data, and annotation density
I turned ambiguity into clear user stories and acceptance criteria, then refined them weekly with the cross-functional team.
I turned ambiguity into clear user stories and acceptance criteria, then refined them weekly with the cross-functional team.
Core Experience: Time-Based Graph Viewer
Core Experience: Time-Based Graph Viewer
1. Track Header Clarity
Users needed to understand what each track represented at a glance. I designed the track header to:
Users needed to understand what each track represented at a glance. I designed the track header to:
•
•
Communicate track purpose through clear hierarchy
Communicate track purpose through clear hierarchy
•
•
Reveal more traces under the header when needed
Reveal more traces under the header when needed
•
•
Apply consistent structure across tracks to support scanning and comparison
Apply consistent structure across tracks to support scanning and comparison
This improved the readability layer of the dashboard, which was essential for trust-building in a data-heavy environment.
This improved the readability layer of the dashboard, which was essential for trust-building in a data-heavy environment.
2. Time Filters with a Useful Default
Time context is the backbone of interpretation, so I treated it as a primary control:
Time context is the backbone of interpretation, so I treated it as a primary control:
Operational Default (On Load)
Operational Default (On Load)
Last 24 Hours applied on load for an immediately relevant operational view.
Last 24 Hours applied on load for an immediately relevant operational view.
Focused Monitoring Mode
Focused Monitoring Mode
Last 12 Hours or Last 6 Hours for tighter monitoring of recent activity and faster trend checks.
Last 12 Hours or Last 6 Hours for tighter monitoring of recent activity and faster trend checks.
I kept the initial filter set intentionally small so it matched real workflows and remained straightforward to implement and iterate.
I kept the initial filter set intentionally small so it matched real workflows and remained straightforward to implement and iterate.
3. Trace Legend Visibility for Focus
In data-heavy dashboards, the legend is essential but visually noisy. I introduced a quick Hide-Show Trace Legend control so users could reduce clutter during pattern-reading and restore details instantly when validating a trace.
In data-heavy dashboards, the legend is essential but visually noisy. I introduced a quick Hide-Show Trace Legend control so users could reduce clutter during pattern-reading and restore details instantly when validating a trace.
4. Templates for Repeatable Analysis Setups
4. Templates for Repeatable Analysis Setups
Engineers often need repeatable layouts for specific analysis scenarios. In DrillScene, templates came in 2 types: pre-defined templates with limited edits, and custom templates that users could create or modify to match their workflows. I designed:
Engineers often need repeatable layouts for specific analysis scenarios. In DrillScene, templates came in 2 types: pre-defined templates with limited edits, and custom templates that users could create or modify to match their workflows. I designed:
Select Dashboard Template
Select Dashboard Template
To switch quickly between pre-defined layouts based on the task.
To switch quickly between pre-defined layouts based on the task.
Add New Custom Template
Add New Custom Template
To create or save a configurable layout tailored to specific user requirements.
To create or save a configurable layout tailored to specific user requirements.
This shifted the dashboard from a fixed view to a configurable system that adapts to different operational contexts.
This shifted the dashboard from a fixed view to a configurable system that adapts to different operational contexts.
5. Annotations that Support Shared Understanding
5. Annotations that Support Shared Understanding
Annotations preserve context on top of time-series data. I supported:
Annotations preserve context on top of time-series data. I supported:
User-Generated Annotations
User-Generated Annotations
Add, view, edit, and delete annotations to share context, explain unexpected patterns, and support faster team alignment.
Add, view, edit, and delete annotations to share context, explain unexpected patterns, and support faster team alignment.
System-Generated Annotations
System-Generated Annotations
System annotations highlight operational signals and remain non-removable, while user-generated annotations are removable to keep the workspace accurate and current.
System annotations highlight operational signals and remain non-removable, while user-generated annotations are removable to keep the workspace accurate and current.
That distinction reinforced accountability and reduced confusion in collaborative review.
That distinction reinforced accountability and reduced confusion in collaborative review.
6. Empty States for No-Data and First-Time Setup
6. Empty States for No-Data and First-Time Setup
In real-time monitoring, “no data” is expected. I designed explicit empty states for both the dashboard and settings to show what the layout looks like when data is unavailable, while guiding users through first-time template setup.
In real-time monitoring, “no data” is expected. I designed explicit empty states for both the dashboard and settings to show what the layout looks like when data is unavailable, while guiding users through first-time template setup.
When creating a new template, the cursor automatically focuses on the required template name field, and the empty state prompts users to add at least 1 track and 1 trace so the dashboard has a meaningful starting point.
When creating a new template, the cursor automatically focuses on the required template name field, and the empty state prompts users to add at least 1 track and 1 trace so the dashboard has a meaningful starting point.
Design System Foundation
Design System Foundation
At the time I worked on this feature, the project did not yet have design tokens. Still, I treated the component layer as token-ready by building scalability into the system upfront.
At the time I worked on this feature, the project did not yet have design tokens. Still, I treated the component layer as token-ready by building scalability into the system upfront.
I focused on:
I focused on:
Variant-Ready Components
Variant-Ready Components
Predictable states, scalable patterns, and reusable structures.
Predictable states, scalable patterns, and reusable structures.
Consistency Rules
Consistency Rules
Spacing logic, typography hierarchy, and interaction consistency across controls.
Spacing logic, typography hierarchy, and interaction consistency across controls.
System Organization
System Organization
Clear naming conventions, component grouping, and usage guidance to reduce team friction.
Clear naming conventions, component grouping, and usage guidance to reduce team friction.
This foundation reduced UI drift and made new tracks, traces, and settings behaviors easier to implement without rethinking core patterns.
This foundation reduced UI drift and made new tracks, traces, and settings behaviors easier to implement without rethinking core patterns.
Stakeholder Management and Cross-Functional Delivery
Stakeholder Management and Cross-Functional Delivery
Because the project started in a trust-recovery state, alignment was as important as the UI.
Because the project started in a trust-recovery state, alignment was as important as the UI.
Design Articulation in a Remote-First, Global Team
Design Articulation in a Remote-First, Global Team
Working with a Bergen-based stakeholder team in an English-only, remote-first setup made clarity non-negotiable. Rather than assuming shared understanding, I treated design articulation as a repeatable system:
Working with a Bergen-based stakeholder team in an English-only, remote-first setup made clarity non-negotiable. Rather than assuming shared understanding, I treated design articulation as a repeatable system:
•
•
I captured requirements, constraints, and open questions during discussions, then reflected them back in plain language.
I captured requirements, constraints, and open questions during discussions, then reflected them back in plain language.
•
•
I asked clarifying questions early, especially when a request could be interpreted in multiple ways.
I asked clarifying questions early, especially when a request could be interpreted in multiple ways.
•
•
I translated subjective feedback into decision criteria, including interpretation speed, operational risk, consistency rules, and implementation feasibility.
I translated subjective feedback into decision criteria, including interpretation speed, operational risk, consistency rules, and implementation feasibility.
•
•
I summarized what we agreed on and what needed follow-up so the team had a shared reference after meetings.
I summarized what we agreed on and what needed follow-up so the team had a shared reference after meetings.
This approach helped prevent misalignment, reduced rework, and helped stakeholders feel confident in the direction again.
This approach helped prevent misalignment, reduced rework, and helped stakeholders feel confident in the direction again.
Weekly Refinement and Iterative Delivery
Weekly Refinement and Iterative Delivery
The team ran weekly backlog refinement and iterative delivery. I used that cadence to slice scope into shippable increments, resolve feasibility concerns early with developers, and keep UI decisions consistent across screens and states.
The team ran weekly backlog refinement and iterative delivery. I used that cadence to slice scope into shippable increments, resolve feasibility concerns early with developers, and keep UI decisions consistent across screens and states.
Outcomes and Impact
Outcomes and Impact
I did not track a single quantitative metric for this feature release, but the impact was clear in collaboration and product quality:
I did not track a single quantitative metric for this feature release, but the impact was clear in collaboration and product quality:
•
•
Stakeholders regained confidence as the dashboard became easier to interpret and discuss using consistent track-and-trace rules.
Stakeholders regained confidence as the dashboard became easier to interpret and discuss using consistent track-and-trace rules.
•
•
Developers received a more reliable component foundation, which reduced ambiguity during implementation.
Developers received a more reliable component foundation, which reduced ambiguity during implementation.
•
•
The team reduced rework by confirming requirements early and iterating in smaller, validated increments.
The team reduced rework by confirming requirements early and iterating in smaller, validated increments.
•
•
The Time-Based Graph Viewer became a scalable base for continued feature growth within DrillScene.
The Time-Based Graph Viewer became a scalable base for continued feature growth within DrillScene.
What I Learned
What I Learned
Self-Explanatory UI Improves Clarity
Self-Explanatory UI Improves Clarity
When the interface explains itself through consistent hierarchy, labeling, and behavior, users spend less time interpreting the UI and more time interpreting the data.
When the interface explains itself through consistent hierarchy, labeling, and behavior, users spend less time interpreting the UI and more time interpreting the data.
Design Articulation Protects Quality
Design Articulation Protects Quality
In international, remote-first work, clarifying questions, structured notes, and written summaries prevent misalignment.
In international, remote-first work, clarifying questions, structured notes, and written summaries prevent misalignment.
Consistency Rebuilds Trust
Consistency Rebuilds Trust
Stable patterns, explicit rules, and steady cadence restore stakeholder confidence over time.
Stable patterns, explicit rules, and steady cadence restore stakeholder confidence over time.
A Strong Component Foundation Scales
A Strong Component Foundation Scales
Even before tokens exist, consistent variants, states, and naming make complex systems easier to extend.
Even before tokens exist, consistent variants, states, and naming make complex systems easier to extend.
What’s Next?
What’s Next?
What’s Next?
