Cloud Scripts

The capstone of Smartpoint Cloud agency automation tools. A low-to-no-code automation tool.

Role: Lead Designer, Researcher

Duration: Ongoing

Overview

Smartpoint users faced challenges with legacy automation tools that were hard to use and maintain. We developed Cloud Scripts, a low-code/no-code tool for Smartpoint Cloud to address this. Cloud Scripts simplifies automation, making it accessible to non-technical users and improving workflow efficiency. Since its launch, user feedback has been highly positive, with many reporting easier automation and increased productivity. It has also helped drive the adoption of Smartpoint Cloud by those agencies for which automation is critical. Further enhancements are planned.

Cloud Scripts is a part of Smartpoint Cloud. To see more of Smartpoint Cloud follow this link

The challenge

Our users previously relied on a suite of legacy tools within Smartpoint Desktop to automate tasks and simplify workflows. These tools, which we referred to as “scripts,” were essential but came with significant challenges. They were cumbersome to use, had steep learning curves, were difficult to maintain, and made it hard to migrate or share scripts. Additionally, building these tools was costly. Despite these issues, they offered our users a critical benefit—automation that streamlined various tasks.

When we transitioned users to our new platform, Smartpoint Cloud, the need for an updated automation solution became clear. We needed to create a tool that would maintain the benefits of automation while addressing the pain points users had experienced with the legacy tools.

The Solution

Our research highlighted the need for a more intuitive, user-friendly automation tool. We designed and developed Cloud Scripts, a low-code/no-code automation tool tailored specifically for Smartpoint Cloud. The goal was to simplify the user experience of building automation scripts, reduce the learning curve, and empower more users to automate their workflows without requiring extensive technical knowledge.

Key features and benefits

Key Features & Benefits:

Simplified User Experience: Cloud Scripts offers an intuitive interface that makes building and managing automation scripts more accessible, even for non-technical users.
Increased Accessibility: The low-code/no-code design allows those who might have been previously excluded from automation to easily create and implement scripts and automation.
Improved Workflow Efficiency: By automating tasks and simplifying processes, Cloud Scripts enhances overall productivity for users across the platform.
Increased adoption: Giving users a native automation tool removes a large obstacle to agency adoption for Smartpoint Cloud.

Results and feedback

Since the launch of Cloud Scripts, user feedback has been overwhelmingly positive, with many reporting significant improvements in task automation and ease of use compared to legacy systems. This has directly contributed to the adoption of Smartpoint Cloud by over 100 agencies, particularly those that rely on automation to streamline operations.

Additionally, Cloud Scripts has played a pivotal role in securing major business deals with key industry players, where automation was a critical factor in the decision-making process. We continue to refine the tool based on user feedback, enhancing its capabilities to drive even greater value.

Demo of Cloud Scripts

Cloud scripts.mp4

Discovery & research

Research summary

Context: Users migrating to Smartpoint Cloud (SPC) still needed to use legacy automation tools and scripts.

Objective: Test if SPC's new features could replace legacy automation tools.

Research Conducted:

Survey of 100+ users who use automation with the old software.
In-depth interviews with 6 script creators and managers (45-60 minutes each).
Analysis of existing automation tools and a comparison with modern solutions.

Key Findings:

Most users follow an iterative process: create, test, release, and reevaluate scripts.
There’s a need for a faster way to create and share scripts.
High Usage of Automation: 75% of survey respondents use automation/scripts multiple times daily, mainly for:
- Time-saving by automating repetitive tasks.
- Standardizing tasks (e.g., ticketing, refunds) to reduce errors.
- Prompting users during specific tasks or workflows.
- Adding custom content not supported natively by SPC.
Pain Points with 3rd Party Tools:
- Steep learning curve, with many users preferring no-code solutions.
- Poor integration with agency software.
- Difficulty in sharing and maintaining scripts and automation.

Details

Research on Automation & Scripting in Smartpoint Cloud (SPC)

During the migration to SPC, we aimed to understand whether its advanced functionalities could replace legacy automation tools and scripts. To validate this, we conducted:

A survey of 100+ users who rely on automation tools.
In-depth discovery interviews with 6 script creators & administrators (45–60 min each).
Analysis of existing automation tools, mapping their functions to identify gaps and opportunities.
Competitive research on modern automation tools for best practices.

Key Findings:

Users follow an iterative process: gather needs → create script → test → release & reevaluate.
There’s a strong need for a fast, easy way to create & share scripts within SPC.

"I don't create Smartbuttons from scratch... I only edit existing ones [because] I don't know where to start" - Research participant

"Script creation is considered to be time-consuming and complicated. Therefore, a specialist is required at the agency to either create scripts or act as a manager of script creation and maintenance" - Research finding

Key findings continued:

The research also showed us that the newer functions of SPC would end some scripting needs. However, a robust and powerful scripting tool is still needed. It was found that 75% of survey respondents use some script or automation multiple times a day. This is for the main following reasons:

Time-saving by automation of repetitive tasks and workflows
Standardize certain parts of their day (ticketing and refunds etc.) to reduce errors
Prompting users during certain tasks or flows
Adding custom or bespoke content that SPC will not support natively

Smarbuttons editor example

An example of Smartbuttons editor, the primary legacy tool for our users. You can see that the Primary way the script is displayed is in XML language. There are "helper" buttons that will convert some inputs (as shown) to XML but the user is still required to know and be proficient in XML to use Smartbuttons.

From the research, we also found some pain points with 3rd party automation software in use today:

A steep learning curve with the knowledge of coding languages being a prerequisite. The majority of users stated they prefer a tool with no coding
Poor integration with users’ selected agency software
Difficulty sharing and maintaining scripts and automation.
Users like the output of the automation and scripting tools, not the creation process.

The problem

Smartpoint Cloud lacks a powerful scripting tool. Customers have stated that while their older automation tools may be clumsy, they are still needed. We assumed Smartpoint Cloud would cover this need without requiring an automation tool, but our research showed this was incorrect. We aim to create a new automation tool native to Smartpoint Cloud. This will increase the adoption of Smartpoint Cloud by agencies that rely on automation and scripting, and improve user efficiency, saving time and errors.

Objectives

Design and build an automation tool that goes above and beyond what is already available for our users and agencies.

Take a “no code” first approach, with a set of inbuilt advanced tools for more advanced user groups.

Make the tool native to Smartpoint Cloud so there is no need to download and integration is seamless

Improve user efficiency related to automating tasks and workflows, driving agency adoption of Smartpoint Cloud

User groups or Personas

Smartpoint Cloud has existing personas, but we needed to explore beyond those and into a set of sub-pseudo personas or user groups.

Although these user groups are important to design for, the primary focus rests with the Creator and admin-level groups as they will have the larger touch point with the feature.

These user groups can also be roughly translated to the Smartpoint personas as shown below. These are not perfect translations but allow us to tie our user groups to more robust personas.

User

Will only ever use a script, knowingly or unknowingly
Has minimal to no interaction with creating scripts or automation tools
Not interested in creating scripts
Usually an entry-level agency employee
Usually unaware that scripts are being used in the day-to-day workflow

Creator

Along with using scripts, they will lead creating scripts for themselves or their entire team
Interested in time-saving and enhancing the workflow of their day-to-day tasks
Has some technical knowledge of SPC and processes and can work with complex bookings
Usually a mid to senior-level employee with solid experience and foundation in the industry

Admin/Manager

As well as the points listed for the creator role:

Take the lead for testing and refining scripts for their team
Manage the sharing and distribution of scripts
Take the lead role in automating and standardizing complex tasks in common everyday workflows
Has extensive technical knowledge of SPC and the Travel Industry
Usually an agency manager or Senior high-level employee at their agency

Designing

I created the first assets after analyzing our research and solidifying the objectives. I also went through many rounds of wireframe ideation and design reviews.

Once I had a basic set of wireframes I worked with the development team to refine and iterate on the design.

Working with these assets, we deployed the first live product for testing. Due to the tool's complex nature, we decided to build a live version rather than test a design prototype.

Internal teams and customer-facing representatives would test this live proof of concept. This approach allowed us to move quicker and catch flaws in our product faster.

Internal testing and changes

Deployed in the development environment for internal testing.
Conducted as a live moderated test with internal users.
Users were given task-based scenarios and asked to report issues.
The test lasted 1 hour
Included a mix of experienced and novice users to assess usability across skill levels.
Findings:
- Most users completed tasks without issues.
- Some technical and usability problems were identified.

Technical Issues were resolved before the next release phase. The most significant usability issues and solutions are listed below.

Issues

It was easy to get lost when the script was long and contained many steps. The user had to scroll, and they often ended up lost and unaware of what step they were on.
Errors were hard to find and identify.
When building, each step was too large and took up too much space in the flow.
No way to recover deleted scripts or identify which scripts have unsaved changes.
Editor modal can block SPC when testing scripts.
No advanced settings or Admin level page.

Solutions

Refined the editor layout to make it an infinite canvas. Each step became expandable and collapsable. We added zoom controls via mouse scrolling and buttons.
An error panel was introduced listing all errors with quick links to jump to each error in the script. Icons were also introduced to identify which scrips had errors and of what type.
The step builder panel was taken outside the flow and placed in a panel, reducing clutter on the editor canvas
Introduced a “deleted scripts” page in the widget to allow recovery of deleted scripts. Added a marker and warning for scripts with unsaved changes.
Enhanced editor modal, introduced minimize/maximize restore, and moved control to the editor modal.
Introduction of an advanced settings page where Admin users can manage their scripts and eventually distribute scripts to other users and teams.

Using design guidleines

After testing we wanted a way to be able to build and design faster. I created a set of design guidelines. The development team could then build without having to review each design decision.

Because of this, I had to work closely with our Atlas Design System team to design, develop, and introduce several new components to the Design System library.

Example of a Figma file of the design guidelines.

Atlas Design system contributions

What is Atlas Design System:

The Atlas Design System is Travelport and Smartpoints internal design system and style guide.
Figma Design libraries and React developer libraries for designers and developers to consume.
Collection of components, templates, fonts, tokens, and guidelines

Why use it?

Atlas maintains brand consistency across our products and ensures a cohesive look and feel.

Due to the nature of Cloud Scripts, it required several components or enhancements to existing components. We had 2 choices on how we could do this:

Build and maintain the new components ourselves outside the library, and update them to keep them in line with Atlas, or;
Incorporate them into Atlas for others to use and ensure that they are always up to date.

We chose to incorporate them into Atlas.

How did I contribute to Atlas?

In my design file, I created a set of guidelines for the development team. These were a combination of Atlas components and new custom components. The new custom components would need to be added to Atlas.

Atlas uses a specific process to add components to the library

I followed these specific steps to create and add serval components to the Atlas library:

The step header
The small rounded "+" button
The draggable "step block"

All of these were added and updated into the Atlas library for use by teams who consume the Atlas design libraries.

Current implementation

After incorporating the changes from testing, and working with the new design guidelines we arrived at our current implementation.

Cloud scripts.mp4

Video demo of Cloud Scripts

Widget

Visible to all user groups.
Displays all scripts for viewing, triggering, and managing.
Provides access to the editor and advanced settings.
Always visible on the user’s homepage in the tool panel.
Users can:

Edit or share individual scripts.
Mark scripts as favorites for easy access.
See script statuses (unsaved changes, errors, triggers, and types).
Filter and sort the script list.
Restore recently deleted scripts directly from the widget.

Editor

Only visible to the creator and admin user groups.
Serves as the core engine for creating, editing, and testing scripts.
Features an infinite canvas layout for both high-level overviews and detailed step-by-step editing.
Each step is built and edited in a side panel when selected.
A toolbar at the top includes the script name and controls for building and testing.

Advanced settings

Visible only to Admin user groups.
Allows users to manage existing scripts.
Supports importing and exporting scripts individually or in bulk.
Enables deleting scripts one by one or in bulk.
Each column has a built-in sorting function.

Key takeaways

Getting enough research and data: The research and the data for this project was a big task. But it gave us a great base to build from and allowed us to make informed decisions that would benefit our users. It took significant time to collect and synthesize, but it was worth it for the insight it gave us.
Cross-team communication: Communication between Design, Product, and Development became crucial in the later parts of this project. Initially not as good as it could have been, we set up more frequent stand-up meetings and opened up more lines of communication. Because of this we could communicate issues more effectively and solve those problems faster.
Testing: In this project, we prioritized user testing at multiple stages during development. This allowed us to catch and fix issues sooner.

Next steps and challenges

Selecting Variables

The vast number of variables available within the application that the user can sell, etc is large. They also tend to have unintuitive names so selecting them can be difficult if you are unsure what to look for. This is our next challenge.

Discovery and design are already underway to introduce a smart search. This will autofill to allow users to search for variables by name and similar names. Reducing the need to learn each variable.

i.e. the variable for selecting a passenger in the booking file could be searched and found by using “passenger”, “traveler”, “person”, etc.

Distribution

Sharing of scripts is currently possible by downloading single or multiple scripts into a JSON file and sharing with another Cloud Scripts user by the easiest means.

Although this is good for single users, for larger teams and larger agencies they prefer to have a single account manager.

The next task is to introduce a sharing panel to allow admin-level users to share and publish scripts globally with their teams. This will be housed in the advanced settings modal.

Adding more triggers

As of now script triggering is limited to clicking or scripts, Terminal entries, and Terminal responses.

Additional triggers will need to be added to allow scripts to be triggered off of button clicks, search responses, and results.

External user testing

The next step for testing is to involve external users. These users will be selected from the existing pool that participated in previous discovery research on automation and scripting.

These users have been granted access to Cloud scripts, along with a user guide to familiarize themselves with the tool prior to testing. Initial feedback has been positive.

Next project

Page updated

Google Sites

Report abuse