Designing a data visualisation tool to give the Army Reserve community full visibility of their allocated, planned, actual, and forecast reserve days — for the first time in the organisation's history.
🔒 Actual screens are withheld due to the sensitive nature of this project.Army Reserve units are allocated a fixed number of reserve days at the start of each financial year. These days are paid for — so tracking how they're planned, used, and forecast is a critical financial and operational concern.
The problem: there was no single tool that showed this. Planning happened in spreadsheets. Actuals came in through a separate system. Forecasting was manual guesswork. No one — from the admin managing the budget to the Commanding Officer overseeing multiple units — had a clear picture of where they stood.
The complexity was significant. Reserve days are split across multiple categories — each drawing from a different budget pot. Units at different levels of the hierarchy needed different views. And the data had to flow correctly from planning through to actuals before the visualisation could mean anything.
The challenge wasn't just the data — it was that different users needed to see the same data in completely different ways, at different levels of detail.
Higher-level organisations also needed to see their subordinate units rolled up — so a Brigade commander could see all units under their command without being overwhelmed by the detail. The cognitive load challenge was significant.
This was one of the most complex requirement-gathering phases I've experienced. The domain was highly specialised — reserve pay categories, budget pots, hierarchical unit structures, and the relationship between planning and actuals all needed to be fully understood before any design work could begin.
Initial requirements workshops produced more questions than answers. The process took multiple iterations of discovery sessions, validation workshops, and prototype reviews before the full picture emerged. Each round revealed a new layer of complexity — a new user type, a new edge case, a new data relationship.
The data flow had to be mapped end-to-end before any UI decisions could be made. The admin sets allocations → units plan against those allocations → reserves are mobilised and assigned to the correct pots → actuals flow back in from the operational system → the dashboard updates to show the full picture.
End-to-end data flow — from allocation setting through to actuals and forecast
Illustrative only — actual screens withheld due to sensitive nature of the project
Illustrative diagram — Allocated, Planned, Actual and Forecast states per unit
The final solution consisted of three connected components working as a unified system.
Before this tool existed, no one in the reserve community had a complete view of how their allocated days were being used. The tool changed that entirely.