Senior Product Designer at MessageBird↗
Previously at Blendle, IENS, Mediamatic.
Design Sprint for the Inbox project at MessageBird
While the power users were our most demanding, most novice users came to build simple flows, most of the time only consist of a couple of steps. In order to help them we explored ways to help them build flows without ever seeing Flow Builder. Guiding them through a linear process, only asking them to input the necessary information, and not having to deal with adding the right elements in the right place or suffering from the blank canvas syndrome.
These solutions were supposed to tackle very specific problems. We saw the potential for e-commerce problems like recovering abandoned shopping carts, sending order confirmations, setting up an FAQ chatbot, etc. This way we could offer tailor-made integrations or setup guides for popular e-commerce platforms like Shopify and WooCommerce.
We started with analyzing the usage data of Flow Builder and discovered that the majority of flows created only consisted of a couple of steps. Many times also solving only a set of specific problems.
Throughout the years we also got feedback multiple times, from less technical users, that Flow Builder was hard to use. There are some fundamental technical principles in there that are hard to grasp sometimes for our novice users.
All this combined, made us explore ways to let our users build automation in other ways.
For this feature we set ourselves some requirements:
With these requirements in mind, we stayed in the wireframe and whiteboard stage as long as possible. This forced us to focus on flow and think out a simple and scalable flow for the underlying complex process. Because while the Solutions are meant to be compact, easy, and simple, the technical side that we are trying to hide really isn’t.
For example, the first Solution that we were building was to recover abandoned carts on e-commerce platforms. Customers put items in their cart and then leave the site, leaving behind potential sales for these shops. With this Solution, they could remind their customers of those items, and even offer them a discount to make them return and finalize the purchase.
The challenges here are:
These challenges turned out to be hard from a technical, UX, but also legal standpoint. This project was very much a juggle between technical limitations, legal roadblocks, and still staying true to the requirements we set for ourselves.
After spending countless hours around whiteboards, at times together with the entire product team to get a complete picture of limitations and requirements, we moved over to scoping out definite user flows and turning them into wireframes.
User flow of the Abandoned Cart Recovery Solution.
Wireframe designs of the Abandoned Cart Recovery Solution.
Unfortunately, a big roadblock that we faced soon was that getting a simple integration with Shopify was out of the question due to legal reasons. So, while step 1 initially would have been super simple, we now needed to guide the user to establish a webhook connection. Here the hand-holding really started and writing good copy was essential. Writing out every action, navigating the user through the settings of another platform was challenging.
Guiding the user in every step of the way to connect their store by setting up webhooks.
Logs page to see how the Solution is performing once published.
Even with the many hurdles that we faced, I think we were able to stay focussed on the principles we set out for ourselves making Solutions fool-proof, and scalable, all while solving specific problems.
We provided the user with a clear linear path consisting of a couple of steps that we outline from the start. This "progress bar" is visible throughout the entire setup so the user knows exactly at what stage of the process they are, what is happening there, and what's to come. This four-step progress bar is applicable to all future solutions, which makes it scalable for building, and recognizable for the user.
With the progress bar on top, users know exactly where they came from, where they are in the process, and where they're going. No surprises.
Every page would start with a introduction helping the user understand its purpose, what's in it for the user, and how to do it.
Users want to know why they need to do certain tasks. Writing a little introduction will help them every time.
The CTAs leaves no room for uncertainty or surprise. The user knows exactly where they will go when clicking on either button at the bottom of the page.
Clear copy for the CTAs. Again, no surprises for the user.
We give users ways to help them out when they're stuck. Either by allowing them to read about it in the documentation and get the most out of it. Or throwing them a lifeline and let them speak to a professional to guide them.
Give the user handles, lifelines, and a manual to help them reach their goals.
In the end, we are very proud of the work and process we accomplished in this project. We had a thorough design collaboration with the product manager and the rest of the team. The scalability and accessibilty that was built in from the start, the simple UI, and all the research that went into it, were all really good practices.
Illustrations for cards presenting the Solutions: Abandoned Cart Recovery, FAQ Bot, Order Confirmation.
Presenting the wireframe designs to the rest of the team early in the process to gather feedback on technical feasibility.
Unfortunately, Solutions didn't become a big success in terms of sales and revenue. I think this had a lot of potential to become a success and grow to offer many more Solutions to our customers. However, some things you can't control: