Designing an internal debugger that cut troubleshooting time by ~70%
Shipped
Oct 2022
Industry
B2B SaaS
Role
Product Designer
Team
CS Team, CTO, CEO, Developers
What is Debug Mode?
Debug Mode is a testing tool inside Tars, where teams build AI agents as visual flowcharts. It runs a conversation through the flow and stops on the node where it breaks.
Before it, the CS team traced 500+ nodes by hand to find one broken link. I designed and shipped it within a month.
Core Features
The canvas follows the run and stops where it breaks
The active node stays in focus
The canvas tracks the debugger node by node, so the CS team doesn't lose their place in a 500 node flow.
Failures surface on their own
When a connection breaks, the run pauses on that node and the canvas zooms straight to it in red.
Three controls that anyone can run
Play/pause, stop and restart. I kept the set small enough that a client with no dev background could use it once Debug Mode shipped for them.
Impact
Debug Mode became part of every chatbot update
On the release call, Tars’ CEO described a CS team member starting a run and moving on to other work.
Troubleshooting Time
~70%
Time that used to go into tracing broken flows by hand.
Iterations
Iteration 1: Three status colors down to one signal
Before
The canvas I was designing for had 500+ nodes and all of them had the same visual treatment.
Design Iteration
My first idea was to color code every node by status. I soon realized while testing that adding three more colors on top of all that blue made the one failing node harder to find.
It also made the canvas more chaotic, which was something I wanted to avoid.
Shipped Design
I dropped the status colors and made the active node the only thing that stands out. It stays at full opacity while the rest of the canvas fades to 40%.
The failure node still needed to stand out from the other nodes, so I retained the standard ‘red-failure’ treatment for it.
Iteration 2: Dropping the code editor conventions
Design Iteration
My first version borrowed from code editors: play/pause, stop, step into, step out, step over and logs. The CS team could work with it.
However, clients were going to use this tool next, and for anyone without a dev background the step controls are where they’d get stuck.
Shipped Design
I kept play/pause, stop and restart, with a status line that says what the debugger is doing at any moment.
Within a couple of months, 90% of the errors the CS team ran into came from small control changes or API and custom code issues that were reported via the debugger. These three basic controls covered all of them.
Shelved Design
The debugging console was never shipped. I had designed it as a way to surface deeper error reports, but once V1 launched, the CS team found the simpler interface handled nearly every issue.
Since engineering support was rarely needed, the console was shelved.
Reflections
Runs should call people back
Once the CS team started leaving runs on their own, they still had to keep checking the canvas to see if one had paused.
I’d add sound and desktop notifications so Debug Mode could tell them.