top of page
Lion Blau

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

iPhone 14 Pro.png

18

Live data sources

70+

Monitored accounts

3m 13s

Avg. visit duration

53.8%

Mobile usage

Early usage signals

Group 16.png

Tactical map — turned feeds into spatial awareness

Group 152445.png

AI briefing — compressed dozens of inputs into a readable daily brief

Israel Monitor  Real-Time OSINT dashboard 8.png

Live TV — added live broadcast context without leaving the product

Israel Monitor  Real-Time OSINT dashboard 9.png

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.

Group 169999.webp

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.

Screenshot 2026-03-22 at 14.52.27.png

Early prototype

Screenshot 2026-04-08 at 03.38.32.png

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.

Pink Poppy Flowers
Group 17089UIG.png

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.

Screenshot 2026-04-22 at 13.44.14.webp

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.

Screenshot 2026-03-22 at 14.40.00.png

Push distribution — Structured updates delivered through Telegram for fast, lightweight monitoring.​

IMG_3524.PNG

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.

Screenshot 2026-04-24 at 18.32.01.png

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.

bottom of page