Bot Framework Composer

Organization : Microsoft FUSE Lab
Time : May. 2019 -
Project Team : Sangwoo Han (Lead Designer)

1. Project goal

Bot Framework Composer is an open-source, integrated development tool for developers and multi-disciplinary teams to build bots and conversational experiences with the Bot Framework SDK .

Composer consists of largely three parts;

Conversation flow designer : Users can visually author conversation flows on the flow editor.
Language understanding : Users can author training data for Natural Language Understanding(NLU) machine learning models in the context.
Language generation : Users can author bot’s dynamic responses with Language generation markdown.

On the highest level, the Composer project’s design goals are

Deliver integrated, visual coding tool for developer audience to unlock the full potential of Bot Framework SDK, lower the learning curve, and fasten the development process that was unable when developers only work with raw codes.
Design for a none-developer audience so that content writers and conversation designers can also be part of the bot development process more inclusively. This would allow a multi-disciplinary team to collaborate more effectively.

2. User research

In collaboration with Blink, we had conducted user research sessions that include all the possible stakeholders in bot development teams. Due to the fact the field is still young from the product development point of view, there is no standardized team compositions or development processes. In that sense, we focused more on team members’ capabilities, responsibilities and tasks rather than their job titles

P0 user - developers : Capable of learning new SDKs and apply them to create fully implemented bot applications.
P1 user - conversation designer : Capable of learning new software development tools and use them to design the end-user experience(bot dialog logics, bot responses, and NLU models).
P2 user - content writers : Capable of writing bot dialogs and scenarios that serve end-user, business, and product needs.

What cannot be stressed more is that these should be understood as more of roles that members of a bot development team play, rather than individual users. Some teams would have one individual playing all three roles while other teams could, or should get dedicated members for each role.

The following are selected case studies.

3. Case study - Application interaction model

Bot framework as a software stack was designed with a specific idea; adaptive dialog.

Adaptive dialog consists of roughly three key elements.

Dialogs : A dialog is the centerpiece of adaptive dialog. When it is called, it takes over the current context and has ‘triggers’ that belong to it ready.
Triggers : A trigger a sub-element of a dialog that can be activated by various conditions. One of the major purposes is to recognize user’s inputs, and fire action nodes attached to it to deliver conversation logics.
Action nodes : Action nodes are atoms of conversation logic. A conversation flow created with action nodes is attached to a trigger and gets started by the trigger activation.

Since these are software design concepts, they are not necessarily intuitive tools to design conversation. While Composer’s main audience is still bot developers, it is critical for the design team to consider how this tool can be a platform for a collaboration amongst developers, writers, and designers to serve the multidisciplinary nature of bot building. Another aspect that played a huge role is that fact that Composer is a web app that is meant to be customized by customers to meet their needs. Therefore the interaction model had to be nailing down key technical concepts of adaptive dialog as well as providing room for scaling.

4. Case study - Action node design

Action nodes are elements that a user would put together in order to create conversation flows in the visual editor.

The main design goals were the followings.

Readability : Users should be able to scan the visual editor quickly in order to get information needed to take further actions. For example, a prompt node not only has to display key information but also indicate how the node behaves, so that it becomes a readable logic flow when it is put together with other action nodes. The concept of readability would have different meanings for each role personas.
Scalability : A design system for the action nodes should be scalable but in a rather specific sense. Because of the fact that 1) Composer is a ‘shell’ on Bot framework SDK which means it is fundamentally a raw code 2) Composer is meant to be customized by users to serve their own product development needs, the design system needs to be extremely simple but with strongly guided. In that way, the system wouldn’t break with complicated code expression, as well as could be used as a guideline to design your own action nodes.

5. The current state

Bot framework Composer is still in the public beta stage, and it is being used by selected internal teams actively. We are working to meet our UX quality standards towards the official release at BUILD 20’ in May 2020.