Robotic Process

Automation (RPA) Recorder

Led end-to-end design for ServiceNow's RPA Recorder, a tool that simplifies and democratizes the development of RPA automations by allowing non-technical users to record their tasks and generate an automation based on the recording.

Timeline

Jun 2022 – Mar 2023

Interface

Windows Application

Role

Lead Product Designer

Time

5 min read

Team

Solo designer working with product and engineering

Responsibilities

End-to-end UX design ownership, User research & validation, Interaction & UI design, Design specifications, Cross-functional stakeholder alignment

Robotic Process

Automation (RPA) Recorder

Led end-to-end design for ServiceNow's RPA Recorder, a tool that simplifies and democratizes the development of RPA automations by allowing non-technical users to record their tasks and generate an automation based on the recording.

1.1

[overview]

problem

1.1

[overview]

problem

1.1

[overview]

problem

1.1

[overview]

problem

1.1

[overview]

problem

1.1

[overview]

problem

Problem

Robotic Process Automation (RPA) mimics human interactions with user interfaces to automate routine tasks—clicking, typing, and navigating exactly as humans do. This makes RPA particularly valuable for legacy applications without APIs, enabling automation without complex system integrations.





ServiceNow's RPA development platform offered a low-code solution for creating automations (Figure 1), but still required significant technical expertise—limiting its accessibility for non-technical users. While business experts could spot automation opportunities, it was difficult for them to create simple proof-of-concept (POC) automations without developer support. Creating these POCs was a complex process and took time away from their core strategic priorities.

Adding to this challenge was a clear market gap – most of our competitors offered a "recorder" tool that allowed non-technical users to create automations simply by recording their tasks. This feature had become an industry standard, and its absence from our platform was increasingly noted in sales conversations with potential customers.

Figure 1: RPA Development Platform (Desktop Studio)

Figure 1: RPA Development Platform (Desktop Studio)

Figure 1: RPA Development Platform (Desktop Studio)

Figure 1: RPA Development Platform (Desktop Studio)

Figure 1: RPA Development Platform (Desktop Studio)

Figure 1: RPA Development Platform (Desktop Studio)

1.2

[overview]

solution

1.2

[overview]

solution

1.2

[overview]

solution

1.2

[overview]

solution

1.2

[overview]

solution

1.2

[overview]

solution

Solution

Our solution empowers non-technical users to create automations through a modern and streamlined recording interface inspired by consumer screen recording tools (Figure 2). A collapsible panel and persistent mini-recorder provide clear recording status while staying unobtrusive—a departure from traditional enterprise software interfaces. The tool automatically detects UI elements across different applications and presents contextual actions through an elegant dark interface, guiding users without getting in their way. When recording is complete, all captured actions automatically translate into a ready-to-use automation workflow in the RPA Desktop Studio, enabling non-technical users to create automations independently.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

2.1

understand

business goals

2.1

understand

business goals

2.1

understand

business goals

2.1

understand

business goals

2.1

understand

business goals

2.1

understand

business goals

Business Goals

To kick-off this project, I facilitated a workshop with PMs and engineering leads where we established a shared understanding of our goals and guiding principles:


  1. Citizen developers (business users) should feel empowered to build automations.

  1. Using a recorder should increase developers' speed and accuracy.

  2. Recorder should simplify the automation building experience and become a tool that users rely on for all their automations.

This helped align the team's vision and set the foundation for the project's direction.

2.2

understand

competitive analysis

2.2

understand

competitive analysis

2.2

understand

competitive analysis

2.2

understand

competitive analysis

2.2

understand

competitive analysis

2.2

understand

competitive analysis

Competitive Analysis

Through analysis of Gartner and Forrester reports, I discovered that recorder functionality had become a standard requirement for RPA platforms to be included in this report, and these analyst reports are widely used by IT departments of corporations, and often influence their buying decisions.

I then performed a competitive analysis of the six key competitors and observed that five out of six competitors already offered this feature. 



I worked through a comprehensive task flow in each of these recorders and analyzed the experience to learn what they were doing well and what we could do better.

Figure 3: Comparing the Experience of Competitors and a UX Summary

2.3

understand

user research

2.3

understand

user research

2.3

understand

user research

2.3

understand

user research

2.3

understand

user research

2.3

understand

user research

User Research

It became clear that having a recorder tool is important for us to be a competitive player in the RPA business, however, I wanted to see how this tool would help our users. I conducted user interviews to validate the need of this recorder, as well as, to understand their goals, motivations, and pain points.

Hypothesis
RPA Recorder will

  • Enable developers to build automations faster

  • Enable solution consultants to build automations for customer demos easily.

  • Enable business users to capture the process and hand it over to IT.

  • Encourage business users to build the automation themselves.


Methodology
Method: Moderated 60-minute remote user interviews
Target User Groups: RPA Developers, Solution Consultants, Business Users
Users (n=8): 3 RPA Developers, 3 Solution Consultants, 2 Business Users

Insights

The interviews revealed critical user workflows and unmet needs around RPA tooling. This research filled a significant gap—our team frequently referenced "professional developers," "citizen developers," "business users," and "process owners" without a shared understanding of who these users actually were or how they worked. I synthesized the findings into persona cards that define each user category, their company role, and how a recorder tool would integrate into their existing workflows.

Figure 4: User Research Insights

Figure 4: User Research Insights

Figure 4: User Research Insights

Figure 4: User Research Insights

Figure 4: User Research Insights

Figure 4: User Research Insights

3.1

ideate

user and task flows

3.1

ideate

user and task flows

3.1

ideate

user and task flows

3.1

ideate

user and task flows

User & Task Flows

Given the insights, I created a user and task flows for two target users:

  1. Primary User - Citizen Developer

  2. Secondary User - Professional Developer




At this stage, I did not create a flow for mid-level developer because I find that designing for different ends of the spectrum often covers most use-cases for those in the middle.

Figure 5: Primary Task Flow for Citizen Developer/Business Technologist (Primary User)

Figure 5: Primary Task Flow for Citizen Developer/Business Technologist (Primary User)

Figure 5: Primary Task Flow for Citizen Developer/Business Technologist (Primary User)

Figure 5: Primary Task Flow for Citizen Developer/Business Technologist (Primary User)

Figure 6: Primary Task Flow for Professional Developer (Secondary User)

Figure 6: Primary Task Flow for Professional Developer (Secondary User)

Figure 6: Primary Task Flow for Professional Developer (Secondary User)

Figure 6: Primary Task Flow for Professional Developer (Secondary User)

Figure 7: Primary User Flow

Figure 7: Primary User Flow

Figure 7: Primary User Flow

Figure 7: Primary User Flow

Figure 7: Primary User Flow

Figure 7: Primary User Flow

3.2

ideate

ideation

3.2

ideate

ideation

3.2

ideate

ideation

3.2

ideate

ideation

3.2

ideate

ideation

3.2

ideate

ideation

Ideation

I then translated the above task flows into lo-fi and mid-fi screens and ideated on the recorder interface.

Figure 8: Lo-fi Ideation V1 (Focusing on the Recorder Interface)

Figure 8: Lo-fi Ideation V1 (Focusing on the Recorder Interface)

Figure 8: Lo-fi Ideation V1 (Focusing on the Recorder Interface)

Figure 8: Lo-fi Ideation V1 (Focusing on the Recorder Interface)

Figure 8: Lo-fi Ideation V1 (Focusing on the Recorder Interface)

Figure 8: Lo-fi Ideation V1 (Focusing on the Recorder Interface)

Figure 9: Lo-fi Ideation V2 (Translating the Task Flows into Lo-Fi Flows)

Figure 9: Lo-fi Ideation V2 (Translating the Task Flows into Lo-Fi Flows)

Figure 9: Lo-fi Ideation V2 (Translating the Task Flows into Lo-Fi Flows)

Figure 9: Lo-fi Ideation V2 (Translating the Task Flows into Lo-Fi Flows)

Figure 9: Lo-fi Ideation V2 (Translating the Task Flows into Lo-Fi Flows)

Figure 9: Lo-fi Ideation V2 (Translating the Task Flows into Lo-Fi Flows)

Figure 10: Mid-Fi ideation of the Recorder Interface

Figure 10: Mid-Fi ideation of the Recorder Interface

Figure 10: Mid-Fi ideation of the Recorder Interface

Figure 10: Mid-Fi ideation of the Recorder Interface

Figure 10: Mid-Fi ideation of the Recorder Interface

Figure 10: Mid-Fi ideation of the Recorder Interface

Back to Drawing
Board

Despite making progress on the designs, I felt unsatisfied with the designs I kept drawing. It felt too predictable, too similar to competitiors, and too “enterprise-y.” I felt stuck and wanted to do something to inspire me and think outside the box. Thus, I organized a collaborative brainstorming session with designers outside the project to bring fresh perspectives. This helped break away from market conventions (that I was so conditioned to seeing) and led to exploring diverse design directions that were more inspired by consumer software.



This helped me create new concepts.

Figure 11: Design Brainstorm

Figure 11: Design Brainstorm

Figure 11: Design Brainstorm

Figure 11: Design Brainstorm

Figure 11: Design Brainstorm

Figure 11: Design Brainstorm

Concept 1 - Floating Recorder Control

4.1

define

define and refine

4.1

define

define and refine

4.1

define

define and refine

4.1

define

define and refine

4.1

define

define and refine

4.1

define

define and refine

Define & Refine Solution

To decide which concept I would further refine and focus on, I systematically evaluated these concepts by creating a comprehensive matrix that weighed various factors such as technical feasibility, user experience impact, alignment with existing patterns, and future scalability.

This systematic evaluation helped guide stakeholder discussions and ultimately led to selecting a concept that balanced innovation with practical constraints. Despite Concept 3 “scoring lower” than Concepts 1 and 2 in the above matrix, it stood out to me as the perfect balance of innovation, feasibility, and scalability. The rest of the team agreed and found this solution to be sleeker than that of our competitors, while still being technically feasible. This design, was a significant departure from traditional enterprise design, bringing delight to our users’ experience as it resembled consumer experiences that they’ve known and loved.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

4.2

refine

design decisions

4.2

refine

design decisions

4.2

refine

design decisions

4.2

refine

design decisions

4.2

refine

design decisions

4.2

refine

design decisions

Key Design Decisions

The recorder tool design required addressing several critical considerations to create an intuitive experience within ServiceNow’s complex ecosystem:

  1. Platform Integration: Introducing a new tool within an established and complex RPA development environment.

  2. Manual Action Recording: Balancing technical constraints with user expectations.

  3. User Trust & Privacy: Building confidence through transparent data capture communication.

  4. Workflow Review, Editing and Saving: Enabling users to validate and refine recorded actions before converting to workflow.

  5. Visual Design & Theming: Navigating inconsistent design systems across acquired and native products.

Platform integration

Challenge: Integrating a simplified recording tool into ServiceNow’s complex RPA platform.

Solution: Created multiple entry points and contextual guidance to reduce friction for both new and existing users:

  • Feature introduction modal to educate users about the new capability

  • Easy-access launcher button for quick tool activation

  • Contextual help integration linking to documentation and future interactive assistance

  • Dismissible discovery popup for users who want to explore the feature later


This multi-pathway approach ensures smooth adoption across different user comfort levels and experience with the platform. Ideally, we would have addressed the daunting "blank canvas" experience when starting new projects, this broader UX improvement was beyond the recorder tool's scope.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Manual Action Recording

Challenge: While the ideal RPA automation would seamlessly record screen actions and convert them directly into workflows, technical constraints and user requirements made this impossible. Developers need to automate actions not easily captured through screen recording (like extracting text from form fields) and perform multiple actions per element. Additionally, technical limitations prevented pulling data from all applications users might interact with.




Solution: Designed a "bounding box with manual action" experience that balances technical constraints with user needs:

  • Explicit element selection with showing available actions allowing users to select different interactions (set text, click, hover, get text, etc.)

  • Manual input prompts for actions requiring user-provided data

  • Clear confirmation feedback when each action is successfully recorded


This approach accommodates both technical limitations and developer requirements for precise control over multiple actions per element across various applications.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

user trust & privacy

Challenge: User concerns about data capture and privacy during recording sessions.




Solution: Clear visual communication throughout the recording experience:

  • Clear recording status indicator with color-coded states (inactive vs. active recording)

  • Real-time feedback showing what and how elements can be recorded with bounding box overlays

  • Confirmation messages providing immediate feedback when interactions are successfully captured




These design decisions prioritize user trust through transparency, ensuring users always understand what data is being captured and when.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Review, Edit & Save

Challenge: Users needed to track, manage, and finalize recorded automation sequences across multiple applications before converting them into executable workflows.


Solution: Implemented a collapsable side panel interface that provides recording oversight without losing context:

  • Action list overview showing all captured interactions with their source applications

  • Management controls for deleting unwanted actions (editing and drag-drop reordering planned for future releases)

  • Cross-application tracking to support automation workflows spanning multiple apps or websites

  • Workflow conversion allowing users to save recorded sequences as workflows for further development in desktop studio




The collapsable side panel approach was ideal compared to all other concepts I explored because it maximized screen real estate while providing a persistent, scannable view of the automation sequence as users continued recording across different applications.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Visual Design & Theming

Challenge: ServiceNow’s design system was in transition—the acquired RPA product used Design System V1 (light theme, green accent), while ServiceNow was launching Design System V2 (purple accent, dark theme capability). I had to decide whether to design the recorder tool using the current RPA theme (increasing design debt) or the new system theme (creating temporary inconsistency between recorder and RPA platform).

My Approach: I recommended implementing the dark theme based on strategic considerations:

  • Design system alignment with ServiceNow's V2 trajectory

  • Enhanced visibility against light UIs of typical web/legacy applications

  • Modern appeal that could strengthen sales positioning

While most engineers and PMs supported my recommendation, conflicting opinions and communication breakdowns late in development created tension when designs were changed without designer involvement. Working with a newly acquired team unfamiliar with UX processes, I invested significant time building relationships, educating stakeholders on design's strategic value, and clearly communicating this multi-faceted rationale.

Resolution: After extensive discussions between design, product and engineering leadership, we established a phased implementation—launching with light theme for immediate compatibility, then transitioning to dark theme in the subsequent release. This balanced immediate business needs with long-term design system alignment.

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

Figure 2: Recording Actions on a Form

5.1

implement

impact and opportunities

5.1

implement

impact and opportunities

5.1

implement

impact and opportunities

5.1

implement

impact and opportunities

5.1

implement

impact and opportunities

5.1

implement

impact and opportunities

Impact & Opportunities

While I transitioned before launch, the project delivered:

  • A modernized recorder tool

  • Foundation for future dark mode implementation

  • Framework for feature enhancements


Identified areas for enhancement:

  • Improved onboarding experience

  • Better field name capture

  • Interactive tutorial system

  • Dark mode implementation

5.2

implement

learnings

5.2

implement

learnings

5.2

implement

learnings

5.2

implement

learnings

5.2

implement

learnings

5.2

implement

learnings

Learnings

Research Validation & User Understanding: The project reinforced the critical importance of thorough user research, even when a solution seems predetermined. While we started with a mandate to build a recorder tool, our research:

  • Challenged assumptions about who would use the tool

  • Precisely identified our primary user group (citizen developers)

  • Validated the business case with concrete user needs

  • Provided clear direction for feature prioritization


Design Leadership & Advocacy: Working with a newly acquired team that had limited experience in working with design, highlighted the importance of design leadership:

  • Established design's role in decision-making processes

  • Built relationships with stakeholders through clear communication of design rationale

  • Learned to balance firmness on user needs with flexibility on implementation

  • Developed strategies for maintaining design quality while meeting business timelines

Personal Growth: Through this project, I developed:

  • Stronger stakeholder management skills, particularly in challenging situations

  • Better understanding of enterprise software development constraints

  • Improved ability to advocate for design decisions

© 2025 Akanksha Kevalramani. All Rights Reserved.