Case study — service design
Circuit Command Centre
A control-room concept for running a Grand Prix weekend — not for running the race.
A self-directed prototype of a single operational picture for the people who keep a Grand Prix weekend working: marshals, medical, security, transport, accessibility, staffing and comms. It is deliberately not race telemetry and not race strategy — nothing in it belongs to a team.
I built it in Figma Make after applying to volunteer as a Race Maker at Silverstone, then went back afterwards to check whether the problem I had assumed was real. This page is that check.
The Live Map, captured from the running prototype at 1600 px. Every value on it is seeded, not fed — and the track outline underneath is a placeholder, not Silverstone. Both points are unpacked below.
Role
Concept, design and build — solo
Type
Self-directed exploration, not commissioned
Surface
Desktop control room · 12 modules
Status
Working prototype · seeded data only
02 — Where it came from
It started with a volunteer application
I applied to be a Race Maker at Silverstone. Reading through what the role actually involves — where you stand, who you report to, what you are supposed to do when something happens near you — I found myself thinking about the weekend as a service rather than as a race.
A Grand Prix is a small city that exists for four days. Somebody has to run its gates, its shuttles, its medical posts, its accessible seating and its radio channels. At Silverstone, over 1,500 of those people are volunteer Marshals and Race Makers, and most of them are told where to stand and then rely on a voice in an earpiece for everything else.
I wanted to see what a unified operational picture for that weekend might look like. So I built one.
I want to be exact about the order of events, because it changes how you should read the rest of this page. I did not run interviews. I did not shadow a shift. I did not do a competitive teardown. I had an idea from reading a volunteer application pack, I built a prototype in Figma Make, and only then did I go looking for evidence about whether the problems I had designed against were real. Section 04 is that search, done afterwards, and labelled as such throughout.
Order matters here more than it usually does. In a commissioned project the research is the brief. In this one the research is a stress test applied to something that already existed — which is a weaker position, and worth saying rather than hiding.
I built the answer before I had properly checked the question. This write-up is the check, run afterwards and in public.
03 — The artefact
Twelve modules, one operational picture
Circuit Command Centre is a desktop dashboard for a race-day operations room. It opens on an Overview that tries to answer one question — is the weekend under control right now? — and then lets a duty lead drop into whichever domain is not.
Twelve modules are built and all twelve render. None of them is a placeholder. What holds them together is a single fixed scenario, and building one continuous situation across twelve screens turned out to be the most useful discipline in the whole exercise. It is what forces the modules to agree with each other, and it is what makes the places where they disagree findable.
The one place the scenario slips: the status bar breaks the seven open incidents down as 1 P1 · 3 P2 · 2 P3 · 1 P4, and the Overview KPI card breaks the same seven down as 1 P1 · 3 P2 · 3 P3.
I found that while writing this page, not while building it.
Event
British Grand Prix · Silverstone · race day
Clock
15:41 · lap 24 of 52 · green flag
On site
142,300 of 150,000 capacity
Staff on station
1,284 of 1,332 · 48 gaps
Weather
18°C · rain risk 35% within the hour
Open incidents
7 · one P1 in Stand C, ambulance 90 s out
ALL TWELVE, ALL BUILT
Overview
The single is-it-under-control picture
Live Map
Zones, posts, routes and incidents in place
Incidents
The queue, the case and the escalation trail
Crowd Flow
Density, direction and throughput
Accessibility
Requests, attendants and facilities
Transport
Shuttles, parking and the egress plan
Staffing
Coverage, gaps and equipment
Security
Screening, perimeter and access control
Medical
Triage, cases, posts and vehicles
Communications
Channels, threads and broadcasts
Reports
Weekend totals and the audit log
Settings
Roles, permissions and preferences
04 — Retrospective desk research
What I found after the fact
This section is desk research, done after the prototype existed, to stress-test it. It is not the process that generated the design. I have kept it to sources I could check, and I have tried to be careful about what each one does and does not support.
Transport and egress — the strongest evidence, and it is Silverstone’s
The clearest recurring problem is getting people away from the circuit.
At the 2024 British Grand Prix, senior F1 figures and media were reported stuck in traffic for hours on both the Friday and the Sunday. BBC F1 correspondent Andrew Benson reported that this fed into F1 reconsidering Silverstone’s position on the calendar.
It is not new, and the circuit has never pretended it is. In an earlier wet-weather year, Silverstone’s managing director stated that the circuit spends over £1 million a year on car park and traffic management. That same weekend, up to 30,000 fans were told to stay away on one day because the car parks had waterlogged, and the delays carried into the following day.
It is also not confined to bad years. Current fan travel guidance for 2025 and 2026 tells people that getting out of the circuit typically takes at least an hour, and sometimes two to three, on the Sunday after the race — in normal, dry conditions.
And it is being actively worked on. For 2026, taxis and private hire vehicles are banned entirely from circuit and surrounding village access, with fans redirected to designated shuttle bus drop-off points. That is a real organisational response to a real, acknowledged, repeating problem.
Sources: GPFans on the 2024 weekend and the calendar question; BBC News on the £1 m figure and the 30,000 fans; Pitstop Glamping’s 2025/26 travel guidance; Taxi-Point on the 2026 vehicle access change.
“Absolute shambles.” A spectator described sitting in a car park for an hour and a half without moving, with no marshals visible directing traffic.
Tripadvisor review of the 2024 British Grand Prix. This is the only first-hand spectator account in this write-up, and it is one person’s experience of one weekend. I have not built a composite “what fans say” section, because there is no aggregated spectator sentiment data to build one from.
Crowd security — real, but industry-wide rather than Silverstone-specific
I want to be precise here, because it would be easy to blur two different things together. The transport evidence above is Silverstone’s. The security evidence below is not — it comes from other circuits, and I am not claiming Silverstone has these problems.
At the 2024 United States Grand Prix, the FIA fined the promoter roughly $550,000 — €500,000, with €350,000 suspended — after around 200 fans breached fencing and barriers to reach the track while cars were still completing their cooldown lap. The official finding was that the organiser failed to take reasonable measures, resulting in an unsafe situation, and a formal remediation plan was required.
At the São Paulo Grand Prix, organisers admitted safety failures after spectators reached the runoff area at turn one while cars were still on track. The FIA ordered a formal remediation plan.
At the Australian Grand Prix, organisers admitted security failures after fans breached barriers and reached a driver’s parked car. Stewards described it as an “unacceptable situation that could have had disastrous consequences” and ordered a review of marshal protection protocols. That weekend recorded 131,124 people on race day and 444,631 across the full race week.
Three different circuits, three different weekends, the same shape of failure: the gap between a barrier being breached and a coordinated response reaching the right place.
Sources: RACER on the US Grand Prix fine; ESPN on São Paulo; Flashscore on the Australian Grand Prix and its attendance figures.
The synthesis in the last paragraph is mine, not any source’s.
What already exists — and why this concept is not a competitor to it
Silverstone’s volunteer workforce is large, and it is already coordinated by real software.
The circuit works with over 700 volunteer Race Marshals, and over 1,500 Marshals and Race Makers combined, supporting more than 40 events a year. That workforce is coordinated using Rosterfy, a third-party workforce-management platform, adopted explicitly to replace manual processes with automation and to make administering the Race Maker Programme — which needs around 500 volunteers for a flagship event like the British Grand Prix — more seamless.
Source: Rosterfy’s own client announcement about Silverstone. Which is worth noting: it is a vendor’s account of its own deployment, so treat the framing accordingly. The workforce numbers are the checkable part.
POSITIONING — SAY THIS PRECISELY
Rosterfy and Circuit Command Centre solve different problems. Rosterfy is pre-event: it recruits, schedules, accredits and administers a volunteer workforce before the gates open. Circuit Command Centre is in-event: it is about what those people see and do during the four days once they are on station.
They are adjacent, not competing. This concept is not an improvement on Rosterfy — it sits next to a problem Rosterfy was never built for. I have not validated that distinction with anyone who uses either, and section 12 puts that first on the list.
What I could not find
THREE THINGS I WENT LOOKING FOR AND DID NOT FIND
—
No standardised live-operations platform across F1 circuits
No public evidence of one. It may vary by venue, it may exist and not be publicly documented, or the function may be distributed across radio, spreadsheets and venue-specific systems. I do not know, and I am not going to guess. This is the single biggest hole in my ability to position the concept.
—
No spectator-side heat-illness or medical statistics
Driver-side heat data exists — heat exhaustion cases treated in the medical centre at the 2023 Qatar Grand Prix — but drivers in fireproofs in a cockpit are not a proxy for spectators in a grandstand, and using them as one would be dishonest. The prototype’s pinned incident is a spectator heat-exhaustion case: a plausible scenario, not an evidenced frequency.
—
No aggregated spectator satisfaction or sentiment data of any kind
Which is why there is exactly one spectator voice on this page, quoted once, with its source named.
05 — Problem framing
A narrow claim I can actually defend
Here is the most I think the evidence supports.
Transport and egress coordination at Silverstone, and crowd-security response across several circuits, are documented, recurring and organisationally acknowledged problems in the live phase of a Grand Prix weekend. They are being worked on — the 2026 vehicle access change and the FIA-mandated remediation plans are proof of that. And the adjacent software known to be in use at Silverstone addresses the phase before the event, not during it.
So the gap this concept explores is specific: the live, in-event coordination layer. What the duty lead, the medical coordinator, the transport controller and the accessibility lead are all looking at between the gates opening and the last car park emptying — and whether they are looking at the same thing.
“Live phase” is doing real work in that sentence. A Grand Prix weekend has at least four operational phases — build, event, egress, teardown — and almost everything I could find evidence for sits in the second and third.
WHAT I AM NOT CLAIMING
I am not claiming that no solution exists. I could not establish that either way, and it is a genuine unknown rather than a rhetorical one. I am not claiming this concept would prevent a track invasion or clear a car park faster. I am not claiming a competitive advantage, because I do not know what I would be competing with.
What I am claiming is narrower: these are real problems, in a phase that at least one known adjacent tool does not cover, and that is a reasonable thing for a designer to go and explore.
06 — Scope and constraints
Who it is for, and who it is not for
The users are the operational side of the weekend: race control leads, circuit managers, marshals, stewards, medical teams, transport controllers, accessibility attendants, guest services, logistics and comms operators. The signed-in user in the prototype is a Race Control lead.
The users are explicitly not race teams. There is no car telemetry in this product, no tyre strategy, no lap-time analysis, no sector deltas. The only sporting information anywhere in it is context a marshal actually needs: which lap we are on, what flag is out, and in which sector — because a yellow flag in sector 2 changes what you can do about debris in sector 2.
That boundary was easy to hold because it is the thing that makes the product interesting. Race data is well served. The service around it is not the same problem.
THE FOUR CONSTRAINTS
→
Desktop-first, and desktop-only
A control-room surface: 1,600 px wide, dense tables, a twelve-column grid, a persistent status bar and a persistent left rail. Designed for someone at a desk with two screens, not for someone standing at post 12 in the rain. That is a deliberate scope decision and also a real limitation — the people who most need this are the ones holding a radio, and this build does not serve them.
→
One weekend, one moment
Everything is pinned to a single scenario: British Grand Prix, race day, 15:41, lap 24 of 52. Nothing in the interface has to cope with a different phase, a different circuit or a different day.
→
Seeded data throughout
No integrations, no feeds, no persistence. Section 10 is specific about exactly how far that goes.
→
Figma Make, exported to React
Built as a Figma Make experiment and exported as a React and TypeScript app on Tailwind and shadcn/ui. The generative starting point is why twelve modules exist at all, and also why several of them are broader than they are deep.
07 — Design system and principles
Calm by default, loud only when it has earned it
A control-room interface has one hard requirement: when everything is fine it has to be quiet, so that when something is not fine you see it immediately. Almost every design decision in this build follows from that one constraint.
None of these principles are written down in the code as comments. They are my articulation, after the fact, of intent that is visible in how the components are built.
01
Neutral ground, semantic colour only
The base palette is a near-monochrome neutral. Colour is reserved for state and carries one fixed meaning wherever it appears: emerald for nominal, amber for degraded, red for critical, sky for informational. Nothing decorative is coloured, and there is no brand accent competing with an alarm.
02
Status is never carried by colour alone
The severity badge renders colour and an icon and a word — a red octagon reading CRITICAL, an amber triangle reading WARNING. A colour-blind operator, or one working from a washed-out projected screen, loses none of it. This is the principle I am proudest of and the one I applied least consistently; section 10 has the count.
03
Tabular numbers everywhere
Every count, timer, percentage and clock uses tabular figures, so digits sit in fixed columns and a changing value does not make the row jitter. On a screen someone watches for eight hours that is not a detail.
04
Layered surfaces, hairline separation
Cards sit on a tinted ground with one-pixel borders and divided rows rather than shadows. Density comes from a tight, consistent rhythm, not from deleting whitespace.
05
A dark control-room variant
Both themes are specified as full token sets rather than as overrides, with blue-tinted neutrals in dark so a red alert reads against a cool ground instead of vibrating on pure black.
06
Role-scoped visibility
Six operational roles, each with its own answer to what it can see, what sensitive data it can reach, which channel it can broadcast on and what it is allowed to resolve. Building it forced the question of what a marshal should know about a spectator’s medical episode — a service-design question before it is a permissions one.
Settings. The roles-and-permissions matrix is the most considered piece of systems thinking in the build: a Medical Lead reaches patient data and can resolve medical incidents; a Security Lead reaches no patient data at all; a Marshal sees the map and their assigned incidents and can acknowledge, but not resolve. Everything else in Settings is a label.
The same Crowd Flow screen in the dark control-room variant — compare it with the light capture in section 08. Both themes are token sets rather than overrides, which is why the semantic reds, ambers and greens keep their meaning across the switch. The theme does not persist between sessions and does not follow the operating system preference.
08 — Key screens
Five screens that carry the idea
Every capture below comes from the running prototype at 1,600 px, not from a mockup. Click any of them to see it at full size.
Overview — is the weekend under control?
The Overview is one question asked repeatedly, and it reads top to bottom as a narrowing funnel: a global status bar with six always-on metrics, then five KPI cards for the numbers a duty lead is accountable for, then the operational map beside a rail carrying the single highest-severity incident and the triage queue behind it, then four domain summaries, then a full-width activity feed.
The pinned incident card is the piece I would defend hardest. One incident — INC-1045, Stand C, row 14 — with its owner, its team, its escalation level, a live countdown and a six-stage timeline showing exactly where the response has got to: reported, acknowledged, dispatched, en route ninety seconds out, on scene, resolved. It answers “what is the worst thing happening, and has somebody got to it” without a click.
Underneath, the activity feed is framed as an immutable audit trail. That was intentional. In an environment where an incident can become an FIA finding, who knew what and when is a design requirement rather than a nice-to-have.
Three of the numbers on this screen actually move: the clock, the pinned incident’s SLA countdown, and the shuttle vehicles on the map. Every other LIVE badge is a label.
The full Overview screen. Weather advisory, five KPI cards, the filter toolbar, the operational canvas and its right rail, four domain summaries, and the audit feed.
Live Map — the operational canvas
The map is the piece that most wanted to exist and is most compromised. It layers eight spectator zones with live occupancy, four car parks with fill percentages, crowd-density heat, five shuttle routes with vehicles that actually move along them, an accessible footway, and pins for twelve marshal posts, four medical posts, an ambulance en route, five gates, three accessible facilities, four CCTV positions and every open incident. A layer panel toggles all nine layers, a legend explains every mark, and selecting a zone opens its detail: occupancy against capacity, marshals on station, nearest medical post, accessible seat utilisation, egress gates and the stand lead’s name.
The marshal posts carry real Silverstone corner names — Abbey, Village, Loop, Aintree, Maggotts, Becketts, Chapel, Stowe, Vale, Club, Copse, Woodcote — and the meta strip displays the circuit’s length, turn count and coordinates.
Two things this capture shows honestly: the labels collide at default scale — Media Centre, Paddock and VIP overlap, and Stand A sits under the legend — and only one of the eight zones has detail data behind it. Clicking any zone other than Stand C silently shows Stand C’s panel.
Live Map with all layers on except CCTV. Every mark on it is real product logic; the shape underneath it is not.
KNOWN PLACEHOLDER — REAL SILVERSTONE LAYOUT GOES HERE
The track outline under all of that is not Silverstone. It is a hand-drawn stylised shape — the code calls it exactly that — and I have left it visible and labelled rather than quietly shipping an approximation. A case study about a specific circuit gets read by people who know that circuit, and a wrong track shape would undermine every accurate thing sitting on top of it. The real traced layout replaces it here.
Incidents — the queue and the case
Incidents splits into a sortable queue and a single case detail. The queue carries ID, severity, title, zone, team, owner, time opened, SLA remaining, escalation level and status. The detail pane carries the escalation workflow as a staged timeline plus a chronological update thread — 15:35 symptoms logged, 15:36 ambulance dispatched, 15:38 yellow flag held for clearance, 15:41 responder ninety seconds out, crowd parted, marshals assisting.
That thread is the most service-design-ish thing in the build. It is the same incident seen from medical, from race control and from dispatch, on one timeline, in the order it actually happened.
Underneath, there is no shared incident model. The type file holds a severity scale and a list of screen names and nothing else; the incident data is written inline in two screens with two different shapes. Section 10 has the detail.
Incidents. The queue on the left, the case and its escalation timeline on the right.
Crowd Flow and Security — why they are two modules
These two started as one idea, and splitting them was the best decision in the project.
Crowd Flow is physics. How many people are where, which way they are moving, how fast, and whether a space is filling or emptying. Its table has a flow-direction column — inflow, holding, outflow, pinch point — and an action column that reads Normal, Monitor or Throttle. It is the module you open to decide whether to hold a stairwell or release a contraflow.
Security is intent and access. Who is trying to get somewhere they should not be, what is in their bag, whose accreditation is valid, and which fence line just tripped a sensor. It runs its own incident register, its own screening-line health and its own perimeter state.
The seam between them is deliberately left visible, and you can see it in the two captures below.
Organising by response rather than by subject is the piece of this project I would carry into unrelated work. The question that produced it was not “what kind of thing is this” but “who acts on it, and what do they do”.
Crowd Flow. Ingress against forecast egress, zone density and circulation with a flow-direction column, gate throughput, and the pre-staged egress plan. Note the congestion alert: Stand C tunnel, pinch, density 96%, holding, eleven minutes old.
Security. Threat posture, the incident register, screening-line health, access control to sensitive zones and the perimeter. Second row of the register: SEC-087, crowd push, Stand C tunnel mouth, critical, opened 15:31.
THE SEAM, AT 15:31
Same tunnel, same minute, same people. Crowd Flow files it as a density problem that gets solved by throttling flow. Security files it as a safety incident that gets solved by putting six more stewards there. Both readings are correct, they have different owners and different responses, and a single merged “crowd” module would have hidden that from everybody.
09 — Iterations
What the prototype taught me by being wrong
Three changes, in the order they happened. Each came from looking at what I had built and finding that it did not hold up.
01 — The status bar was compressed to the point of uselessness
The first version squeezed the global metrics into a thin strip, on the reasoning that chrome should be minimal and content should get the room. That was wrong for this product. Those six numbers — event phase, open incidents, attendance, staffing, weather, transport — are the ones that stay true regardless of which module you are in, and a strip that thin left no room for the qualifying line underneath each value.
“1,284 / 1,332” tells you very little. “1,284 / 1,332 · 96.4% coverage · 48 gaps” tells you whether to worry. I rebuilt the bar as two rows of full metric cards, each with an icon, a status dot, a value and a support line.
BEFORE
A single compressed strip of bare values.
AFTER
Two rows: identity and controls above, six metric cards below, each with a support line that turns a number into a judgement.
02 — The map was a blank frame pretending to be a map
The early version had the container, the card header and the layer chrome, but nothing operational inside it. It looked like a map and answered nothing.
Populating it is what turned this from a dashboard with a picture in it into an operational tool: zones with real occupancy, marshal posts at named corners, medical posts and a moving ambulance, gates with queue times, shuttle routes with vehicles on them, crowd-density heat, and every open incident pinned in place. The map is where the other eleven modules become one situation.
BEFORE
Empty canvas, correct chrome, no content.
AFTER
Nine toggleable layers carrying roughly sixty operational marks, and a zone-detail panel behind the eight spectator zones.
03 — Crowd Flow and Security overlapped, so I split them by function
Both modules were reporting on the same physical events and I could not tell which one I was supposed to open. The split, described in section 08, is by what you do about it rather than by what it is: flow management on one side, threat and access on the other, with the overlap left visible rather than resolved away.
That reframing — organising by response rather than by subject — is the piece of this project I would carry into unrelated work.
BEFORE
One “crowd” module reporting density and breaches together.
AFTER
Two modules with different owners, different tables and different verbs, and a shared incident that appears in both.
10 — What it does not do
Everything that is a picture of a thing rather than the thing
This is not a caveats paragraph tucked at the bottom. It is a list, and it is here because a prototype that looks this finished will be read as more functional than it is.
TEN THINGS THIS PROTOTYPE DOES NOT DO
✕
Every number is seeded
There is no API, no feed, no socket, no database. The 142,300 attendance, the gate wait times, the shuttle headways, the weather — all of it is hardcoded. Nothing in this product has ever been connected to anything.
✕
Only three things are actually live
The status-bar clock, one SLA countdown on the Overview, and the shuttle vehicles moving along the map routes. Every other LIVE badge on the screen is a label.
✕
There is no SLA engine
There is a number that decrements and a function that formats it as mm:ss. “Auto-escalates L3” is text. Nothing computes a breach, and nothing escalates.
✕
There is no shared incident model
The type file contains a severity scale and a list of screen names, and that is all. The incident data lives inline in two different screens with two different shapes — one calls it severity, the other sev; one stores SLA as seconds, the other as a string. I kept them in sync by hand.
✕
Most controls are not wired
Search, New incident, Assign, Broadcast, Escalate, Post, Call lead, Push-to-talk, Fill, Export CSV, Generate report, and every filter chip render their states correctly and do nothing. The map’s zoom and recentre buttons have no handlers.
✕
Only one map zone has detail data
Clicking any zone other than Stand C silently shows Stand C’s panel.
✕
The accessibility preferences do not work
Settings displays High-contrast, Reduce motion, Large text, Audio alerts, Keyboard-only navigation and Screen reader announcements as configured settings. They are read-only text. Worse: the interface animates a pulsing indicator on live badges and on the critical incident marker while displaying “Reduce motion · On”, and never checks the user’s actual motion preference.
✕
Status is not always icon-backed
The severity badge does it properly. The plain status dot — used in gate queues, shuttle lines, staffing coverage, perimeter sensors, access control and vehicle status — is colour-only, with its meaning in an adjacent column at best. I set a rule and then broke it in six places.
✕
The track outline is a placeholder
Covered in section 08, and worth repeating here so it cannot be missed.
✕
The map does not render in the exported build
I found this while preparing this write-up. A card’s content wrapper has no explicit height, so the map’s full-height rule resolves against nothing and collapses to two pixels — its own borders — and everything on it is clipped away. It is a two-line fix, and I have since made it. The map captures above were taken with that height forced, which I would rather say than not.
11 — Reflection and limitations
What I actually learned, and what I have no right to claim
These two columns are equal weight on purpose. The right-hand one is not a list of caveats attached to the left-hand one — it is the more important half.
WHAT THE EXERCISE WAS GOOD FOR
One scenario across twelve modules is a method
Not a content chore. It is what surfaced the Crowd Flow and Security overlap, and it is what made the inconsistencies findable — including the P-count mismatch I only spotted while writing this.
Organising by response, not by subject
The best structural decision in the project came from asking who acts on this and what do they do, instead of what category is this.
The permission matrix changed the product
Deciding that a marshal can acknowledge but not resolve, and that a security lead reaches no patient data, is a service-design decision that happened to be expressed as a settings table.
Calm-by-default is testable
Every time I wanted to add colour I had to justify it as state. Most of the time I could not, and the screen got better.
WHAT I CANNOT CLAIM
No primary research
No interviews, no shadowing, no observation, no competitive teardown before building. The research in section 04 is retrospective, and it is labelled as such throughout.
No validation with anyone who does this work
Not one marshal, steward, medical coordinator, transport controller or circuit operations manager has seen this. Every workflow in it is my inference about what those roles need, and inferences about other people’s work need evidence from those people.
The competitive picture is genuinely unclear
I could not establish what circuits currently use for live operations. I am positioned against an unknown.
Mock data only
Which means the interface’s hardest questions — what happens at four hundred incidents instead of seven, what a stale feed looks like, what a partial outage looks like — have not been asked at all.
Desktop-only, which inverts the priority
The people whose experience this is nominally about are standing at posts holding radios. This build serves the person at the desk.
One real spectator voice, quoted once
I would rather quote one real person than synthesise a chorus.
A prototype this finished is a claim about feasibility, not a claim about need. I have evidence for the first and none for the second.
12 — What I would do next
The order I would actually do it in
01
Put it in front of people who do the job
Before another pixel. Marshals, Race Makers, stewards, a medical coordinator, a transport controller. Not a usability test of the interface — a conversation about whether the model underneath it resembles how a weekend is actually run. Everything else depends on this step, and it is the one that could invalidate the whole thing, which is exactly why it goes first.
02
Validate the Rosterfy adjacency with someone in circuit operations
I have argued that pre-event workforce management and in-event coordination are different problems. That argument reasons from public material, not from anyone who has used either. One conversation with someone who administers the Race Maker Programme would confirm the positioning or collapse it.
03
Build the mobile companion, because it is the actual product
The desktop control room is half the system. The other half is what a marshal at post 12 sees on a phone: their assignments, acknowledge and status, an escalate button, and the two or three facts about their zone that matter. The desktop view reconciles information; the mobile view generates it.
04
Wire one real feed end to end
Not all of them. One — weather is the obvious candidate, since it is genuinely public and genuinely operational. Doing one properly forces every question the seeded version dodges: latency, staleness, partial failure, and what the interface says when it does not know.
05
Give the incident model a home
One shared type, one severity scale reconciled with the P1–P4 triage scale, one enumerated state machine, and an SLA rule that actually computes a breach and actually escalates.
06
Trace the real Silverstone layout
Properly, from a licensable source, at correct geometry — and then check the label collisions the real shape will create.