Bloombot

OVERVIEW

Project Brief

Bloombot was a Robotic Process Automation(RPA) integrated development environment (IDE) to build automation solutions, based on Python libraries.

The problem

In the RPA industry, interfaces are usually based on functional blocks with defined functions. Generally, those who use these tools are developers, and this is not really the most natural way to code.

The Goal

Build an IDE for the RPA sector that feels like coding in Python.

PROTOTYPE

Meeting the pain points

To better familiarize myself with the product and industry, I conducted some market research of my own. I prepared a benchmark for the features of the product competitors. Also, I prepared an informal destructured interview with two usual developers of RPA software. The objective was to know the pain points and the desires of the users. I ask to the team for a demo of any simple task, this helped me to understand their workflow better.

What I found was that the use of functional blocks involves pains like learning to use it, being restricted to the limitations of the blocks and the interfaces usually are very poor in terms of debugging.

DEFINE

Aligning: concepts, users, business...

The idea was defined at a functional and business level, however, it was not possible to convey what the purpose was and focus on what specific problems they wanted to solve with the MVP features. To align business goals with the needs of our users, use the Scope Canvas. This tool allowed us to define how we would measure the success of the product and give a sense to what we wanted to build, simply, an RPA tool for devs designed for devs.

DEFINE

Defining the MVP

The functions within the RPA tools are very varied, broad, and diverse, so it was necessary to prioritize which functions would be developed for the MVP. For this point I implemented a ux session with the development team, on one side the team that was going to develop the program and on the other side, the potential users of it.

Initially, it was explained that the objective of the activity was to determine which would be the prioritized functionalities for the MVP, so we first needed to do an exercise: in a period of 5 minutes, write on the board what they thought were the basic functions that it should have an RPA program. Subsequently, we reviewed each of the ideas, grouped them the most similar and understood, and then dedicated some time to explain the not-so-obvious. With this, we come to 5 great features:

• The functions must be built based on full abstraction and with global scope, to allow the users to use it as Lego and communicate between them.

• Debugger really may help to understand what's going on, at least which files are falling.

• UI is as clean and functional as possible, its object is to improve the coder's work.

• The RPA functions to be prioritized for development will be related to the web and Excel activities.

To define the functions and tasks within a specific context, we used a prioritization matrix. Our axes were based on the number of people using a particular function and how frequently it was used. With this matrix, we determined that the initial scope of task tools would focus on web and Excel automation tasks.

What everybody wanted... the UI

With the features defined and already prioritized, the interface design process was simplified. I focused on providing the most natural experience by focusing on 4 big blocks:

• Code editor, the place where the magic happens. For the first instance, consider using line numbering and linter integration.

• RPA tools, here the tools related to importing prebuilt functions will coexist through abstractions based on the web and Excel categories.

• Toolbar with three buttons for code execution, launching the automation created, and opening the console.

• File/Dependency Browser to view automation-related files and built-in functions(dependencies) for their operation.

• Console, especially needed for debugging.

Key Learnings

This project represented a big challenge to me, initially, everybody was talking about the architecture, the abstractions, and the functions, but nobody was talking about the product and how it will impact the users. Wear the hat of UX and also frontend dev, allowing me to lead the process to build an MVP and spread the problem to solve to the devs, first then the solution. This was my first experience designing a product and leading a team.