A traffic scheme editor

The challenge

Traffic engineers draw the road scheme of a city: every lane marking, sign, curb and traffic light, to the standard, on top of a surveyed base. Before the editor this work was done in AutoCAD, a general-purpose drafting tool that has been on the market for over 40 years and is used by everyone from architects to mechanical engineers. For traffic design it is a set of workarounds: markings are drawn by hand as rectangles and fitted, signs come from templates each engineer keeps for themselves.

Nobody complained about it. AutoCAD is not a tool you judge for convenience; it is a tool you learn. A new engineer spent 4 to 5 weeks with an instructor before drawing a scheme on their own, and then kept asking senior colleagues how things work. The pain was the company's: a month of training per hire, plus the time of the people who answered the questions.

The brief was to move AutoCAD to the cloud with multiplayer. The goal I set for the product was different: the “Figma for traffic engineers”, a specialized tool that a new hire can use without a course.

Phase 1: Interviews

I started by interviewing 30 traffic engineers, 14 of them new hires, to understand their daily workflows, and I dug into the company's hiring and onboarding to see where the month of training actually went. Three things from those interviews shaped the product:

• No shared legend. Every engineer had their own symbols for signs and callouts; some did not draw the post at all. Templates were personal, not the company's.
• Everything is manual. Bike parking, hatching and line markings were drawn as rectangles and fitted by eye. The standard says what the marking is; AutoCAD does not know it.
• Nobody learns AutoCAD, they learn the office. New hires learned which senior to ask, not where the tool is. That is why the training took weeks.

So instead of asking what was inconvenient in AutoCAD, I asked what these people used outside of work: Word, Excel, social apps, map apps. The patterns from there are understood without an instruction, and the editor was built on them.

Phase 2: The first sketch

Before diving into the mechanics of AutoCAD and its alternatives, I sketched a baseline interface: a layout that someone far from engineering could understand, built on the patterns people meet in everyday software. The test for every element was simple: would a new hire find it without asking.

Phase 3: What to borrow

I looked for inspiration across both direct competitors and indirect tools. While I paid close attention to Autodesk as the market leader, I also analyzed tools like Cinema 4D and Figma.

I was particularly interested in Autodesk’s Fusion 360. Even though it's an industrial 3D design tool, it represented Autodesk's "next generation" of cloud-based software. I wanted to see what legacy features they chose to abandon and what they replaced them with. Seeing that Fusion 360’s layout closely aligned with my initial sketches and Figma's interface was a strong validation of my concept.

Phase 4: Planning and trade-offs

Working with the Product Manager, I defined the MVP, prioritized the backlog and broke it into sprints. Three decisions from this phase show how I argued for the design:

• Keep the engineers' classification. The standard divides markings into types, not into the linear, point and area groups our system needed internally. The tech lead wanted the system's groups in the tool palette. I argued that engineers would never look for a crosswalk under “area markings”, so the palette follows the standard, and the system's grouping only shows up as what you can convert a line into without redrawing it.
• A layers panel. AutoCAD has no layer tree like Figma or Fusion 360; it relies on a set of commands to reach objects hidden under other objects. The PM argued against a panel, fearing it would eat screen space. I showed that a “hide UI” shortcut costs nothing, while memorizing commands is exactly the month of training we were trying to remove. The layer tree in Fusion 360 was the closing argument.
• Map-first project creation. A road scheme always has a place. In AutoCAD the workflow was: create a blank canvas, paste a map screenshot, scale it by hand, draw the project border, draw on top. Engineers did this every time and never mentioned it, because it was how it had always been. I designed the opposite: open the map, select the area, the project is created with the base already in place. When I tested it with them it was the first thing they asked when the release would be. It did a lot to build trust early on, and it is a good example of why I do not wait for users to ask.

Phase 5: Usability sessions

After the core architecture was set, the team spent a long stretch populating the app with specific tools: road surfaces, curbs, markings, signs, and traffic lights.

For months I ran usability sessions on the drawing mechanics. For each round I built a prototype and gave engineers a real task from their work, then watched where they clicked, where they looked for each tool, and whether they finished without help. Two things came out of those sessions. The sign library had to follow the state standard to the number, not the traffic code: engineers drawing the existing situation could not find the configuration they needed, and the first library had gaps and wrong numbers. And the selection filter, hiding all signs to work on markings alone, was something they asked for themselves, so it moved up the backlog.

Once the core interactions held up, adding a new tool became a matter of reusing the same mechanics with new attributes. At that point I stepped back from day-to-day design and handed the editor to a mid-level designer, reviewing his work, while I moved to the traffic management system (TMS) and the design system.

Results

The product was launched to the engineering teams after about a year and a half of development.

• Shorter onboarding: Training dropped from 4 to 5 weeks in AutoCAD to 3 to 5 days. New engineers drew their first schemes on day one and learned the automation tools as they went, without an instructor.

• Adoption: By the time I moved to a consulting role in 2023, approximately 70% of the city's road network had been mapped using this product. The company then sold the tool to several other large cities.
• Foundation for the ecosystem: The product eventually expanded to include analytical layers, traffic simulation, and 3D viewing capabilities. Most importantly, the data drawn in the editor became the street data source for Yandex Navigator and fed the company's other city systems, including the traffic management system.