Operational control board
A Streamlit and Snowflake operational control board with near real-time refresh, built through iterative consultation with designers, analysts, and engineers, and adopted for operations alignment.
Outcome In production, providing a shared operational view across three groups.
- Streamlit
- Snowflake
- Data Apps
- Stakeholder Delivery
- Streamlit
- Snowflake
- Python
- Operational dashboarding
Context
An aviation client’s operations teams needed a shared operational view during an office and location migration. Without a central picture of ground and flight issues, delays, and crew or ground operations, different teams were working from different views of the same situation.
My role and ownership
I built the control board and owned the delivery, but the real work was collaborative: I iterated through three design cycles with the client’s designers, analysts, and engineers so the board reflected how operations teams actually worked rather than how I assumed they did.
Technical approach
- Built a centralised operational control board in Streamlit on Snowflake, with data refreshing roughly every five minutes to give teams a near real-time shared view.
- Designed the layout around operational priorities (issues, delays, crew and ground operations) surfaced from Snowflake.
- Ran three design iterations with designers, analysts, and engineers, tightening the board against real operational workflows each cycle.
Tradeoffs
The main tradeoffs were about refresh cadence and scope. More frequent refresh feels more “live” but costs more and adds little for decisions made on a multi-minute cadence, so a roughly five-minute refresh matched how the teams actually used it. On scope, I resisted adding every possible metric and kept the board focused on the operational signals teams aligned around, so it stayed a control board rather than a dashboard dumping ground.
Outcome
The board is in production, giving three operational groups a shared view of issues, delays, crews and ground operations, with data refreshing approximately every five minutes.
Reflection
This one reinforced that adoption is a design problem as much as an engineering one. The three iteration cycles mattered more than any single technical choice, because the board only became useful once it matched the team’s real workflow. If I extended it, I would add lightweight usage signals so the most-watched panels could be promoted and the unused ones retired.