Reimagining a Fire & Life Safety Control System

RoleLead
ClientHoneywell / Notifier
AgencyOgilvy
Timeline13 weeks
TeamLead UX + PT design, research, and project support
Industrial UX Safety-Critical Systems Touchscreen Interaction Information Architecture

Original Hardware Control Panel

Legacy Notifier fire alarm control panel — physical keypad and indicator lights

Redesigned Touchscreen Interface

Redesigned Notifier touchscreen interface — Active Events screen with contextual controls

From hardware-constrained control panel to touchscreen-first life-safety platform.

Notifier's fire and life-safety control platform had accumulated decades of technical complexity without producing a current map of its own structure. Its architecture reflected hardware-era engineering logic, device hierarchies, and layered configuration rules — not how operators respond to events, locate devices, or navigate under pressure.

I led the UX redesign, reconstructing the system's underlying architecture and translating its engineering logic, device hierarchies, system states, and hardware-era navigation into an operator-facing product structure organized around events, points, status, and action. The work required interpreting a dense, fragmented legacy model and producing a shared structure that design, product, and engineering teams could build from.

A retrospective audit of project artifacts indicates that I consolidated approximately 128 unique functional nodes into 66 task-oriented destinations—a 48% reduction in information-architecture complexity—while preserving the platform's core operational and programming capabilities.

Original Hardware Interface – Key Components

Original hardware control panel with four numbered annotation markers indicating status LEDs, soft keys, fixed function keys, and special function keys

The panel required operators to navigate life-critical functions through a small LCD, fixed hardware controls, soft keys, and a programming keypad. New capabilities had been layered in over time without a clear organizing model.

  • Critical functions were buried in deep navigation paths
  • Operators relied on memorized sequences and changing soft-key behavior
  • The interface reflected implementation logic more than operator decision-making

Before: Multi-step alarm response

Alarm occurs
Abbreviated LCD message appears
Press "View" soft key
Scroll through events
Select an event
Navigate for details and actions
Return or switch context
Acknowledge

After: Single-screen alarm response

Redesigned Active Events screen — collapsed view with active alarms surfaced at the top and alarm state visible
Redesigned Active Events screen — event expanded inline showing device, location, status, and Acknowledge action together on one screen
Before After
~6–7 actions to acknowledge 1 in-context action
2+ context shifts 0 screen changes
1 event visible at a time Multiple events visible together
Repeated Next/Previous actions 1 direct selection

Action counts are approximate; exact paths varied by event position and whether detail was reviewed.

The redesign translated a fragmented hardware-era command sequence into a persistent response state where alarm priority, event context, and acknowledgement remained visible together.

The first design problem was interpretive: no current model of the system existed. Before interface design could begin, I reconstructed its features, menu paths, duplicate functions, and access hierarchies into a shared functional model that made the platform understandable across design, product, and engineering.

128 → 66 48% reduction in information-architecture complexity Retrospective analysis of project artifacts

Legacy architecture

Legacy Notifier information architecture spanning four dense diagrams — communicates scale, fragmentation, and depth of the original system structure

Redesigned architecture

Redesigned Notifier information architecture — clearer grouping by operator task domain, reduced depth, and consolidated navigation paths

The reduction reflects a translation from fragmented technical paths into recognizable product domains — not the removal of necessary capability.

Why the legacy structure was difficult to use

Buried individual tasks

Legacy IA detail showing history review task buried beneath multiple branches, filters, date-entry fields, and event-type selection

Common tasks were buried across multiple branches.

Sequential list navigation

Legacy IA detail showing Next and Previous navigation pattern requiring operators to step through related event information sequentially

Operators navigated events sequentially using Next/Previous.

The largest reductions came from separating routine work from specialist programming and consolidating settings, reporting, and duplicate paths. Event-response logic changed less because required safety-critical states were preserved.

Early concepts explored task-first entry points, but testing showed that operators oriented themselves around affected system points. They first identified the detector, module, zone, node, or location involved, then determined what action to take.

I translated that observed behavior into a point-centric interaction model in which the selected point, its status, and its available actions stayed together. The architecture clarified where capabilities belonged; the point-centric model clarified how operators accessed them, replacing sequential Next/Previous navigation with visible point lists and direct selection.

ObservedOperators oriented around affected points — detectors, modules, zones, nodes — rather than abstract task categories.

ChangedShifted from task-first entry points to a point-centric interaction model.

ResultPoint lists, point details, and available actions remained connected within one workflow, without losing orientation.

Point list presentation

Scrolling list of points within the selected Node, Loop, or Zone — a contextual set within a region of the system.

Point selection

Selecting a point surfaces its status, detail, and available functions in context.

Point-specific functions

Point detail expands inline with status, information, and relevant actions. Task is performed without leaving the list view.

Updated point status

Operator returns to the updated list. Context and orientation are preserved.

The point-centric model converted Next/Previous navigation into direct list selection — point, status, and action remaining together without context switching.

The translated architecture became a cohesive operational interface — one where system state, event priority, and point-level detail are organized by how operators work rather than how the hardware is built. Persistent navigation and status give operators continuous awareness. A prioritized event list surfaces what matters without requiring menu traversal. Each row carries enough context to orient the operator before they act.

Final Notifier touchscreen UI showing the Active Events list with prioritized fire alarm and trouble entries, persistent left-side navigation organized by event category, and point-level detail available per row
The final interface brought the translated architecture into a cohesive operational product — giving operators continuous system awareness, prioritized event visibility, and direct access to affected points.

For operators

Less system structure to learn, with event context and actions kept together throughout response workflows.

For the product

A retrospective audit of project artifacts indicates a 48% reduction in information-architecture complexity — 128 destinations consolidated into 66 — while preserving core operational and programming capability.

For the team

A shared language and architecture that design, product, and engineering could use to discuss, prioritize, and extend the platform.

The most valuable work happened before the screens. I reconstructed an undocumented safety-critical system, translated it into a measurable, test-informed product architecture, and carried that model through research into a point-centric interaction framework. The result preserved the depth of a life-safety system while making that complexity more usable for operators and more actionable for the teams building it.