Menu ↑
Sander van der WoudeSenior Product Designer
Menu ↑
Sander van der WoudeSenior Product Designer
Senior Product Designer at MessageBird↗
Previously at Blendle, IENS, Mediamatic.
Project information
2017 – now
My role:
Sole designer for the first 3 years from its inception. Later joined by two other product designers taking it to the next level.
In the past 5 years it grew from allowing to build simple SMS or phone menu flows, to offering a wide arrange of rich communication channels, smart Machine Learning features, database management, test and debugging, extensive logs, heatmap analytics, employing custom functions, and much more. It's powerful as a tool, but also as an enabler of sales for MessageBird as it can provide custom solutions for its customers.
Snippet from a promotional video created for Flow Builder in 2018 by Devon Moodley.
From the start, MessageBird provided a fast and reliable way of sending SMS and Voice through their APIs. However, this was out of reach for our less technical users. We needed to open up these powerful APIs to those users too by providing them with an easy-to-use graphical interface in our dashboard. With drag-and-drop interactions, they would be able to connect channels with actions and for example build: chatbots, phone menus, automated reminders/notifications, support flows, conversational UIs, etc.
We weren't the only ones doing this at the time. Competitors like Twilio and Intercom were coming up with their own tool to allow users to automate their communication in a simpler less technical way. There were big differences in the way everyone approached it. Twilio went for a complete free-form builder with their Studio tool, while Intercom went for a real rigid form-based approach with their chatbot builder. We wanted to allow users to have freedom and access to all the powerful features, but still guide our users with a semi-rigid UI so the flow would resemble more of a tree structure and not become a tangled mess.
In the first version, we went for a very linear approach. It was almost like building your own form with collapsable cards. To configure a step, clicking on it would open the card and allow the user to configure the step.
Version 1 of the Flow Builder UI.
It worked very well. It was easy to understand and use. However, we soon discovered that it didn't work for more complex flows that wanted to branch and nest a lot. For that, it needed a more tree-like structure. So we quickly iterated and shipped Version 2 after that.
We quickly realized that we needed to go for a leaner tree-like structure to be more suitable for branching. We didn't allow for total free form, but steps would be placed on a grid so the lines wouldn't tangle and the flow structure would be easily readable. Configuration now needed to happen in a panel sliding in from the side, keeping a clear vision of the flow.
The configuration panel in Flow Builder.
This new UI provided us the scalability we needed to quickly add new functionality and allow users to build bigger and more complex flows without losing a clear overview of what they build.
Second iteration of the Flow Builder UI.
The configuration panel in Flow Builder.
Besides these improvements in the Builder part of the tool, we also added more functionalities for the user to improve their experience. A logs page per flow to see every invocation of the flow
Architecture and user flows inside Flow Builder.
An important part of Flow Builder is being able to accept and generate data that can be used and manipulated throughout the flow. This variable data needs to be presented in a user friendly manner. Naming should be clear and adding variables to steps should be intuitive, while still allow for complexity like variable objects and custom variables from external sources.
Variable objects and their behavior in the UI.
In Flow Builder, every added Step is a use case in itself. It required complex configuring in a limited standardized way. At the start, the tool only had around 10 available steps, while it has an impressive 60+ now.
Step icons. Almost all were designed by me.
Once a Flow is live and running, users want to see how it performs. In the Logs view, they can monitor every invocation, and how every invocation performed. If the Flow is failing, they can see what happened and debug the flow. Lately, advanced filtering options have been added to make this even more powerful.
The current view of the Flow Builder Logs, including advanced filtering options.
While the Logs page gives you a good view of how every single invocation performed, we lacked a more visual way of presenting how traffic is flowing through a flow. What are potential bottlenecks? In a phone menu, what option is chosen most often? What step fails the most? For these questions, we developed a Heatmap view of the flow, with advanced filtering and even the option to view live data.
Heatmap view of the flow. We stay true to the tree structure the user is familiar with in the Builder. Color blobs around the branches indicate higher or lower traffic, but of course, accompanied by labels and exact data.
We noticed some hesitation from our users to publish flows without the ability to test them. Especially with SMS or Voice where you have to pay for usage, you don't want to put something live that can break easily or will cost you a lot of money to just test and debug a flow. This is why we designed a Simulator where we can simulate moving through a flow as if it were live. Of course, not everything will work, but will give many users more peace of mind publishing their flow after testing.
When simulating a flow, we will move through the flow, showing the user at what stage in the flow they are.
While it was already possible to set variables within a single invocation or add a row to a Google Sheet, some customers needed a way to store and fetch data from a single source that could come from multiple invocations. That's why we build database functionality inside Flow Builder. Users can create multiple databases and use steps inside Flow Builder to create, read, update and delete data. It is a simple Key-value database that also accepts variable objects. To adhere to data protection laws like GDPR there were also data retention settings that could be customized.
The current view of the Flow Builder Logs, including advanced filtering options.
We often had interviews with customers or our own Sales Engineers, who were true power users of Flow Builder. Sometimes the interviews were more about inquiring how they though about the tool, their needs, wants, roadblocks, etc. But many times it was a great way to test new features and show designs in an early stage to get feedback that we could incorporate before shipping.
During the pandemic (2020-2022) all these user interviews were done through video calls.
We would record and document these interviews in Dovetail, which is a great tool for transcribing these interviews and tag quotes to categorize them. Next to interviews we would also regularly check user data in Mode, and continously run NPS surveys on the platform. The latest addition to our toolkit was a tool where we would publish about new features shipped, upcoming features that were on our roadmap, and allow users to request features and upvote them.
Working with the Design Team in 2019.