I'm Ofek, a Product Designer with 7 years of experience designing mission-critical systems for the Israeli Air Force: command & control, mission planning and real-time monitoring. I work side by side with product managers and engineers from discovery to delivery, and my CS background helps the designs actually ship.
Complex, data-dense tools for people who can't afford to miss anything. Product names and data are altered for confidentiality.
Operators were tracking every aircraft by eye for 12-hour shifts. I designed a system that lets them build their own alerts and automated actions, then switch them on and off live during a shift.
Read the case studyShort description of the second case study goes here.
Short description of the third case study goes here.
For seven years I designed the systems Israeli Air Force operators rely on around the clock. That work taught me to sit through a night shift before drawing a single screen, and to measure a design by fewer errors under pressure, not by how it looks in a review.
I hold a B.Sc. in Computer Science and write HTML, CSS and JavaScript, so engineers and I speak the same language. I'm now looking to bring that rigor to a product team building meaningful, user-centered products.
Away from the screen: drums, scuba diving, woodworking, running and chess.
Consultant · Israeli Air Force
Israeli Air Force
Flare is a system for managing alerts and automated actions. It is one of seven operational systems that work in sync to protect Israel's airspace, and one of the systems I planned and designed in my role.
Starlight is a real-time system for protecting the airspace. It is staffed 24/7 and built around a map, where each entity represents an aircraft and carries its details.
Part of the operator's job is to spot anomalies and suspicious behavior in the airspace in real time. That takes full concentration across 12-hour shifts.
To help operators cope with the system's cognitive load, the team decided to try alerts. The basic alerts, mostly hard-coded, helped a little, but they needed frequent changes and every change took up valuable development time.
That is where the idea came from: a subsystem that lets operators create their own custom alerts.
Through user research, meetings and silent observation during shifts, I found that a lot of time and effort went into tracking every aircraft to catch deviations and events. That load made it hard for the shift to focus on actually handling those events.
Operators were spending their attention on finding the events, and had too little left for handling them.
From there I mapped four needs:
Detect anomalies and unusual behavior in the airspace automatically and alert the operator. For example, alert when an Airbus A380 is in the sky.
Once behavior is flagged, the operator has to perform the same set of steps while juggling many other tasks. I saw a chance to automate those steps and take load off the shift.
Which alerts matter depends on the current threat picture and operational status, so alerts need to be adjustable per shift.
Operators run their shifts differently. Some want to mute every alert, others want to set alerts themselves. Alerts had to adapt to each person.
The ideas started with an alert management screen and a way to switch off existing alerts. They grew into a full system for managing alerts and automated actions, which operators can turn on and off in real time. I sketched it in four parts.
Creating an alert starts with defining the anomaly the operator wants to find. I planned a search-based system: the operator enters the unusual conditions, and the system finds matching events regardless of the order of the conditions.
Concept: the ideal search-based query, where conditions can come in any order.
After defining the alert, the operator sets the actions that follow when the anomaly is detected. I mapped every possible action and let operators pick any number of follow-ups, with no limits or dependencies between them: highlight the aircraft, show its flight history, report it.
The operator sets the alert's active hours, for example for flights that are only suspicious at night. The creator also assigns groups and tags, so the alert is easy to classify and find later.
The alerts a shift needs change with the threat picture and operational status. I wanted a screen where the operator picks which rules run during that shift and which alerts are relevant to them.
The development team received the specs but ran into a problem: they couldn't build the central entity-search screen within the project's timeline.
Later, one of the developers suggested an open-source library that could solve it, but with limits on how the system would work. It supported filtering, not search. The conditions would depend on each other and on the order they appear in.
That meant adapting the solution and rethinking the design.
I kept the library's node-based model and redesigned what it shows and how operators work with it.
The original nodes were circles with random colors and letters. I changed them to an oval shape that shows what the node contains from the outside, with a matching icon and one fixed color for each node type.
Double-clicking a filter node opens a window for choosing limiting conditions and the relation between them (OR / AND). Step through how an operator builds a condition:
Double-clicking an information node, such as an alert or an action, opens a window for its details: a title, a description, a priority level, and the automated actions that run when the alert is clicked.
To add a node, the operator clicks the arrow next to the node it should come from and picks the type of node to create.
Building a rule happens in two stages: first the nodes, then the extra details about the rule.
The details: who created the rule, relevant tags, the group it belongs to, and its schedule.
Scheduling lets a rule run only during certain hours or days. That makes alerts more precise and cuts down false alarms.
Flare is connected to the operational system, and rules run through it. So I added a side panel inside Starlight where operators turn rules on and off without leaving the map.
