Context

The Event Management System, internally called Lagebericht, is used by incident managers and dispatchers in European rail control centers. When a disruption happens (a delay, a technical fault, weather, a signaling issue, an infrastructure problem), someone in the control room needs to do three things at once: document the incident for internal records and regulators, coordinate the operational response, and communicate to passengers.

Before the redesign, these three tasks lived in three different tools. Documenting the incident happened in one rigid form. Coordination happened in chat and phone calls. Passenger communication happened in a separate system with a different login, a different tone, a different set of rules. Every disruption meant switching windows, copying the same details three times, and hoping nothing got lost between systems.

The project ran fully agile in two week sprints. My dual role as Senior Product Designer and Project Manager meant I sat at both ends of the delivery. On one side, running user interviews and workshops with our customer contacts (incident managers, dispatchers, operations leads). On the other side, sprint planning with our engineering team, ticket prioritization, roadmap decisions, and handoff coordination. That closeness to both customer and team is what kept the design honest and the release cadence predictable.

The Problem I Was Asked to Solve

Two problems really, tied together.

First, the old Lagebericht form was one size fits all. Every incident, from a minor delay to a major infrastructure failure, was documented with the same rigid template. Fields that mattered for a signaling fault were noise for a weather delay. Fields that mattered for a passenger evacuation were missing entirely from the standard form. Incident managers filled in what they could, skipped what did not apply, and left context in free text fields that later became hard to search.

Second, the report itself was the end of the workflow. What passengers actually saw came out of a separate system, written by a different team, from scratch. The delay between an incident being logged and passengers being informed was longer than it needed to be.

The brief: make the Lagebericht flexible enough to serve every incident type without overwhelming users, and connect it directly to passenger communication so information flows out fast and accurately.

Discovery

Three activities in parallel over three weeks.

Incident manager interviews. Sessions with control center staff who use the current Lagebericht daily. Focus on their workflow during a real disruption, not the ideal case. Mapped where they abandoned the form, where they used workarounds, and where they resented the tool.

Retrospective analysis of past incidents. Reviewed the past 6 months of incident reports across categories. Identified which fields were actually filled, which were left blank, which were used in non standard ways. Also looked at the average time between incident start, incident logging, and first passenger notification.

Contextual observation. Sat with two dispatchers during actual shift work. Saw the switching between tools, the parallel documents, the phone calls happening while typing.

Key insight from this phase: incident managers do not want less structure. They want the right structure for the specific incident they are handling. And they want the same information they type internally to feed the passenger message, not to be typed again.

Approach

Framed the redesign around three testable hypotheses:

1. A modular form where users select the incident type and get a tailored field set will reduce cognitive load and improve report quality compared to one rigid template.

2. Attaching supporting PDFs (signal diagrams, infrastructure maps, external reports) directly to the incident record will reduce time spent linking documents across systems.

3. Generating a passenger information draft directly from the incident record, with a tone shift built in, will reduce time to first passenger notification and reduce inconsistency between internal and external communication.
   

Ran a two week concept sprint with Product, Engineering, incident managers and a content specialist to shape direction.

Design Decisions

Modular field selection. At the start of a new incident, the user picks an incident type from a list of common categories (delay, signal fault, infrastructure, weather, safety event, other). The form then shows only the fields relevant to that type, with sensible defaults where possible. Every field can be added manually if the incident does not fit the template. Choice made: put field selection upfront rather than progressive disclosure inside the form, because during a real incident users have no patience for a form that grows as they type.

PDF attachments treated as first class citizens. Not buried in a secondary tab. On the main incident view, the attached PDFs sit alongside the structured fields with previews. Uploaded once, reused across the incident lifecycle. External reports (from regulators, from infrastructure partners) attach to the same record so the full context lives in one place.

Passenger information as linked output, not the same document. From within the incident record, users trigger a passenger information draft. The system pulls the relevant fields (route affected, expected delay, cause in plain language) and drops them into a passenger facing template with reassuring tone rules baked in. Users edit if needed, then send it out to the passenger channels directly from the interface. Choice made: keep the internal Lagebericht and the passenger message tonally separate, because the same wording that satisfies a regulator can alienate a stressed commuter.

Templates as starting points, never as constraints. Every incident type has a template. Every template is fully editable. Nothing generated by the system is final unless the user confirms it. That principle is repeated in the UI copy and the interaction design.

AI as Multiplier

Established a Claude plus Figma workflow for this project too, this time with a specific focus.

Claude helped surface edge case combinations of incident types and field sets that would be tedious to enumerate manually. For each of the six incident categories, Claude proposed which fields typically matter and which do not, based on synthesized interview notes. Every proposal was then reviewed with two incident managers before entering the design.

Claude also drafted default passenger information templates per incident category. Tone rules were embedded in the prompts. The drafts were a starting point, always rewritten in collaboration with the content specialist. Same pattern I keep relearning: AI gets to 75 percent fast, the last 25 percent needs human judgment the model does not have.

Outcome

• Time from incident logging to first passenger notification reduced significantly (measurable after full rollout)

• One unified interface replaced three separate tools, fewer window switches per incident

• Fewer duplicate data entries because passenger information now draws from the same source as the internal record

• Higher completeness of incident documentation because the modular form asks only for what matters

• Design system components from this project (modular form, template editor, tone aware output) reused in the wider portfolio harmonization work

What I Learned

Emergency and incident systems have a paradox at their core. Users need flexibility to handle the specific situation in front of them, but they also need simplicity so the tool does not slow them down when seconds matter. Solving that paradox is not about adding options. It is about making the right options obvious in the right moment and hiding everything else.

Another lesson: internal tools and external communication should never be separate systems if they describe the same event. The cost of that separation shows up as delay, inconsistency, and stress on the people in the middle who have to keep both in sync.

And a lesson that came back from the RTPI project: the language layer of a product is not decoration. In an incident context, the difference between a well written passenger message and a badly written one is trust in the operator. That is a design responsibility as much as any interaction pattern.

Selected Visuals

[Add screenshots from your actual work here: incident type selection screen, modular form with field set changing, PDF attachment view, passenger information generation view with template plus edit mode, comparison of old rigid form and new flexible form, workflow diagram from tool switching to unified interface]

Role Details

Owned the redesign end to end from 2025 to Present in a dual role as Senior Product Designer and Project Manager. Wrote the brief, ran discovery interviews with customer incident managers and dispatchers, facilitated concept sprints, designed the interfaces in Figma, coordinated engineering handoff, ran usability tests with real users in the control center context. On the delivery side, led two week sprint planning and prioritization with the engineering team, tracked roadmap, coordinated with QA and Business, and kept the customer stakeholders looped in through sprint reviews. Cross functional collaboration with Product, Engineering, QA and Business, plus domain experts on the customer side in incident management, dispatching and passenger communication.