Designing a chatbot platform

Bringing conversational AI to the enterprise domain.

My Role:

Lead a design team through this highly complex initiative to conceptualize, research, and design a web-based developer IDE that lets developers enable conversational features for SAP enterprise applications.


Conversational UX for enterprise products was a relatively new field in 2015. There were a lot of consumer-focused conversational platforms, but very few enterprise platforms. On the other hand, SAP needed its own platform as SAP customers would not like to transmit business-critical data to third-party platforms. This project was about defining- What an SAP specific conversational platform should be like?

Why was this important?
The Beginning
It all started when a small group of people became curious about how we can simplify enterprise information consumption less painful by using conversational applications. This need was identified when we heard this pain point from a lot of customers that our team was talking to. They all were saying that even for simple tasks like applying for a leave (shown on the right) or checking if the invoice has been paid, one has to navigate complex screens.

While on the other side, a lot of consumer apps were utilizing conversational features to simplify data consumption.

Since this was a totally new domain for all of us, we started by studying the landscape of bot tools that exist out there. We looked at all these tools and studied what they can and cannot do.

The tools above allowed people to create static chatbots (some had dynamic content features, but not a lot). As a next step, we started looking at more mature and comprehensive bot frameworks:

We did a detailed analysis of these tools to understand how the conversational platforms work. We specifically noted down the things which were missing from the enterprise platform perspective. We did this exercise to make sure that we are not trying to re-create something that has already been solved.The image below shows the analysis boards.

Starting big


Once we had validated that the existing tools and frameworks will not be able to solve SAP enterprise specific problems, we embarked on a mission to create a framework grounds-up.

The team agreed that we need to begin with a broad vision and then work our way to refine and fine tune it as we build things and talk to users.

To come up with a product vision for SAP conversational AI platform, the team conducted the following exercises:

- Competitive analysis of vision statements from indirect competitors and other companies.

- Brainstorm and synthesize the vision statement.

SAP CAI platform is a comprehensive bot building platform empowering SAP users to build and monitor bots for multiple channels.

It is seamlessly integrated with current SAP apps and systems that enables a flexible, collaborative experience for users to create chatbots to help run business fast and efficiently.

Having this vision statement gave us something to work with. Without this statement, we were shooting in the dark. Armed with this vision statement, our next task was to validate this statement.

We wanted to refine the vision statement and also understand user needs around conversational capabilities for enterprise applications. We set out to interview users and ask the following questions:

What is their vision of conversational AI platform for SAP?
How do they see themselves using such a platform (if available)?
What pain points will such a platform solve for them?
What steps do they envision for building chatbots?

During these interviews, we also asked them to draw, doodle, and sketch to make it easy for them to share their thoughts. We collected a lot of these ideas:


After talking to a lot of users, we sketched out a picture of the platform so we can not only understand all the parts of the system but also make it easy for any new team member to quickly understand what we are building. This helped a lot as the team grew exponentially and we added more designers and engineers to the team.


Since a lot of the parts of this conversational AI machine were technical in nature, we gathered a group of data scientists, engineers, designer, and product owner to come together and detail out parts of this machine.

- Entity Extraction
- Conversation Flow Builder
- Deployment
- Testing and Debugging
- Coding environment vs. Visual Tools
- Intent Matching

At the end of the workshop, we had multiple viewpoints of addressing each of the parts of the machine.

Design thinking workshop

Now that we had a good clarity on how we wanted to address each of the functions of the platform, the product owner started writing the use cases and our first sprint cycle was going to start shortly. I sat down with the product owner to understand the stories and saw that there were a lot of technical details in the stories which were not easy to understand.

We took those stories and tried to simplify them using storyboards (as shown below). These storyboards helped reduce the amount of time spent debating and estimating the stories during sprint planning.

Ideas to usecases
Understanding conversations

One of the most challenging parts of designing this platform was understanding and designing the visual conversation flows.

The problem with most of the existing frameworks is that it is really hard to design branching conversations. Most enterprise applications have some kind of business flow associated. For example:

Apply for leave:
- Employee creates leave request
- System checks balance
- Approves or Denies
- Approval sent to manager
- Manager approves
- Employee gets an email confirmation.

Now that might look like a simple flow, but there is more to it. At each of the steps, the system needs to do multiple things, For example:

When an employee submits the request:
- User may provide insufficient information.
- System may need to request additional information.
- System may need to disambiguate (eg. which kind of leave).
- System may need to do transformations (eg. calculate the number of days between given dates).  

Checking balance:
- System needs to make an API call and process the received results.  

Sending Approval request:
- System needs to first find out users manager.
- Then compose and send out an email.

To further understand the complexities of a branching conversation, we wrote a dialog script using script writing tool.

Writing conversation scripts

Using this script, we created an interaction flow diagram for this conversation. This gave us a good understanding of the branching conditions and how the users expect them to be handled.

From script to conversation flows

Defining linear conversations was easy. Creating branching conversations was challenging. 

So we focused first on getting this right. We quickly sketched out a concept based on the studies we had done so far. 

Each conversation starts with a node and the developer can then build the conversation based on what should happen next.

Building a dialog designer

As our users played with the first prototype, we realized that dialog designer is not as simple as it seemed. Our users were looking for:

  • How do we use variables in the responses? 
  • How do we define what the bot is expecting from the user? 
  • Is there a way to transform data before proceeding to the next node? 
  • How do you make API calls during the conversation before responding to the user?

To enable developers to design complex conversation flows, we added advanced functionalities to allow them to define variables and then let them apply transformations on top of these variables. 

Variables, Transformations, and APIs

Lessons learned


Throughout the project, I learned that when the team was faced with a really big challenge, everyone got confused, when we came together and broke the task into smaller chunks, we were able to achieve success faster. 

These quick wins also help boost the morale of the team and provides opportunity for frequent celebrations.

Quick Small Wins go a long way to the success of the project.

This project started with a small group of 5 people and grew to a 40+ member team. 

As a designer, I was constantly engaged in evangelizing design. Consistently involving engineers, data scientists, and product owners in the design process and user research helped "infuse" the design culture in the team. 

As a result, we were able to get one of the best idea from an engineer during this project.

Infused design vs. Embedded design

Most designers try to stay away from development tools. JIRA, Github, and other such tools are never in a designers workflow. 

I had used these tools many times before, but other designers on the team were very reluctant to bring these tools to the design workflow. 

Once we started using these tools, everyone realized that it's not such a bad idea to version control a sketch file or lookup tasks on JIRA.

JIRA, Github etc. may look complicated, but they are very useful