Hey there. Since my first post on Twilio Hackathon, I've made some good progress. In this post, I'm going to go over user flow design and how I used Studio Flow to stitch my to-do list textbot together.

User flow challenges

The biggest challenge of the textbot is having multiple trigger words to take users into different paths. After watching some Studio Flow tutorials, I embarked on the user journey. I started with a simple path to sign-up users. It quickly got complicated as I added more commands for the bot.

As an overview, these are the commands that I planned for this hackathon:

• "hi" - sign up
• "add item" - add an item to list. If list doesn't exist, create one.
• "remove item" - remove item by name or number
• "show items" - show all items in list

User Flow v1

To give you an idea how I thought through the process, here's a first version.

Each green box is one Studio Flow, and each Flow calls the corresponding API to manage the list. This design decouples the "bot" and the backend, so the Rails app is simply an API that handles requests and backend. Simple enough. I went to work and discovered a few challenges/learnings.

• While technically, I can just create a single big Flow that covers all the conditions/branching, I chose a design where each Flow is decoupled and modularized. No monolithic design!
• To connect the Flows, I wrongly assumed that a single phone number can associate to multiple Flows. I had thought that when a user texts the phone number, every Flow will evaluate the trigger words and go down the corresponding Flow when triggers match. Thinking back now, it makes total sense that one phone number can only trigger one Flow. Here's more details about this topic.
• Learnings: I needed something that parses all the commands, and then trigger "sub-Flows".

User flow v2

• Here, a Flow process commands, and triggers other nested Flows based on string condition. A Flow can be triggered via Studio Flow REST API and from another Flow, which helps.
• Pros: Single point of entry for SMS.
• Cons: I wasn't satisfied with the split-based-on widget. While string parsing with Regex is enough to parse most text, but building more than a "Yes"/"No" condition, it quickly gets complicated and becomes difficult to manage (like this example). A case statement is much easier to code and manage, especially when there are nested conditions.
• Learnings: While everything kind of works, I found that it was difficult to overcome the lack of control, the unwieldiness of the Flows, and the limitation on debugging. I decided to bring the "command parsing" into code.

User flow v3

• Blue box is the Rails app, green boxes are Flows. Here, I'm leveraging a Flow to listen to SMS to trigger and sign up. I could have combined both sign-up and trigger into my app, but the main reason they're in a Flow is because I love using Send & Wait Reply Widget, which will take some work to build manually.
• Caveat: While using Send & Wait Reply Widget, if the Flow is triggered via Studio Flow REST API, the "wait" part doesn't respond to the user's text. Not sure if it's a bug or by design, but that's the main reason why this Flow is triggered by text in this design, not by my app.
• Leveraging my app to process all the commands. This enables me to use all kinds of string manipulation and case statements, and allows me to use Studio Flow REST API to tigger corresponding Flow.

Conclusion - Think like Lego Master Builder

Studio Flow is awesome. It's great for anyone, technical or not, to quickly build a chatbot. With the rise of low/no-code development, it's definitely going to gain more traction. The big plus here is allowing non-coders to build a simple bot, without bothering developers to build it. :)

However, Flow isn't like software development. If your bot features will grow and evolve over time, I recommend writing software rather than building Flows. Since I started using Studio Flow, I've learned to think of Flows as drag & drop AWS Lambda functions. They're very good at building point solutions, and need to be broken down into smaller and more manageable pieces.

As an example, I've been looking for ways to programmatically check in the Flows in source control, creating dev/prod Flows, and "migrating" them into production mode. Twilio's Studio REST API v2 will be interesting and might help close some of these gaps. During your development process, consider trade-offs between building software and creating Flows that cater towards your use cases.