Lion Blau
Conflict intelligence product
Israel Monitor is a public monitoring product for interpreting fast-moving conflict. It brings sirens, briefings, live broadcasts, and event signals into a single interface, evolving from a feed-driven dashboard into a broader system with a tactical map and editorial workflow — used during live escalation to track events as they unfolded in real time.
Feb–Apr 2026 · Role: Product design, front-end, data architecture, automation
Role: Product design, front-end, data architecture, automation
Feb–Apr 2026
18
Live data sources
70+
Monitored accounts
3m 13s
Avg. visit duration
53.8%
Mobile usage
Early usage signals
Tactical map — turned feeds into spatial awareness
AI briefing — compressed dozens of inputs into a readable daily brief
Live TV — added live broadcast context without leaving the product
Naval activity — extended monitoring beyond headlines and sirens
PROBLEM
No single place to understand what was happening, right now
When the conflict escalated, the information problem was not scarcity but fragmentation. News lagged. Social feeds were immediate but noisy. Telegram was fast and often essential, but difficult to follow, especially across languages and source quality. What was missing was not just more information, but a better interface for urgency: one place that could combine alerts, context, and live signals without forcing people to assemble the picture themselves. Israel Monitor was built to make that picture legible.
system
More than a dashboard
Israel Monitor began as a live OSINT dashboard, but evolved into a broader monitoring system: a public intelligence surface designed to follow escalation as it happened.
The product brought together three layers. A live monitoring layer aggregating sirens, headlines, and social signals into a fast interface. A tactical map translating events into geography, trajectories, and movement. And an internal editorial workflow to review, structure, and publish signals with confidence.
Together, these layers turned fragmented inputs into a coherent, real-time view of the situation.
Early prototype
Operational redesign
The product evolved from a modular dashboard into a more focused operational interface.
How the build expanded my scope
The build quickly moved beyond interface work. Shipping Israel Monitor meant learning and implementing relay logic, cron jobs, feed parsing, automation, and live data orchestration — the operational parts required to make a real-time monitoring product usable and trustworthy.
EVOLUTION
From feeds to spatial awareness
As the product matured, the limitation of a feed-based interface became clear: it could show that something happened, but not where signals concentrated, how threats were moving, or how events related across the region.
I redesigned the experience around a tactical map layer. Alerts, trajectories, and event markers could now be interpreted in geographic context rather than as disconnected updates — shifting the product from passive monitoring to real situational awareness. A later replay-oriented “Time Machine” extended this further, turning the map into both a live interface and a historical record of escalation over time.
Regional view for movement across theaters
Local view for immediate operational clarity
Shift from linear event streams to spatial understanding — enabling users to see concentration, movement, and relationships between signals in real time.
trust
Designing the system behind the system
A real-time map is only as useful as the quality of the events behind it. As more sources were added — Telegram channels, alerts, extracted reports — the product needed more than a front-end. It needed operational control over what became visible, when, and with what level of confidence.
I designed an internal workflow for reviewing, structuring, and publishing events. This layer handled deduplication, location fixes, confidence scoring, and publication state — turning noisy, incoming data into a coherent public surface.
This wasn’t just a backend concern. It was essential to keeping the live experience fast, credible, and usable under pressure.
Internal event curation workflow used to review, structure, and publish incidents before they reached the live map.
Distribution
Designed for the surface people actually use
The system was not limited to a single interface. The same intelligence powered multiple surfaces: a dense desktop dashboard, Telegram updates, mobile alert views, and lightweight AI briefings.
Different contexts demanded different speeds. Some users needed a full operational view, others a quick check-in or a shareable summary. Designing the product meant designing how the same signals adapted across those moments without losing clarity or meaning.
Push distribution — Structured updates delivered through Telegram for fast, lightweight monitoring.
Shareable daily brief — A story-format summary designed for quick consumption and easy reposting.
Constraints
Designing under unstable inputs and live pressure
This was not a clean-data product. Sources changed, feeds broke, quality varied by language and channel, and the interface had to stay legible under real-time pressure.
Three constraints shaped the product most. First, data reliability: live signals were often incomplete, duplicated, or noisy. Second, trust: not every incoming event was ready for publication, which made editorial control essential. Third, speed: the product had to stay understandable during active escalation, not just in calm retrospective review.
Those constraints pushed the design toward clarity, hierarchy, and operational restraint. The product could not simply show more; it had to decide what was worth surfacing and how confidently.
Unstable signals
Live inputs were often incomplete, duplicated, or noisy.
Publication trust
Not every incoming event was ready for publication.
Real-time speed
The interface had to stay readable during live escalation.
Three forces shaped the product most: unstable inputs, trust in what gets published, and the need to stay readable under live pressure — leading to a design focused on clarity, hierarchy, and operational restraint.
Traffic over the first months after launch, showing sustained usage during live escalation.
1.5k visitors · 2.2k pageviews · 3m+ avg. s.time
OUTCOME
Shipped under live conditions
Israel Monitor launched publicly and was used during active escalation periods. In its first months, it drew repeat traffic, meaningful session time, and sustained usage — indicating that people were not just visiting, but relying on it to follow events as they unfolded.
Traffic came from multiple countries and skewed slightly mobile, reinforcing the need to design beyond a desktop dashboard and support faster, lighter consumption surfaces.
The system I designed held up under real conditions — supporting sustained usage during live escalation and enabling users to follow events as they unfolded, not just after the fact.
More importantly, the system held up under real conditions: live data, unstable inputs, and continuous iteration while events were still developing. It proved that complex monitoring systems only become usable when speed, clarity, and trust are designed together.