top of page

USERLANE EDITOR

Refine Selector: making a developer tool usable without developers

Userlane

¡ 2021 to 2022

Senior Product Designer

Developer tools UX, Progressive disclosure, Editor design

Sequencing a feature redesign so non-tech users could navigate the DOM without reading code. 🔍

CHALLENGE

Before the redesign, only 1 of 7 users could use the Selector, and even the IT manager needed help from Customer Success. 🚨

  • Userlane's Editor lets non-developers build in-app guides on top of any web application. To do that, the Editor has to select the right HTML element on the customer's page.

  • The DOM was hard, especially in apps like SAP SuccessFactors and Salesforce where element IDs are dynamic and similar elements repeat. The Selector amplified that with raw JSON, a binary found / not found status, and unlabelled controls.

  • 2021 customer research surfaced the scale: 1 of 7 participants felt comfortable using the Selector. Even the IT manager in the group needed help from Customer Success.

  • Guides let bad matches get fixed inline during recording. Tooltips raised the stakes: persistent placement meant a wrong match appeared on multiple unintended UI elements at once. The Tooltips MVP made the redesign acute.


Context on the full Editor work lives on the Userlane Editor landing. This deep dive is about the Selector redesign specifically.

WHAT I ACHIEVED

Redesigned the Selector in 2 iterations, and established a progressive-disclosure pattern the team applied everywhere else. 🏗️

  • Redesigned the Selector with the squad in 2 iterations. A v1 shipped from an internal hackathon, and a v2 in subsequent sprints.

  • Established a progressive-disclosure pattern the team continued applying to other technical Editor surfaces.

  • Built as a shared component, so updates in one place reflected across every content type.

WHAT I LEARNED

Let users build the mental model first. Add power tools second. 🧠

  • V1 gave users a visual HTML tree, basic positioning controls (order num, parent num), and a fall-through code selector for advanced cases.

  • Attribute visibility (IDs and classes) was deliberately excluded from v1. Attributes would be essential for SAP- and Salesforce-class apps. Loading them in on day one would bury the framework under unfamiliar information.

  • V2, several months later, added attribute visibility, language refinements, and interaction improvements.

DESIGN DECISIONS

Two decisions that made a developer tool usable without developers. 🎨


  1. Ship the smallest viable version of a complex tool. Add capability once users had the framework. 📦

  • Deferring attributes to v2 was the call I'd repeat.

  • Simpler applications got value immediately. Harder customers got a navigable framework in v1 and full support in v2.



2. The Selector couldn't tell users why an element wasn't found. So we designed for what it could tell them. 🔍

  • The Selector couldn't tell users why an element wasn't found. A dropdown? A modal? A dynamic load? Engineering iterated and concluded the system genuinely doesn't know. The underlying app's state isn't observable to Userlane.

  • So we designed for what it could tell them:

    • A count of similar elements ("23 similar elements").

    • A clear unique state.

    • A grey, disabled "not found" state.

  • Editors could reason about the problem themselves, even when the system couldn't diagnose it.

  • Warning users about ambiguous elements that would cause issues later became the design's job.



OUTCOMES

Recurring sentiment: "We've been waiting for this for a long time." 📈

  • 2 rounds of internal qualitative feedback from Customer Success and Implementation teams. Strongly positive in both rounds. Recurring sentiment: "We've been waiting for this for a long time."

  • ~80% positive ad-hoc customer feedback on the Selector specifically.

  • Honest limit. No formal post-launch usability re-test, no Selector-specific telemetry. I closed that gap by instrumenting Selector success and abandonment events from day one of v1, so v2 could be measured against v1 rather than against memory.

REFLECTION

The harder lesson was accepting that some problems aren't mine to solve, and finding the adjacent one that is. 🪞

Making a technical feature usable for non-tech users is one of the satisfying things about working on B2B platforms. Creativity and user understanding both matter.


The v1-to-v2 sequencing was the call I'd repeat. Shipping the smallest viable version of a complex tool, and adding capability once users had the framework, worked better than giving them everything upfront.


The harder lesson was accepting that some problems aren't mine to solve, and finding the adjacent one that is.

bottom of page