Bringing conversational AI to the enterprise domain.
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?
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.
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.
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:
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.
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.
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:
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:
To further understand the complexities of a branching conversation, we wrote a dialog script using script writing tool.
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.
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.
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:
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.
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.
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.
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.
