Otomatis by Bahasa.ai. —a comprehensive study case

Designing an automation platform to help Indonesians move data faster in their daily used apps.

1. Early context
2. Design process
3. Reflection and learnings

UX design (prototyping)
UI design
Evaluative research

Key results

Early Clients/Partners bought in with the idea and willing to utilize Otomatis.
They even help promote & resell the product to their customers
Add more revenue streams to Bahasa.ai
A million incremental tasks used monthly. Showing that our early adopters truly utilize our product solution.

Early Context of the Project

Started in 2021

Bahasa.ai is renowned for its chatbot business, providing valuable solutions to esteemed companies in Indonesia. In the chatbot domain, we leverage our clients' APIs to craft tailored solutions. While maintaining focus on this successful venture, Bahasa.ai initiated the Otomatis Project to further fortify our business operations.

The initial concept behind Otomatis was to enhance the management and utilization of our Clients/Partners' APIs. We began by modularizing client HTTP requests (GET/POST/PUT/PATCH/DELETE), allowing us to effortlessly select and configure modules—later named triggers and actions—via a simple, code-free form.

Otomatis evolved into a standalone product, functioning as an iPaaS (Integration Platform as a Service).

"Otomatis aims to maximize the potential of our partners' features and business use cases by seamlessly connecting them to a myriad of open APIs already modularized within Otomatis.

Otomatis will cut the cost of integration-engineers that usually dedicate hours of work just to enable a single integration. With Otomatis, we want to create an integration-builder that is code-free and can be built by anyone easily."

Example of how Otomatis enables an integration

How Otomatis will work?

To help you understand the idea better

Otomatis will connect an application’s APIs into a useful integration that can help optimize and automate business processes. Thus, users can reduce repetitive tasks, and allocate more efforts to focus on other important matters.

Otomatis will need 3 components to create an integration/scenario:

An Application
Representation of an Online/SaaS application that is integrated on Otomatis.
A Trigger
A component of the application that is activated by any invoked events.
Action/Actions
Components of the application that receive a request to alter/fetch data.

"We believe that Otomatis must be rich with integrated-apps and modularized trigger/actions, so it can become more relevant to users. Also, it needs to be highly usable by offering flexibility and simplicity at the same time."

Design case

Portraying the Product Idea into a Convincing Prototype to win early Adopters or Resellers.

To ensure that we're addressing the right problems, we designed our process around regular cycles of prototyping and product pitching/demo to our partners, validating the idea to see if they bought-in with the ideas.

Our starting point was to create a demo that shows how Otomatis can help their business.

Design Process

1. Emphatize

Research

To better understand the ideas, benchmarking was done to define our target users, and comprehend them better. So, I started by conducting a research with the following goals:

Research Goals

Identify similar apps outside of Indonesia, and evaluate their strength and weaknesses.
Understand Otomatis' target users and their experiences on doing daily repetitive tasks.
Discover goals, needs, motivations, and frustrations of their daily routine doing work chores.

A. UX Benchmarking

First, to gather all inspirations/insights, I analysed similar apps outside of Indonesia (the idea is relatively new in Indonesia). This helped me to understand how the existing apps are built, and how they differ with each other.

This research plays an important role to determine the approach that will be most relatable to our segments. I found that the difference could easily be seen by how the product communicates through features, copywriting, and the level of difficulty in building integrations that are suitable for their target users.

B. Provisional Personas

Now that I had a better understanding of how similar apps communicate to each of their target users, I wanted to discover our potential target users to determine their needs, so the design could be built according to the target users.

The personas were created after rounds of interviews and meetings with potential clients. I started to notice a pattern in the goals and challenges that could be addressed through Otomatis. By creating a provisional persona, I could emphatise better, then start discovering sample use cases and how the product can communicate faster.

C. User Interview

Alongside the persona we decided, I want to learn more about our target users' real day-to-day operations. What could be improved, what tasks were actually repetitive and should be automated, how they're dealing with a redundant business process, etc.

In this process, the higher management would usually had already started an initial pitch with potential clients, then I would do further explorations to discover whether their needs could be productised with Otomatis.
‍
I also initiated some interviews by asking open-ended questions to learn how our target users operate and run their business daily. One of them actually already used a similar app outside of Indonesia. It helped me to better explore how they utilize the app, and what is considered valuable so that they are willing to pay monthly to use it.

Insights

They actually do repetitive tasks that can be automated
We understand our target users' tech-savviness to help adjust the level of difficulty of our product
Similar platforms that already exist do not have Indonesian apps that are available to be integrated

Needs

To be able to focus on other tasks/works that actually matter more
To be able to easily create intermediate level automations/integrations
To be able to integrate apps that are often used in Indonesia

Above is an image of an integration sample, created by our interview participant in Integromat. He used a lot of modules and integrations, but none of them provide any relatable Indonesian apps.

2. Define & Ideate

Which problems are we trying to solve?

Now that I understood which target users Otomatis is most suitable for, also that I understood what are their goals, needs, and frustrations, I tried to define and ideate how the product will help them. From what I already acknowledged, I started to create several action items to create our first product prototype/demo.

Ideation Action Items

Formulate a HMW Solution based on our user's POV to better understand them

Uncover all possible solutions based on a feasibility analysis and what are needed by our early clients

Select 1-3 integration solutions and understand the benefits that Otomatis can offer

Create a user flow (happy path) to create an integration in Otomatis. Reflecting to our target user's capability

A. Defining Use Case

To build the integrations that are needed by our client, I need to check if the integrations can be built by Otomatis. I had to do a feasibility analysis and see which integrations are possible.

I searched lots of official API documentations that are available to be accessed on the internet. Here is the example of Tokopedia's documentation guide: https://developer.tokopedia.com/openapi/guide/#/

From that documentation, I tried to understand what was feasible to be modularized and started to list down all use cases for Marketplace Seller.‍

1. Brainstorming

I started the brainstorming process with pouring out all ideas while looking at the API documentation. I poured out all ideas as fast as possible while looking at specific use cases that are requested by our prospects.

2. Affinity Map

After all ideas were poured out, I started to do a grouping to categorize the use cases/integrations. The categorization shows that every Marketplace Seller has main functions from operation, marketing, and accounting.

3. Define three sample use cases to be built for Demo

I was able to identify common patterns/functions that are going to help Marketplace Seller to do their job more effectively.

Of all that are listed in each of the three categories, I selected one of them. The decision was based on:
‍
1. Feasibility Analysis
2. Suitability to our Prospects / Target Users
3. The difficulty level of the Scenario Set Up

Marketing Automation
An Automation that helps Marketplace Seller to market their product more effectively.

Example:
Auto add new customers from transactions to Mailchimp lists

Operation automation
An Automation that helps Marketplace Seller to manage their product more effectively

Example:
Auto update stocks in ERP App whenever there's a transaction

Accounting Automation
An Automation that helps Marketplace Seller to record financial transactions pertaining to their business

Example:
Auto create Sales Order in their ERP System when there's a new paid order.

B. Create User Flow

To be able to build those three integrations that I had selected, I needed to start creating an overall user journey. I wanted the users to be able to create their own scenarios, and even more can build their own automation outside of the use cases that I proposed.

The goal of this product is to enable users to create integrations that are flexible, in the most simple way.

C. Low-Fidelity Wireframe Sketches

Next, I started to visualize the idea using lo-fi wireframe sketches. Hence, I could picture how it would look on interactive UI.

I started to plan the information architecture/hierarchy based on the user flow that had been created before. Then, I built a step-by-step sketches that user needs to do to achieve their goal.

3. Prototype & Test

UI Design

Finally, I started to create the UI Design, so we could create the real integration or let our users try the prototype. After the UI Design is made, we can validate and test our idea.

A. High Fidelity Design

I created the UI designs using Figma, which was used as a guideline for engineers to start creating the MVP, so then we can actually start to build an integration.

B. Demo and Validate the Idea

After the UI design and MVP development was built, I created several demo videos to show to our prospects.

Here is one of them which shows that Otomatis can integrate Tokopedia chat and Shopee chat to Zendesk Support. (I recommend you to watch in 1,5x speed with closed caption for better experience)
‍

This video was re-shared by Zendesk Indonesia's Country Manager in his LinkedIn, as Otomatis has leveraged Zendesk Functions to be put in an integration with Tokopedia chat/Shopee chat.

Hopefully, this would encourage more prospects to get to know more of the idea and willing to try Otomatis.

Our other demo videos also obtained some nice reception from several SaaS businesses in Indonesia. We're currently exploring lots of applications, integrations, and use cases, so it would be more relatable to be utilized in Indonesia.

Reflection and Learnings

One of the most exciting things about building Otomatis is being able to experiment and take risks. The speed of the design delivery is important to quickly validate the idea.

I faced new challenges during this project that I haven’t faced before - creating a product to help integrate data between applications is quite complex. I have to understand the utilization of APIs and their functionality, also how to create a seamless experience that cuts most of the technical part when creating an integration/automation.

The next steps I would take this project through from here are:
1. Do lots of usability tests to our early adopters to gain more insights for the product
2. Continue with another feature like discovery of scenario template, to help user start the integration.
3. Continue to discover use cases/scenarios that will help Indonesian businesses to automate their repetitive tasks.