The Problem
N-able's platform strategy — the "Ecoverse" — centered on unifying its product library into one integrated automation ecosystem. Scripting was a core piece of that: partners needed to automate IT asset management tasks like registry changes, software distribution, and device configuration, but the existing approach was unreliable and opaque. Script reliability was a frequent complaint in at-risk churn feedback — scripts timed out, didn't run in real time, and technicians had to manually double-check whether a script had actually run, with no clear output showing what had happened.

My Role & Constraints
I worked on UX/UI design for Scripting within a large, cross-functional team spanning five countries — four-plus PMs, four-plus engineers, three designers, two researchers, and info-dev. My focus was specifically on component and interaction design. I began by mapping the full set of workflows a user would need to create and execute a script, which shaped where prototyping effort was focused, and I personally ran feedback sessions with PMs, engineering, and the extended UX team throughout development.

Process & Key Decision
Engineering testing surfaced a real risk: the script creation page's original three-column layout could break for users on smaller or split screens, and the team was debating whether to instead split the flow into separate steps or tabs. Rather than resolve it on opinion, I pulled usage data showing well over 90% of users were on HD monitors, which supported collapsing to a two-column layout instead — the data settled the debate, and two columns shipped.

I also pushed for two specific additions early on. I advocated for input and output parameters on scripts, designed with the foresight that they could later be used to monitor and manage devices directly within the platform — this was unanimously agreed on and built into the feature. I also proposed a migration strategy to help users move from N-able's existing Automation Policy (AMP) tooling in the classic platform over to the new scripting tool; that wasn't prioritized at the time.

Outcome
The feature shipped in phases — the first release let users create and store scripts but not test or run them; a later release added execution. Reception was positive, but adoption has been limited by a broader structural issue: Scripting lived in N-able's new Ecoverse platform, and compatibility between the Ecoverse and the classic platform was incomplete, so many partners kept using their existing, familiar tools rather than switching over. The input/output parameters I pushed for were built and adopted as planned. The migration strategy I proposed wasn't taken forward at the time — in my view, that gap is still a factor in adoption today, since without it, users had little practical reason to leave their existing workflow behind.