Sliderule Plain Text Diffs

Empowering technical users in a no-code rules engine

Summary

Role: Lead Product Designer

Timeline: 1.5 months

Team: product lead, frontend developer, backend developer, product designer (me)

Responsibilities: Led UX and interaction design for plain text diffs, from scoping requirements with the product lead to final specs. Partnered closely with our frontend developer to evaluate an existing diff package and adapt the design to its strengths and limits.

Challenge: After Sliderule’s acquisition by Block, the user base shifted to more technical users, including ML scientists and data scientists. To better support their needs in Sliderule, we prioritized a few code features, the first one being plain text diffs.

Outcome:

• Support tickets regarding diffs dropped to zero within a week of launch

• Diff usage increased 50%

• Validated demand for more code-native features for Sliderule’s technical users

The problem

Plain text diffs were the first code feature we released because the original diffs caused the most friction. They were UI-based, brittle, error-prone, and made it hard to see what had changed between workflow versions. Users had lost trust in them and spent a lot of time double-checking their work before deploying. For large workflows, this was extremely cumbersome.

Product strategy

Our users already knew Git diffs well, so I used Git’s conventions as the baseline. There was no reason to reinvent the wheel. Early conversations with our frontend developer uncovered a package we could build on, so she didn’t have to start from scratch. Speed mattered because the old diffs were a major blocker. Minimum requirements included:

• clear and simple change count (additions and subtractions of logic)

• search functionality because large workflows were common and data connectors can pull in massive amounts of data

• diff accuracy

Design

Meeting users where they already are: I kept the conventions our users trust from daily Git use: green for additions, red for removals, and line numbers. We offered both unified and side-by-side views, because preference varies by person and task, and forcing one would have created friction for a group of users we were trying to win back.

A change count you can trust at a glance: A summary of additions and removals sits above the diff, so users can confirm “is this the change I expected?” before reading a single line.

Choosing the right tradeoff on search: The package’s built-in search worked differently from what I had designed. Rather than drop the package or build a diff engine from scratch, we weighed what mattered most: the package’s diffs were accurate and reliable, which was the core of the trust problem. So we kept it and tweaked its search to make it easier to use. Tweaks included match highlighting and auto-scroll to the matched locations. This let us ship fast without compromising the thing users cared about most.

Accuracy over polish The old diffs broke because they compared UI state. Plain text diffs compare the workflow’s underlying logic, so what users see is exactly what changed.

Key results

Users adopted the new diffs immediately after launch. Instead of manually re-checking their work before every deployment, they could see exactly what changed and move on with confidence. The drop in tickets confirmed that users no longer needed help to understand their changes. We had rebuilt the trust the original diffs had lost.

Reflection

The biggest lesson was that good design is sometimes restraint. Reinventing the diff would have cost time and asked users to unlearn something they already trusted. Partnering with engineering early mattered just as much: knowing the package’s limits up front let us make a deliberate tradeoff instead of discovering it late. The project’s success also proved that Sliderule’s technical users wanted more code-native tools, and it paved the way for the next feature: a plain text view of entire workflows.