Will the run match the plan?האם ההרצה תתאים לתכנית?

Overview

Someone has to build the near-miss

A self-driving team can't wait for the road to produce a dangerous moment, so someone builds one: take a recorded drive, add a car that cuts in, run it in simulation. That person plans what should happen. The simulation decides what does, because the vehicle under test drives itself.

The Scenario Designer is where they do it, from scratch or from a recording: the first two steps of Foretellix's flow. I designed it so the author can see the gap between plan and run: what is wrong before a preview, what happened in it, and what changed from the recording.

One question ran under every screen, and four design decisions came out of it: will the run match the plan?

---

The problem

A plan nobody can check until it runs

At first, users could only review and debug simulation results, not edit or create them. It took four steps:

1. 1
   An export panel. The leanest start: Smart Replay, inside the run debugger. Keep recorded actors, change their speed or position, export a new test.
2. 2
   New actors. They called for a complete editor. I started designing it while extending Smart Replay.
3. 3
   A separate editor. A temporary step: Smart Replay left the debugger. It could vary a recording, not start from scratch.
4. 4
   One editor. The Scenario Designer: new scenarios from scratch, and edits to existing results.

New actors also brought the harder problem, the one this case study is about. In a cut-in, the author adds a car that changes lane just in front of the vehicle under test. That vehicle drives itself: a little faster or slower than assumed, and the cut-in comes too early, too late, or not at all.

---

How I worked

Stand-ins and questions in writing

For its first months the editor had no product manager. So alongside the design I defined the features, wrote the user stories and acceptance criteria, and set the priorities.

I had no direct contact with the people who would use it, but I wasn't working blind. A contact at the main customer worked closely with us on requirements, and a second customer sent a clear written list of needs. The rest came from:

• Stand-ins for users. Internal usability sessions with colleagues in the author's seat, dogfooding, bug-bash findings, and a persona. The session planned with a customer's user never took place.
• Open questions, in public. I wrote down what nobody had decided, from error severity to auto-save, and the answers became the specification.
• Prototypes to vote on. Where a choice was open, I built the options for the team to try.
• Two designers. They kept the Smart Replay side moving under my written direction while I designed the editor.

---

Market research

What eleven other editors do

I compared eleven scenario-authoring tools on nine aspects. They split on how to describe a path, and most kept a structured view of the scene beside the map: the questions behind decisions 1 and 2.

---

Design decision 1

A path made of waypoints

A new actor needs a path. The benchmark showed two ways to describe one. Some tools use waypoints: points on the map that the car passes in order. Others use segments: one stretch of driving after another, each with its own behaviour.

What was cut

One of the application engineers I interviewed before making this choice asked to see the waypoints on the timeline as well as on the map. I designed it: one row for each actor, one dot for each waypoint. It was cut before production and never built, because customers didn't seem to need it.

What came back

Segments returned later. An actor may have to follow one stretch of its path exactly and adapt to traffic on the next, and that setting belongs to the stretch between two waypoints. So the author still places waypoints, and the segment between them carries the behaviour.

---

Design decision 2

One tree for the whole scene

By early 2026 a scene held the vehicle under test, recorded actors, added actors, segments, triggered actions and parameters. In a flat list, people lost their place.

Six of the eleven benchmarked tools put a structured scene list beside the map. The PM and the tech lead weren't convinced it was a must, so I built a working prototype in the product's own code. The PM came round as the feature details got deeper, and I believe the prototype helped.

The tree also carries an idea that was the PM's: set a behaviour on a group and every actor in it follows. My part was the rule for exceptions. An actor you changed by hand keeps its value until you reset it.

---

Design decision 3

Two kinds of issues, shown where they happen

Some problems can be known from the plan itself. Others only a run can reveal. An author who can't tell them apart doesn't know whether to fix the plan or run it again.

An issue also shows up where the author is looking: on the waypoint that causes it, with the reason. In the table, each row names every actor involved.

---

Design decision 4

Preview: the run beside the plan

Comparing started in the run debugger: a result is checked against the original noisy log, and against other versions and variations of the same test.

In Smart Replay, comparing meant a long loop: change, extract, execute, then open the result elsewhere.

The check is gradual, cheapest first:

• Play. The exact planned path. No behaviour, no alerts.
• Preview. A real run on Foretify's default simulator, not the customer's. Representative, and much faster.
• Launch. The customer's full configuration, variations included. Much slower.

The PM and I wanted two levels, with Preview on the customer's full configuration. That was too slow and cost the customer more. The middle level was the tech lead's solution.

The fix: promoting an actor duplicates it. The original stays as a reference layer, and the edit sits on top.

---

Process change

One component, in Figma and in code

Each panel of the editor started as a master component in Figma: the inspector, the tree, the actor controller. Every ticket's delivery screens were built from them, with each state numbered and annotated.

When an idea had to be tried rather than looked at, I built it in a prototype branch of the product, on the same shared components engineering uses, as with the tree.

Keeping Figma and the shared components in step was ongoing work. In the last year I could close the gap myself: with Claude Code I changed the shared components and merged them into the main repository, where Storybook documents them.

---

Outcome

What an author can do now

By September 2026 the editor had shipped with:

• Authoring from a run or an empty map. Actors, paths by waypoint, triggered actions, preview, save and launch.
• The issues model as specified, with the log beside it.
• The scenario tree, on by default in one of the two apps that host the editor.
• Two names from my prototypes, shipped word for word: "Save as new test" and the before-you-leave dialog.

In one internal usability session, a stand-in user built a cut-in scenario in about 15 minutes.

Adoption at the main customer stayed low, and with no product analytics and no direct access to users, nobody could establish why. My read is that they needed variations at scale more than scenarios authored one at a time.

What I would do differently

Push the automation direction earlier. I had built a working mock of prompt-based authoring inside the editor and didn't fight for it. Two customers kept asking for exactly that. Next time the mock goes in front of customers early, and the cost of having no direct user access gets written down on day one.

---

What next

Editing in plain language

Editing by prompt, with an AI agent that makes the change, was one of the first things customers asked for, and that mock is where I wanted the editor to go next. The author describes a change, and the assistant answers with a proposal: drawn on the map beside the plan, named in the editor's own terms, and waiting for Accept or Discard.

• A proposal, not an edit. Nothing changes until the author accepts, and every accepted change can be undone in one step.
• In the editor's terms. The reply names the actor, the waypoint or the triggered action it will change, so the author can check it in the tree and the inspector.
• Two ways in. From the chat, for changes to the scene, or from an actor on the map, for changes to that actor.