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
TL;DR
Tars lets enterprise teams build AI agents as visual flowcharts, but debugging large agent canvases meant manually tracing hundreds of nodes to find where conversations broke.
I designed and shipped Debug Mode, an automated testing experience with adaptive workflows for technical and non-technical users. The feature reduced troubleshooting time by ~70%, shipped within a month.
Core Features
One glance tells if the flow is healthy
Single-signal canvas
Shows exactly where the debugger is at every node, so the CS team doesn't lose their place and doesn't have to scroll back to the start.
Failing node, highlighted automatically
When the system identifies a connection break between two nodes, the first node turns red and the canvas zooms straight to it, so the CS team can go in and see exactly what needs fixing.
Simple and clear controls
Play/pause, stop, restart. These same three controls work for the CS team and for a client with no dev background.
Impact
Faster troubleshooting, strong adoption and lasting trust
Faster Troubleshooting
~70%
Troubleshooting time dropped by roughly 70% post-release, time that used to go entirely into manually tracing broken flows.
Became the team's default workflow
The CS team started running Debug Mode every time a chatbot changed, often multiple passes in a single update.
Earned enough trust to fade into the background
On the release call, Tars' CEO described watching a CS team member start a test run, switch to other work, and check back only occasionally.
Context
500 nodes in a flow, one broken link and two different users
Problem: Finding failures in large flows was painfully manual
The CS team was losing hours debugging chatbots with 500+ nodes. Identifying where a flow broke meant manually searching through the huge canvas for the error, losing their place, restarting from the beginning, and repeating this process.
Navigating this visually complex canvas was the bottleneck that was costing turnaround time for enterprise clients.
Constraint: The same tool had to serve two very different users
The CS team needed detailed debugging signals like API errors and JSON, while clients would eventually need a much simpler experience. Rather than compromise both, we scoped Debug Mode's first release for the CS team, using their feedback to inform a future client-facing version.
Design Evolutions
Iteration 1: One signal instead of three
Why didn't this work?
Three status colors (active, passed, error) layered onto 500+ blue nodes created more visual noise than clarity.
The shipped solution
Instead of relying on multiple colors, I designed the active step to be the single visual focus: full opacity with a subtle glow while the rest of the canvas faded to 40%. Animated connector lines previewed the execution path.
When something broke, the run paused automatically at that unresolved node. The failing node would turn red and the canvas zoomed directly to it.
Iteration 2: Six debugger controls down to three
Multiple controls that would have complicated the workflow.
Why didn't this work?
The first version featured traditional IDE conventions: play/pause, stop, step into, step out, step over, logs.
The CS team could read it, but these advanced controls were where non-technical clients would stall. This wasn't a scalable design.
Three simple, clear controls that got the job done.
The shipped solution
I shipped three controls with clearly stated status messages, so nothing about what the tool was doing had to be inferred.
That cut held up against real usage. Within a couple of months, 90% of errors traced back to minor control changes or API and custom code issues, the exact cases the three-control version already covered.
Scope Decisions
Shipping in phases and shelving the debug console
The first release focused on the CS team. As enterprise onboarding accelerated, reducing their debugging time mattered more than waiting for a version that served everyone. Shipping in phases let us solve the immediate problem first.
The debugging console 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.
The debug console design that was shelved
In Hindsight
What I'd add today
Passive notifications
Watching the CS team trust the tool enough to multitask revealed one missing piece: they still had to look back at the canvas to know when a run paused. I'd add sound and desktop notifications so the debugger could actively alert them.
Surface run health at a glance
While the canvas showed where failures occurred, understanding the overall health of a test still required scanning the flow. I'd add status pills summarizing nodes tested, errors found, and run progress, giving the team an at-a-glance view of each run.