Improving Query Builder Error Notifications (Part I)

Queries are without any doubt the starting point of social media monitoring. Furthermore, we have the widest range of Boolean operators of any platform on the market to allow our users to get the most refined, accurate and useful data possible – and recently we introduced new cool operators too.

Yes, we love Queries, but we are aware that sometimes writing them can be tricky. For this reason we introduced syntax highlighting two years ago, and with the new Query builder we’re proud to announce a new Query validation system to make Query writing the best possible experience. This is what this post is all about.

Analyzing the experience

The redesign of the new Query validation system began with the analysis of the previous user experience. We started by mapping the experience, putting ourselves in the users' shoes and visualizing the journey that our users go through when they write a Query.

This helped us determine the points of failure (pain points) in the previous validation process and answer some questions: what does the user face when creating and testing a new Query? How is their workflow? How do they fix errors in a Query definition?

What we discovered at the end was quite interesting. The Query validation process had several pain points:

  • users had difficulties to find out where errors were, thus wasting time in long quests for the errors’ origins
  • users had to face a lengthy validation process as they had to test their Query definition repeatedly in order to fix all the errors
  • the presence of generic errors (e.g. “Your search definition is not valid.”) was not helpful in solving their issue

Rethinking the experience

After analyzing what we discovered it was time to start thinking about what features could be put in place to achieve our goal of providing our users with an effective and helpful Query validation.

Therefore we started a brainstorming session in order to transform the pain points into magic points, thus removing user frustrations. At the end of the process we started mapping the new experience we imagined using another journey map.

The new experience we imagined was faster and more effective than the previous one.
We addressed the most important pain points and transformed them into possible magic points:

  • the validation process is quicker than before because the system can trigger more than one error at a time
  • highlighting error regions helps users easily spot the most important errors after testing their Query
  • more specific errors can help users better identify the problems
  • more effective and clearer error messages suggest to users how to fix their errors

Embarking on a long journey

We started by creating a massive spreadsheet listing all the errors triggered by the previous validation system.

The goal was clear:

  • improving the error notification messages for the existing errors in order to provide users with more clues as to how to quickly fix the issues
  • reducing generic errors thus making them more specific

We then:

  • put all the existing errors in two different categories (errors and warnings) according to their impact on Query validation
  • defined new more specific and helpful errors cases from the generic ones (we’ve gone from around 20 to over 60 different new messages)
  • prioritised which error cases to tackle, according to their importance and impact on Query validation

Our journey was not complete yet…

After understanding the user needs and ideating a new validation experience we started to prototype our solutions in order to test them with users and improve them throughout the development process. Find out how we went about this in Improving Query builder Error Notifications (Part II).

Usability testing and user surveys have provided us with valuable insights into the users’ behaviour.