Node Search

Led the design to easily find and edit nodes to build an awesome chatbot

Context

Instabot’s chatbot is made up of nodes. You can think of nodes as a LEGO block, each node with a unique ability (e.g. allowing multiple choices), that when combined a certain way forms the actual chatbot experience. Because not all chatbots are the same, this means that a bot can have twenty something nodes to hundreds of nodes depending on its complexity. To help a user keep track, find, and edit a particular node pre- and post-launch of a chatbot quickly became the biggest challenge. If successfully solved, users will save time on locating nodes which leads to a more enjoyable overall bot-building experience.

After I consulted with the Sales team and Product team for the essential requirements, I experimented with possible solutions, and designed a “map-like” search function for finding nodes that’s intuitive, contextual, and easy to use for Instabot’s average user/internal team.

My role was to ideate on several solutions, produce hi-fi clickable prototype, revise designs based on feedback, and deliver the final assets/specs for the engineering team.

Process

Building on the requirements arising from customers-sales conversations and supported by qualitative research/Fullstory recording sessions. Here are the common complaints:

1. “Finding a specific node with very similar names is very hard.”

2. “Sometimes I only remember the content, don’t remember the position.”

To better help the team focus on possible solutions, I defined the problem statement to be: How might we make finding and editing a particular node easier?

Once the team agreed, I created wireframes to explore design alternatives. I created three alternative designs for a search tool. Each option has its own pros/cons. To decide between design alternatives, I conducted heuristic evaluations of the three designs.

Option C - MAP was the strongest solution in my option as it gives context of search, establish clear relationships to one another, and show coarse and fine results. But to really get a sense of how the “Google Map”-like search tool will behave as it has a lot of moving parts, I’ve created wireframes and designed a hi-fi clickable prototype.

I allowed the product managers, sales team, and developers to play around with the clickable prototype to see if the solution was viable or not. Feedback was very positive and supported my design decisions. They were most vocal about copy changes and the transition screens between clicking search and display of results. I then made the necessary changes and handed off designs to the development team.

Reflection

To recap, the team and I needed to come up with a way to help the user find and edit a node that's as quick and frictionless as possible. I overcame this problem by getting initial direction from users and the sales team, designing possible solutions, and producing hi-fi prototype that was tested by users that validated the design.

Since the new search tool release, the platform saw the Search button’s click rate increased steadily from initial release which means users were interested. This was further supported when I analyzed the average user-session — it dropped from 60 minutes to 45 minutes (a user just gained 15 irreplaceable minutes)! Furthermore, when reviewing 20 FullStory sessions, I saw a 40% drop between this flow (editing > preview > save) compared to a prior build by users which indicates they are more confident in addressing the correct node. All the signs indicate the new search tool was a hit with our users.

The next steps to elevate this solution are to work with the Marketing team to fine tune copy to address clarity, provide better out of the box search terms, and have filters.

Special shoutout to Jimmy Ng (technical product manager), I wouldn’t have arrived at final solution without his patience and guidance answering my frequent questions about designs’ technical feasibility, usability, and usefulness.