Sriram P R

1 · Problem and why it mattered

Enterprise industrial-software conversations stalled at slideware; customers needed to see a capability working in their own scenario before committing to it.

2 · Users and operating context

Customer stakeholders evaluating a solution; internal sales, product and solution-architecture teams presenting it.

Enterprise industrial-software conversations often stall at slideware: buyers are asked to imagine how a capability would fit their operation. The source describes a body of work producing proof-of-value prototypes and demo experiences for these discussions, created with product, sales and solution-architecture teams.

3 · Evidence available at the start

The source summary slide describes the practice: cross-functional discovery, interactive prototype design, demo delivery and a stated count of 50+ prototypes. Individual prototypes, customers and outcomes are not included in the supplied material.

4 · Constraints, dependencies and confidentiality

Demos are customer-specific and confidential, so none is shown. Per the source, each had to be aligned, timely and customer-ready for a sales or solution conversation.

5 · My role and its boundaries

I contributed to 50+ proof-of-value prototypes and demo experiences, designing prototypes and concept flows and coordinating with product, sales and solution-architecture teams through concept, iteration and delivery. These were demonstrations for evaluation, not production releases.

The source credits me with designing the prototypes and concept flows and coordinating teams through concept, iteration and delivery. This is project and craft leadership; it does not establish line management of those teams. Separately, I have mentored two team members from a beginner level to working independently; that is mentoring, not direct-report management.

6 · Options and trade-offs

The chosen options are documented in the source. The alternatives are the counter-options each decision rules out; the source does not record which alternatives were actually prototyped or tested.

7 · Key decisions and why

• Scenario-driven flows instead of exhaustive feature tours, so a demo tells one coherent story.
• Clickable prototypes rather than static mock-ups, so stakeholders can evaluate interaction, not just appearance.
• Iteration with sales and solution teams before delivery, so the narrative matches what is technically feasible.

Each prototype was structured as a scenario: a customer goal, the workflow that serves it, and the screens a user would move through. The sequence below describes the delivery pattern documented in the source.

8 · Screen evidence

Full size

9 · Collaboration

Partnered with sales, product and solution-architecture teams to uncover customer needs, define use cases and shape demo narratives.

10 · Validation and review

Stakeholder review is part of the documented delivery pattern. The number of reviews, participants and the feedback received are not documented.

11 · Result

Commercial outcomes are not documented and are not claimed. The documented output is the body of work itself: 50+ proof-of-value prototypes and demo experiences that demonstrated product capabilities, communicated complex workflows and helped stakeholders evaluate proposed experiences. The exact period and per-project count are not yet established.

12 · Reflection and next step

The strongest improvement would be one anonymised prototype with its scenario, the decision it informed and what changed after review.

Context

Pipeline networks combine many interdependent elements (valves, pumps, junction nodes, connections) whose states, flow, pressure and maintenance information matter together. Seeing one element in isolation rarely explains what is happening.

Design challenge

Let users move through a large, interconnected infrastructure without losing their place, while keeping status and operational context visible at the right level of detail.

Users & operational context

Operators and stakeholders responsible for monitoring and understanding the network. Detailed role definitions are not documented.

My role & scope

I designed the pipeline network experience architecture: the navigation paths, interaction flows and a multi-layered map.

UX objectives & principles

• Reduce the cognitive effort of navigating a complex network (stated design objective).
• Keep spatial relationships and flow paths understandable.
• Surface status and maintenance information in context rather than in separate screens.

Information architecture & interaction approach

The map was organised in layers: a network overview, a subsystem focus, and contextual overlays for flow, pressure and maintenance insight. Navigation paths were structured so users could move between these levels deliberately.

Key interface decisions

• Layered views so the overview stays readable and detail appears only when a user focuses on a subsystem.
• Status-aware mapping so equipment state is visible on the map itself.
• Context-aware navigation that keeps the user's position in the network clear while drilling down.

Visual evidence

Full size

Cross-functional considerations

Worked with customers and cross-functional teams to align the map design with operational needs, usability goals and implementation priorities.

Intended value

Intended to improve spatial understanding, operational visibility and task flow across the network. Usability-test results and navigation-speed measurements are not documented.

Next steps

Next step: add an anonymised map screen and a before/after of the navigation structure.

Context

Industrial HMIs sit between an operator and equipment that can be expensive or unsafe to get wrong. Screens accumulate controls and readings over time, and operators work under time pressure.

Design challenge

Structure screens, alerts and workflows so operators can read equipment state quickly, find the right control, and complete critical tasks with confidence.

Users & operational context

Plant-floor operators. Shift patterns, environment and device specifics are not documented.

My role & scope

I designed touch interactions and control patterns, applied human-centred principles to the structure of screens, alerts and workflows, and worked with product, engineering and business teams to validate concepts and deliver HMI solutions.

UX objectives & principles

• Reduce cognitive load (design objective; outcome not measured in the supplied material).
• Make control visibility and system feedback unambiguous.
• Support safer interactions through clear hierarchy and deliberate confirmation.

Information architecture & interaction approach

The diagram alongside describes the hierarchy this case study applies: information that must be visible immediately, contextual detail needed during investigation, and actions that require deliberate confirmation.

Key interface decisions

• Context-aware controls: show the controls relevant to the current machine state instead of every control at once.
• Usability-led screen architecture so navigation, visibility and task flow follow operator priorities.
• Meaningful system feedback after every action, so the operator knows the machine responded.

Visual evidence

Full size

Cross-functional considerations

Concepts were validated with product, engineering and business teams before delivery.

Intended value

Clearer, more confident operation of complex machines. Safety certification and measured cognitive-load reduction are not documented and are not claimed.

Next steps

Next step: add an anonymised HMI screen annotated with the three information tiers.

Context

A digital twin is only useful if the person looking at it can tell what the asset is doing and whether anything needs attention. Raw telemetry rarely answers that on its own.

Design challenge

Connect the equipment representation, its KPIs, status indicators and trends so that an operator can move from 'what is this asset doing?' to 'what should I do?' without hunting across screens.

Users & operational context

Operators and maintenance teams.

My role & scope

I designed HMI screens surfacing live equipment status, performance trends and anomaly signals, and structured the screen flows, alerts and system views.

UX objectives & principles

• Make asset health and anomalies visible at a glance.
• Reduce cognitive load and support faster task execution (design objectives).
• Keep the digital representation tied to plant-floor decision workflows.

Information architecture & interaction approach

Context-aware screen architecture: the asset representation anchors the view; KPIs and status sit closest to it; trends and supporting detail follow. The pump-monitoring screen in B4 is a representative example of this structure.

Key interface decisions

• Equipment visualisation as the primary navigation anchor rather than a list of tags.
• Status and anomaly signals placed on or beside the asset they describe.
• Trends separated from current values so 'now' and 'over time' are not confused.

Visual evidence

Full size

Cross-functional considerations

Collaborated with engineering, product and domain teams to align interfaces with plant-floor needs and decision workflows.

Intended value

Intended to help teams understand asset health, performance and anomalies with greater speed and confidence. Screens in this portfolio are representative; deployment status is not documented.

Context

Industrial software needs equipment imagery that is consistent across product screens, training material and sales storytelling. Ad-hoc renders drift in scale, angle and style.

Design challenge

Represent complex equipment clearly at different levels of technical detail, while keeping proportions, orientation and style consistent enough to reuse.

Users & operational context

Operators, trainees, product teams and customer audiences viewing equipment in HMIs and presentations.

My role & scope

I designed platform-style industrial asset visualizations: a steam turbine, a gas turbine and a process flow diagram (PFD) asset.

UX objectives & principles

• Choose the level of realism that suits the job, rather than defaulting to maximum detail.
• Keep consistent proportions and orientation so assets can be swapped and compared.
• Support technical communication and digital-twin storytelling.

Information architecture & interaction approach

The three assets form a fidelity scale. A realistic render explains what a machine is; a semi-transparent technical view explains how it works inside; a simplified PFD explains how it fits into a process and where instruments sit.

Key interface decisions

• Steam turbine: high-fidelity render for product and training contexts where recognisability matters.
• Gas turbine: semi-transparent technical view for digital-twin and simulation storytelling, exposing internal stages.
• PFD: simplified flow representation with instrument tags for system-level communication inside interfaces.

Visual evidence

Full size

Full size

Cross-functional considerations

Not documented for this project. Related asset standards are described in the design systems section.

Intended value

A reusable vocabulary of equipment visuals. These are visualization and UX assets, not evidence of engineering-model accuracy.

Context

Operators monitoring a pump need its temperatures, pressures, speed and vibration in one place, alongside enough history to tell whether a reading is normal.

Design challenge

Combine a dense set of sensor parameters with trends and alerts without overwhelming the screen or hiding the asset itself.

Users & operational context

Control-room operators (the screen identifies an 'Operator, Control Room' user).

My role & scope

I developed screens that integrate sensor data and real-time feedback so operators can visualise equipment performance, detect anomalies and act proactively.

UX objectives & principles

• Real-time visibility of critical parameters.
• Early identification of deviations.
• Proactive alerts before issues escalate.
• Support for performance optimisation.

Information architecture & interaction approach

Tabbed asset navigation (overview, realtime data, trends, alarms, maintenance, history) keeps one pump's information in one place. The overview tab places a labelled equipment illustration at the centre, summary gauges to the right, an operating-parameters list with status bars beneath, and time-ranged trend charts at the bottom.

Key interface decisions

• Callouts attached to the equipment image so each reading is tied to its physical location.
• Operating parameters shown as value plus status bar, with timestamps, so currency of data is visible.
• Trend charts with consistent time-range controls (1H to 1W, plus live) for speed and vibration-versus-speed.

Cross-functional considerations

Not documented for this project.

Intended value

A single, coherent view of one asset's condition. Displayed values are illustrative, not operating data.

1 · Problem and why it mattered

Plant data from roasting, grinding, blending, packaging and quality checks was needed by different people at different depths; one dense screen would serve none of them well.

2 · Users and operating context

Production and operations teams. Specific roles are not documented.

A coffee plant generates data from roasting, grinding, blending and packaging, plus batch and quality checks. Different people need it at different depths: a production review, a process overview and a live operations view.

3 · Evidence available at the start

The source documents the plant stages, the KPIs and data types shown, and the three intended views. No user research, interviews or usage analytics are documented in the supplied source.

4 · Constraints, dependencies and confidentiality

Screens are adapted for confidentiality and use representative values. Data sources, integration constraints and the delivery platform are not documented in the supplied source.

5 · My role and its boundaries

I designed the dashboard and operational monitoring experiences for the plant.

The source credits me with the dashboard and monitoring experience design. Ownership of requirements, data integration and implementation is not documented.

6 · Options and trade-offs

The chosen options are documented in the source. The alternatives are the counter-options each decision rules out; the source does not record which alternatives were actually prototyped or tested.

7 · Key decisions and why

• KPIs grouped at the top with comparison to the previous day, so change is visible without reading charts.
• Current status (line status, equipment health, quality alerts) kept separate from historical trends.
• Control limits drawn on the moisture chart so quality deviations read against target, not as raw numbers.
• A dark operational view for continuous monitoring, distinct from the light review dashboard.

The three concepts map to levels of investigation. The production dashboard answers 'how did we do?'; the concept exploration organises the process stages spatially; the operational dashboard answers 'what is happening now, and is anything wrong?'

8 · Screen evidence

Full size

Full size

9 · Collaboration

Not documented for this project.

10 · Validation and review

Not documented in the supplied source.

11 · Result

No measured outcome is documented. Intended outcome: faster production review and earlier visibility of line or quality issues. A measurement plan would compare the time to answer common review questions, and the time from a quality deviation to its acknowledgement, before and after rollout.

12 · Reflection and next step

Evidence is the gap in this case. The next step is to add any review feedback that exists and to show one end-to-end path from a KPI change in the review view to the live view that explains it.

1 · Problem and why it mattered

Alarm systems produce more events than people can read as a list; operators needed to move from a summary, to the context of one event, to the right action.

2 · Users and operating context

Operations teams and alarm handlers.

Alarm systems produce high volumes of events. Without structure, operators see a list; they need categories, priorities, acknowledgement state and the order in which things happened.

3 · Evidence available at the start

The source documents the three views and their intent. No alarm-rate data, operator research or feedback is documented in the supplied source.

4 · Constraints, dependencies and confidentiality

Screens are adapted for confidentiality and use illustrative values. Integration with the alarm system, the alarm philosophy and the approval process are not documented.

5 · My role and its boundaries

I designed the dashboard and operational monitoring experiences, focusing on alarm categorisation, anomaly sequence timelines, priority management, acknowledgement tracking and real-time observability.

The source credits me with the dashboard and monitoring experience design for these three views. The related swim-lane timeline (C3) is presented in the source as a generic representation; my scope on that screen awaits confirmation.

6 · Options and trade-offs

The chosen options are documented in the source. The alternatives are the counter-options each decision rules out; the source does not record which alternatives were actually prototyped or tested.

7 · Key decisions and why

• Category and priority breakdowns placed beside trends, so 'how many' and 'which kind' are read together.
• A 'top nuisance alarms' view to make alarm-flood sources visible.
• A severity-by-hour heatmap in the operations view for spotting time-of-day patterns.
• Acknowledgement latency and status shown explicitly rather than implied.

Three linked views: a categorisation dashboard for review; an anomaly sequence concept that traces an incident through clustered and correlated events to a root-cause hint and severity score; and an operations centre for live alarm queue, heatmaps and zone health.

8 · Screen evidence

Full size

Full size

9 · Collaboration

Not documented for this project.

10 · Validation and review

Not documented in the supplied source.

11 · Result

No measured outcome is documented; response time, acknowledgement rate and other values on the screens are illustrative. A measurement plan would track alarms per operator per hour, the share of nuisance alarms, and acknowledgement latency, before and after.

12 · Reflection and next step

The anomaly sequence concept shows a 'high confidence' root-cause hint. A production version needs a validated basis for any confidence wording, or should present the hint as a suggestion with its evidence, as the reconstructed D3 screen does.

Context

When an anomaly in one system triggers others, an alarm list hides the chain. Operators need to see order, timing and which system each event came from.

Design challenge

Show a chronological view across several systems that stays readable, lets users filter to what matters, and gives detail for one event without losing the overall sequence.

Users & operational context

Operators monitoring an alarm system.

My role & scope

I structured event and signal information for investigation, established time context, event relationships and the information hierarchy, and designed the interaction and visualisation patterns that take a user from a detected anomaly to detailed investigation. The underlying detection model was not my work.

UX objectives & principles

• Visualise event sequences across systems to understand cause and effect.
• Filter by time, severity, system or asset.
• Severity-based categorisation with impact indicators.
• Support faster root-cause analysis (design objective).

Information architecture & interaction approach

Summary KPIs sit above the application. Inside, a left navigation separates timeline, alarm list, analysis and shelved alarms. The timeline uses one lane per system with connectors between related events; below it, selected-event details and a numbered event sequence give the focused view.

Key interface decisions

• One lane per system, so the source of each event is never ambiguous.
• Connectors between events to show propagation, not just co-occurrence.
• Timeline and list views offered side by side for different working styles.
• 'Show normal events' toggle so context can be added without cluttering the default.

Cross-functional considerations

Not documented for this project.

Intended value

Makes event propagation readable on a single time axis. No measured MTTR improvement is documented.

Context

Data platforms and services produce a steady flow of status changes. Teams need to recognise what matters quickly and see patterns over time.

Design challenge

Make alert states instantly recognisable, give each monitored stream a scannable status, and summarise incident volume, categories and response time.

Users & operational context

Operations and data teams monitoring streams and services. The monitors shown (data quality, API error rate, stream latency) indicate an IT and data-operations context.

My role & scope

I designed dashboard and operational monitoring interfaces focused on alert visibility, issue prioritisation, observability and data-driven decision support.

UX objectives & principles

• Fast issue recognition through clear alert states.
• Severity-based prioritisation and grouping.
• Trend-based analysis of incidents and response time.

Information architecture & interaction approach

A proposed reading of the structure: Detect (alert visibility system) → Understand context (monitor list with source, incidents and recent activity) → Prioritise (status and severity) → Investigate (trends and categories) → Act. This is an explanatory structure based on the screens, not a validated production workflow.

1. 1Detect
2. 2Understand context
3. 3Prioritise
4. 4Investigate
5. 5Act

Key interface decisions

• Four alert states (info, completed, warning, critical) each with its own icon, colour and label.
• Inline sparklines in the monitor list so recent behaviour is visible without opening a monitor.
• Response time shown as average, median and 90th percentile rather than a single number.

Visual evidence

Full size

Full size

Cross-functional considerations

Not documented for this project.

Intended value

A transferable pattern for B2B SaaS and data-platform observability as well as industrial operations. Values are illustrative.

Context

During an incident, the order of events is often the most useful information. A timestamped, filterable sequence lets teams reconstruct cause and recovery.

Design challenge

Present a chronological stream that is easy to scan, correlate and filter, and that opens into detail without leaving the sequence.

Users & operational context

Operations and incident-response teams. The example events (server, web tier, auto-scaling) are from an IT operations context.

My role & scope

I designed sequence timeline experiences that help teams monitor events, alerts and triggers in chronological order.

UX objectives & principles

• Make event progression easy to understand.
• Correlate related alerts across systems.
• Severity-based prioritisation.
• Faster root-cause analysis (intended design objective).

Information architecture & interaction approach

Filters for time range, asset/system and severity sit above a vertical event timeline. Selecting an event opens a detail panel with time, system, severity, category, description and tags. An adjacent operational summary shows active alerts, events over time, category split and response time against goal.

Key interface decisions

• A connected vertical timeline with severity markers, so sequence and severity are read together.
• Severity always shown as a labelled pill, not colour alone.
• Detail panel beside the list, so context is gained without losing position.
• Response time shown against an explicit goal.

Visual evidence

Full size

Cross-functional considerations

Not documented for this project.

Intended value

Clear reconstruction of incidents. Reductions in investigation time are not measured or claimed.

Context

Operations data is spread across monitoring, production and maintenance systems. Decision-makers need a single overview that still shows where to look next.

Design challenge

Present a large volume of operational data through KPI cards, trends and comparisons, and make clear which parts describe the present, which explain a problem and which anticipate risk.

Users & operational context

Operations and maintenance decision-makers.

My role & scope

I designed dashboard and operational monitoring experiences that turn live system data into actionable insights for predictive maintenance, condition monitoring and operational analysis.

UX objectives & principles

• Identify failure risk early from trend and condition data.
• Track health, sensor signals and performance in real time.
• Turn live metrics into data-driven actions.

Information architecture & interaction approach

Descriptive: KPI cards (asset health, active alerts, uptime, response time, energy, maintenance risk), asset status and production output. Diagnostic: downtime by cause and alarms by severity. Predictive: an impact-versus-likelihood matrix and assets ranked by risk score. Actionable: maintenance work orders by status.

Key interface decisions

• Every KPI paired with a comparison to the previous period.
• An impact/likelihood quadrant to prioritise risk, with a tooltip showing the underlying scores.
• 'View details' entry points on each panel instead of cramming detail into the overview.
• Work orders shown by status (completed, in progress, scheduled, overdue) to link insight to action.

Cross-functional considerations

Not documented for this project.

Intended value

One overview that makes the distinction between monitoring, diagnosis and prediction visible. Values are illustrative.

Context

Operators must detect, prioritise and respond to critical issues in real time. Inconsistent severity cues across screens slow that down.

Design challenge

Define a severity hierarchy that is unambiguous, apply it consistently across lists, charts and notifications, and support acknowledgement and escalation.

Users & operational context

Operators in an industrial monitoring system.

My role & scope

I designed alert and notification interfaces that help operators detect, prioritise and respond to critical issues.

UX objectives & principles

• Consistent severity semantics everywhere an alarm appears.
• Fast prioritisation through categorisation.
• Timely, multi-channel notification with acknowledgement and escalation.

Information architecture & interaction approach

Severity summary cards lead, followed by an active-alarm table filterable by severity tab, then distribution, trend and top-source charts. Notifications, escalations and timeline are separate destinations in the navigation.

• CriticalSystem down or unsafe condition. Immediate action required.
• HighMajor issue affecting operations. Prompt attention needed.
• MediumNoticeable issue or performance impact. Monitor and investigate.
• Low / InfoInformational update or minor change. No immediate action.

Key interface decisions

• Each level pairs a colour with a distinct icon, a text label and a plain-language meaning.
• Severity tabs on the alarm list show counts, so users know what a filter will return.
• Top alarm sources ranked to point at the equipment generating the most noise.

Visual evidence

Full size

Cross-functional considerations

Not documented for this project.

Intended value

A shared severity language for alarms. Multi-channel delivery (UI, email, SMS, mobile push) is shown as a design capability; implementation is not documented.

Context

Alarm review spans the current state (what is active now) and history (how alarm load has changed and where it comes from).

Design challenge

Make critical alarms easy to identify and act on, while giving enough history to spot recurring sources and time-of-day patterns.

Users & operational context

Industrial operations teams.

My role & scope

I designed clear, high-visibility alarm interfaces for industrial operations.

UX objectives & principles

• Easy identification and prioritisation of critical alarms.
• Visibility of alarm sources by area.
• Historical patterns across days and hours.

Information architecture & interaction approach

Headline metrics (total active, critical, high priority, acknowledgement rate) with sparklines lead into stacked daily alarms, severity split, alarms by area, alarm rate and a time-of-day heatmap. The recent active alarms table closes the page with severity, area, acknowledgement status and duration.

Key interface decisions

• Acknowledgement status in the table pairs a coloured dot with a text label.
• Alarm duration shown per row, so long-standing alarms stand out.
• A compact operational overview variant for smaller panels.

Visual evidence

Full size

Cross-functional considerations

Not documented for this project.

Intended value

A clear relationship between alarm summary and alarm detail. Values are illustrative.

Context

Default alert rules rarely fit every team. If configuration is opaque, people either live with noise or switch alerts off.

Design challenge

Make alert settings understandable and adjustable, with visible feedback on how alert volume and severity change.

Users & operational context

Operators and teams managing alerts. The example alerts (endpoint malware, failed logins, vulnerability scans) indicate an IT security context.

My role & scope

I designed alert configuration experiences that help operators tailor severity, notification frequency and escalation rules.

UX objectives & principles

• Understandable settings with explicit control.
• Visible feedback on alert volume and distribution.
• Safe configuration that does not hide critical alerts.

Information architecture & interaction approach

Filters (time range, area, severity) and an auto-refresh toggle sit above summary cards, alert volume over time and severity split. Recent alerts list status, category, priority, area, time and who acknowledged. Rule creation is a single, clearly labelled primary action.

Key interface decisions

• Severity filters as labelled chips with colour dots, plus an 'All' option.
• 'Acknowledged by' column for accountability.
• 90-day trend and top-category views alongside the live dashboard to inform rule changes.

Cross-functional considerations

Not documented for this project.

Intended value

Configuration that stays connected to its consequences. Specific rule capabilities beyond those shown are not documented.

Context

An alarm that may or may not have been handled is a risk in itself. Teams working across shifts need a clear record.

Design challenge

Make acknowledgement quick enough for real operations, while capturing enough context for accountability and handover.

Users & operational context

Operators and teams working across shifts.

My role & scope

I enabled operators to acknowledge active alarms with mandatory comments, actions taken and user identification.

UX objectives & principles

• Clear accountability for every acknowledgement.
• Faster acknowledgement and resolution (intended outcome).
• Context for teams across shifts.

Information architecture & interaction approach

The active alarm list filters by acknowledgement state. Selecting an alarm opens a side panel with severity, time, message, current value and threshold, followed by required fields (acknowledged by, comments, actions taken) and an optional attachment. A history timeline below records each state change.

Key interface decisions

• Required fields marked explicitly, so the operator knows what is needed before submitting.
• Current value shown next to threshold, so the reason for the alarm is visible in the form.
• Cancel and Acknowledge as clearly separated actions.
• Acknowledgement history as a timeline, linking comments and actions to each step.

Cross-functional considerations

Not documented for this project.

Intended value

Reduces ambiguity about whether and how an alarm was handled. Regulatory compliance is not established and is not claimed.

Context

Recurring issues often share causes that are only visible across time, systems and past cases.

Design challenge

Help operators identify underlying causes by looking at temporal patterns, deviations and related events, and connect findings to actions.

Users & operational context

Operators and reliability teams.

My role & scope

I designed the information hierarchy, the visible investigation workflow, the presentation of top causes, occurrence trends and insights, and the recent-case view. Analytics and implementation were outside my scope.

UX objectives & principles

• Event correlation and causal analysis.
• Timeline reconstruction and impact assessment.
• Action recommendations to prevent recurrence.

Information architecture & interaction approach

The workflow is shown explicitly as a sequence, so the dashboard always communicates where in an investigation the user is.

1. 1Detect issue
2. 2Collect data
3. 3Correlate events
4. 4Identify root cause
5. 5Recommend actions
6. 6Monitor & validate

Key interface decisions

• The investigation workflow is visible on the page, not hidden in a process document.
• Top root causes and their occurrence over time shown together.
• Plain-language insights summarise patterns (for example, by shift).
• Recent RCA cases list root cause, impact and resolution status.

Cross-functional considerations

Not documented for this project.

Intended value

A visible investigation workflow that connects analysis to action.

Context

Root-cause investigations involve many possible contributing factors. Teams need a structure for exploring them and a record of how the cause was reached.

Design challenge

Make a cause-and-effect investigation interactive and traceable: show candidate causes by category and impact, explain why one was selected, and connect it to actions and related incidents.

Users & operational context

Operations and reliability teams investigating incidents.

My role & scope

I designed the information hierarchy and interaction patterns for root-cause exploration: the cause map, the presentation of diagnostic evidence behind a selected cause, and the recommended-action and related-incident views. The analysis behind the suggestions was outside my scope.

UX objectives & principles

• Visualise an issue and its possible contributing factors.
• Trace problems back across components, processes and systems.
• Make the reasoning behind a selected cause explicit.

Information architecture & interaction approach

A cause map (fishbone structure) organises candidate causes into Materials, Processes, People, Methods, Environment and Machines, each marked by impact level. The left panel records investigation progression from alert to resolution. Beneath the map: the selected root cause, why it was selected with supporting evidence, recommended actions and related incidents.

Key interface decisions

• Six standard cause categories so investigations are comparable.
• Impact level marked on each candidate cause, with a legend.
• A 'why is this the root cause?' panel that lists supporting evidence.
• Investigation flow with timestamps and a workflow status, so the record is complete.

Visual evidence

Full size

Cross-functional considerations

Not documented for this project.

Intended value

A diagnostic investigation aid. The confidence score shown is illustrative; the source does not establish that AI independently determined the root cause.

Context

AI-assisted diagnosis is only useful if people can see what was observed, what the system is suggesting, and what remains for them to decide.

Design challenge

Integrate automated diagnostic assistance into the investigation flow without letting a suggestion read as a confirmed root cause.

Users & operational context

Operations and engineering teams investigating an alarm. Specific roles are not documented in the source.

My role & scope

The source states I integrated AI algorithms into the design to automate parts of the diagnostic process. This is read as interface and workflow design for AI-assisted analysis; building, training or validating models is not claimed. The screen below is a portfolio reconstruction, not the original deliverable.

UX objectives & principles

• Support the investigation process with automated assistance.
• Make complex diagnostic information easier to navigate.
• Show confidence and status alongside every AI finding.

Information architecture & interaction approach

The reconstructed screen reads top to bottom as an investigation: the event summary; correlated signals on one time axis; the evidence list (observed signals, derived correlation, maintenance record); candidate hypotheses marked as proposed; a human-review stepper with confirm, reject and request-more-data actions; and next steps that require approval.

Key interface decisions

• Evidence and interpretation are shown in separate panels, so an observation is never mistaken for a conclusion.
• No confidence or likelihood score is displayed, because none has been validated; the assistant's suggestion is labelled as a suggestion.
• A visible human-review step with an explicit reject path back to evidence review.
• Proposed actions are gated on confirmation rather than offered as instructions.

Cross-functional considerations

Not documented for this project.

Intended value

Intended to make AI suggestions reviewable and to keep the decision with a qualified person. No accuracy, confidence or time saving is claimed.

Next steps

If an anonymised original diagnostics screen can be shared, add it beside the reconstruction and label each clearly.

Context

Investigations fail when people don't know the next step, lose context while exploring related data, or cannot tell a system suggestion from a decision.

Design challenge

Design an easy-to-follow path that keeps users oriented and surfaces relevant information at the right time.

Users & operational context

Operators and engineers investigating an alert. The source describes guiding users from the detection of a problem to its root cause.

My role & scope

I designed an easy-to-follow flow that guides users from the detection of a problem to its root cause.

UX objectives & principles

• Clear pathways where every step leads closer to resolution.
• Minimal cognitive load through grouping and progressive disclosure (design objective).
• User control: explore related areas without losing context.
• Faster decisions (intended goal).

Information architecture & interaction approach

Seven stages grouped under the source's four phases (Detect, Explore, Diagnose, Resolve): signal detected, signals correlated, affected asset inspected, evidence and hypotheses reviewed, a qualified person decides, action and hand-off recorded, outcome captured. Each stage is marked as system assistance, a human step, or system-proposes-person-reviews, and names the case studies that show it. Rejecting a hypothesis loops back to evidence review.

1. 1Detect
2. 2Explore
3. 3Diagnose
4. 4Resolve

Key interface decisions

• Human steps and decision points carry a heavier outline than system-assistance steps, so responsibility is visible without colour.
• A single explicit loop (reject → evidence review) instead of an open-ended return path.
• Each stage links to the case studies that show it, so the flow ties the alarm, timeline and RCA work together.

Cross-functional considerations

Not documented for this project.

Intended value

A designed concept that connects the alarm, timeline and RCA case studies into one journey. No validation evidence is documented.

Context

Preventive maintenance depends on spotting degradation early. On an embedded HMI, space is limited and the screen must be readable at a glance.

Design challenge

Fit overall health, monitored assets, critical alerts and maintenance due into a compact, dark HMI while keeping a clear order of attention.

Users & operational context

Operators and maintenance teams using embedded HMIs.

My role & scope

I designed embedded monitoring interfaces that help operators track equipment condition, detect early risk signals and prioritise maintenance actions.

UX objectives & principles

• Real-time visibility of asset condition.
• Early risk detection through thresholds.
• Maintenance effort focused on what matters most.

Information architecture & interaction approach

Four summary tiles (overall health, assets monitored, critical alerts, maintenance due) sit above a health trend and health distribution. Below, assets ranked by health score and recent alerts with severity close the loop to action.

Key interface decisions

• Each summary tile pairs a number with a status word (Good, Action required, This week).
• Health bands defined explicitly in the legend (good, fair, poor) with their score ranges.
• Assets ranked by health score with a trend sparkline, so declining assets stand out.

Cross-functional considerations

Not documented for this project.

Intended value

Supports proactive maintenance decisions. Uptime and readiness figures shown in the source are illustrative.

Context

When many similar machines run side by side, maintenance teams need to see at a glance which ones deviate.

Design challenge

Show several readings per machine across a fleet, and make it obvious which machines need attention and why.

Users & operational context

Maintenance teams.

My role & scope

I designed embedded HMI screens that offer real-time status monitoring of critical equipment for maintenance planning.

UX objectives & principles

• Real-time monitoring of critical parameters.
• Proactive alerts with thresholds.
• Clear maintenance prioritisation.

Information architecture & interaction approach

Each machine card uses the same layout: name, alert badge, and four readings (pressure, vibration, temperature, gas flow). Out-of-range readings are highlighted within the card. Grid and list views and group filters support different fleet sizes; a dark plant overview summarises the whole site.

Key interface decisions

• Identical card structure so differences read as data, not layout.
• Card border and badge reflect machine state; the badge also states the alert count in text.
• The specific deviating reading is highlighted, so the reason for the state is visible.

Visual evidence

Full size

Cross-functional considerations

Not documented for this project.

Intended value

Fast fleet comparison. The meaning of individual readings beyond those legible is not documented.

Context

Maintenance management is a classic enterprise workflow: many records, statuses and priorities, with a need to act on them quickly.

Design challenge

Give maintenance teams an overview of what is due and a list they can filter, sort and act on.

Users & operational context

Maintenance teams and leads.

My role & scope

I created interactive designs for maintenance teams to monitor equipment health and schedule maintenance proactively.

UX objectives & principles

• Work-order and equipment-due visibility.
• Clear status and priority.
• Efficient actions from the list.

Information architecture & interaction approach

Summary cards (equipment due, low inventory, work orders, purchase orders, maintenance cost) lead into a maintenance list with due date, status, priority, cost and row actions, plus filter, reset and pagination. An overview variant adds maintenance trend and category breakdown.

Key interface decisions

• Status pills and priority dots both carry text labels.
• Filter and reset placed together above the table.
• Row selection for bulk actions; a single 'Add new' primary action.

Visual evidence

Full size

Cross-functional considerations

Not documented for this project.

Intended value

Reusable enterprise table and status patterns that transfer directly to other B2B work-management products.

Context

Camera feeds can reveal conditions sensors miss, but a wall of video is not a monitoring tool. The feed must be connected to status, alerts and equipment.

Design challenge

Show live visual monitoring alongside alert summaries, equipment status and anomaly trends, so a detection can be understood and acted on.

Users & operational context

Maintenance leads and operators.

My role & scope

I designed HMI interfaces for real-time equipment monitoring using camera-based artificial vision. The vision models themselves were not my work.

UX objectives & principles

• Real-time visual monitoring.
• Anomaly detection and actionable insight.
• Support for predictive maintenance and safety monitoring (intended use contexts).

Information architecture & interaction approach

Summary cards (monitored equipment, active alerts, anomalies, uptime, inspections) lead to a grid of labelled camera feeds, each with a status tag. Recent alerts and an anomaly trend sit alongside. A use-case strip frames where the capability applies.

Key interface decisions

• Every camera feed labelled with the asset name and a text status (Normal, Anomaly).
• Detection regions drawn on the feed, with the anomalous feed highlighted.
• Recent alerts beside the feeds, so the alert and the image can be compared.

Cross-functional considerations

Not documented for this project.

Intended value

Makes visual detections part of the monitoring workflow. No specific vision model, accuracy level or production deployment is claimed.

Context

Artificial-vision monitoring produces a stream of detections. They are only useful if operators can see which cameras are healthy, which events need review, and the evidence behind each one.

Design challenge

Present camera status, detections and evidence so an operator can confirm or dismiss each event quickly, without treating a model output as a confirmed fault.

Users & operational context

Operators visually monitoring machinery (per the source). Other roles are not documented.

My role & scope

I designed interfaces that display real-time images and videos of equipment, powered by artificial vision, so operators can visually monitor machinery. The screen below is a portfolio reconstruction of that experience, not the original deliverable.

UX objectives & principles

• Continuous visual monitoring.
• Anomaly visibility.
• Operational context for faster response.

Information architecture & interaction approach

Status metrics lead (cameras online, degraded and offline; events awaiting review). A camera grid shows each feed with a text and icon status. The event table lists time, camera or asset, event, severity and review status (detected, under review, confirmed, dismissed). The selected-event panel shows the evidence frame with the detection region, the event details and the confirm or dismiss decision.

Key interface decisions

• Camera health (online, degraded, offline) shown with text and icon, so a missing feed is never mistaken for 'no events'.
• Four review states keep model detections separate from confirmed faults; dismissals record a reason.
• The selected event states plainly that it is a model detection, not a confirmed fault.
• Camera tiles reuse the label-plus-status pattern from E4, keeping the vision cases consistent.

Cross-functional considerations

Not documented for this project.

Intended value

Intended to make visual detections quick and safe to review. No detection accuracy, uptime or response-time result is claimed.

Context

Detection results are only actionable if users can see where the issue is, what kind it is, how certain the system is and what to do next.

Design challenge

Present machine-generated observations so they are understandable and actionable, and do not read as confirmed facts.

Users & operational context

Maintenance leads.

My role & scope

I designed how AI-based object-recognition results, such as wear or malfunctioning parts, are surfaced in the HMI screen. The recognition model itself was not my work.

UX objectives & principles

• Real-time issue visibility on the HMI.
• Clear detection categories and locations.
• Actionable next steps from a detection.

Information architecture & interaction approach

A 3D or camera view anchors the screen, with a detection overlay and callout (machine, part, issue, confidence, view details). Left: detections over time, by type and by confidence band. Right: defects by category, detections by zone and alerts by severity. Environmental gauges sit beneath the model, and a 'how it works' strip explains the pipeline from capture to preventive action.

1. 1Image capture
2. 2AI analysis
3. 3Issue identification
4. 4Alert & notification
5. 5Preventive action

Key interface decisions

• Detection callout names the machine, part and issue in words, not just a box on an image.
• Detections grouped by confidence band, so uncertain results are visible as a category.
• 3D and camera views as explicit toggles.

Cross-functional considerations

Not documented for this project.

Intended value

Makes AI detections legible. Confidence values and accuracy claims shown are illustrative; no model performance is claimed.

Next steps

Opportunity: distinguish detection, uncertain result and operator-confirmed issue as separate visual states.

Context

A maintenance alert is only trusted if users can see what triggered it. Dynamic thresholds make this harder, because the limit moves.

Design challenge

Show the triggering condition, the measurement, the time context, severity and the next available action in one view.

Users & operational context

Operators and maintenance teams.

My role & scope

I designed the alert experience for AI-triggered maintenance alerts based on visual data analysis, so operators are notified when maintenance is required. The detection logic itself was not my work.

UX objectives & principles

• Explain each alert through its triggering condition.
• Make dynamic thresholds understandable.
• Connect alerts to maintenance windows and rules.

Information architecture & interaction approach

A metric chart shows the actual value, predicted range and allowed range, with alert-fired, active and resolved periods shaded and annotated. Hovering shows the upper and lower limits at that point. Beneath, active alert rules list metric, condition, threshold, duration, severity, status and trigger time.

Key interface decisions

• Annotated chart states ('fired', 'active', 'resolved') so the alert lifecycle is visible on the data.
• Hover detail shows the dynamic limits at a point in time.
• Rules table makes each threshold and duration explicit.

Cross-functional considerations

Not documented for this project.

Intended value

Alerts that explain themselves. Dynamic-threshold learning is described as a capability; implementation is not documented.