Product design — How we make complex tasks feel simple

Mastering the art of adding functionality without compromising usability

Product design sketches

A difficult aspect of interface design is making complex tasks feel simple and easy to do.

Often a task is conceptually simple, but the complexity comes from the implementation and edge cases. In this post I’m going to explore the process involved in adding more functionality to our filtering UI without compromising usability and the product decisions we had made before.

To give you some context, at GoSquared we offer the ability to see your users on a per-person level, and intelligently automate actions based on things they do throughout your site or app. The actions are linked up to people entering and exiting Smart Groups — a set of properties or events you filter your users by. When someone enters (matches) that filter, or when someone leaves (stops matching), an action is triggered. You can set up Smart Groups to do pretty powerful things like encouraging loyal and active users to upgrade their subscription.

filtering bar in GoSquared People

Previously, you could only construct filters using the AND operator (e.g. find all the people who are paying customers AND have logged in within the last 30 days AND have product emails enabled), however as we and our customers started using People more and more, we started feeling the need for building more advanced filters.

When filtering users, we found that often you’ll want to target different values for a property (e.g. users with their “location” set as “London”, “Paris” or “Berlin”), or want to target multiple behaviours at the same time (e.g. having multiple definitions of what an “active user” is). Only being able to build filters with AND operators became limiting, so we decided to add the ability to build filters with OR operators as well.

When talking to our customers, the reoccurring frustration with services offering similar functionality was being limited to the use of just one operator (either only AND operators or only OR operators). From a technical standpoint it’s not hard to filter with multiple operators; the difficulty is in creating a user interface that is easy to understand and use.

Design with real examples from the start

The first step in tackling the problem was to put together a list of filters that we and our customers wanted but were unable to use. Using real examples from the start of the design process is incredibly important as it forces you to design for the reality and not just what looks or works well. I often come across beautiful mockups of user interfaces that end up failing in the real world because they’ve used idealistic examples.

Josh Puckett wrote a fantastic article with his thoughts on bringing real data into your design tools, which I highly recommend reading: Modern Design Tools: Using Real Data

Getting your ideas onto paper quickly

The next stage in the process for us was getting as many ideas out of our heads without worrying too much about constraints or limitations. The goal here was to go through as many ideas as possible without getting attached to any single design. I personally like to sketch out variations quickly and get as much of what’s in my head on paper as soon as possible and then develop them later. This is a process to get lots of ideas you can develop and refer back to later, but done in a way that doesn’t require you to spend more than a few minutes on each variation — the longer you spend developing a single idea, the less likely you are to explore others.

Product design filter sketches

When deciding which variations are worthy of testing and developing, its often useful to reflect on what your current designs do well. When adding new functionality, it’s often difficult to maintain the simplicity and ease of use of what already exists. Think about how frustrating it is when a service you use adds a new feature but at the same time breaks something that previously worked well — it sucks. In our case, although the filters you could put together were limited, building them was an incredibly easy thing to do — it was just one button to add a new parameter to the filter. Another incredibly useful aspect was the results updating as you built your filter — you’re able to see how each piece of your filter affects the results, allowing you to spot mistakes in your logic sooner. Those were two really important features we knew we wanted to have continue through to our updated design.

Building prototypes for rapid iteration

Prototyping has always been an important stage in the design process and it often feels theres a new tool for creating prototypes every day. When deciding which tool to use, it’s important to know what you’re trying to prototype — is it the whole flow? Just the interaction? Something else? Different tools are better at different things. A good question to ask when evaluating tools is: which tool will help me iterate most quickly for what im trying to test? You want to choose a tool where you’ll be able to make changes easily, and quickly.

We went with simple HTML + jQuery + CSS instead of anything fancy. It’s quick to work with, doesn’t require learning any new tools, and by moving options into variables, is easily changeable. Additionally, we were only focused on interactions and less so about visuals — any visual cues we really needed were applied roughly in CSS, but otherwise just left as the browser default styles. For each prototype iteration we’d duplicate it before we make a change to give us an old copy to refer back to. Sometimes you’ll explore an idea and realise that wasn’t the right way to think about it; you can then go and take another direction from a previous version.

User testing internally and externally

Throughout the prototyping stage we’d ask other members of the GoSquared team to have a play around with the prototype and try to perform the real world tasks we collected at the start. During this, we’d observe how quickly they understood how to get started with the tasks, where they got stuck, and how they resolved any issues they came across. Interestingly when you have multiple tasks to perform, you can watch to see how the user goes about moving from one test to another. In this case, asking to build one filter and then another, provided the opportunity to see how people naturally go about editing and resetting their filters.

Prototype 1

In this prototype, parameters were added with the + button, which would AND it to the other parameters. When clicking on an “AND” it would switch to OR and create an OR group with the parameters either side. In practice this was not obvious and quite complicated on a conceptual level. From the user testing, we found that’s just not how people think about building their filters, but it was interesting to experiment with something quite different early on.

Prototype 2

A later prototype replaced the + button with an “AND” button and an “OR” button. Conceptually this was a lot easier to understand and matched up closely with how people went about trying to build filters. In this iteration, operators would be fixed for each group, so inside a group, all parameters must be ANDed together or ORed together. This fixed edge cases when trying to build more complicated filters, but at the expense of a more complicated and potentially confusing UI.

Prototype 3

A later prototype restricted ANDs to the root level, and ORs would be applied to groups. This restriction stopped some filters being able to be built, but improved the mental model of how the UI worked removing all the confusion we’d seen in our previous internal user tests.

After the bulk of the prototyped design was built, we tested with people outside the company to again gauge people’s understanding of the interface. You can share a few variants of the prototypes you’ve been working on and see if anything works better in one than another. If you’ve built your prototype to be easily modified, you’re also able to make quick changes and see how those perform. It’s important to remember though, that those changes should also then be tested with many other people; what works for one person might not make sense to everyone else.

Tidying visuals

Final Filter UI - how we made complex tasks simple

After we were happy with the interaction design and confident that the metaphors used made sense, we finished up by tidying the visual design. This stage is all about making it fit in visually with everything that surrounds it, make it look polished and make sure the metaphors are visually communicated effectively. One of our challenges was communicating grouped sections effectively. The way you think about grouped sections in mathematics is to use brackets, so we decided to build on that idea. Every new parameter added is either added to an existing group, or its own group, and that’s indicated by a darker blue bubble.

Keep it simple

The new filtering interface in GoSquared has been available for our users for a few weeks now, and so far the feedback has been great.

We methodically followed a design process that used real examples from the start through to the end and explored as many ideas as possible, from as early as possible to ensure we didn’t become falsely attached to one single approach.

When building and testing prototypes, focus on the core user interaction first and visuals after. Good visual design highlights actionable areas in the design and is an important aspect in the design process, however is secondary to good user interaction and conveying a solid mental model of how the interface works.

This is just a brief look at process behind one of the many ways we focus on making complex tasks feel simple at GoSquared. If you have any thoughts on the design process or the final outcome, let me know in the comments below!

Subscribe to the GoSquared newsletter.

Join 15,000 people. Get our latest posts delivered to your inbox every week.

  • Peter Zalman

    Thanks for sharing!

    Your design process seems very well thought. I saw very similar pattern in one of my company products and to be honest, never liked both using it, and giving design feedback to it.

    I don’t understand all your design constraints, but here are few points that I did not like on that solution:

    _You are building coloured UI with boxes and buttons around the textual definition that you can express just with text and operators. Everyone who understands how the operators works would understand simplest possible representation. And the simplest possible representation of this UI is textbox with:

    (ConditionA AND ConditionB) OR ConditionC

    Any UI on top of it feels like unnecessary chrome. What is faster – figuring out what a button does, target the mouse towards a small target (Fitts law) and clicking that button, or type TWO letters using keyboard to type “OR”. Even from your work in progress wireframes, I see that you are adding rectangles and user interface around the content, that is already complete.

    You can do magic with the typography, contrast (syntax highlighting) and autocomplete or IntelliSense.

    _You are essentially designing list that is stacked vertically. What will happen when the screen width will get smaller, and smaller? You will stack the conditions rows bellow. But from that moment, it is not so obvious that it is not array, but separate conditions rows. The orphan “AND” button will add the condition to that line where it is located, or to the line bellow? Then why it is not in the row where it adds the data? You also needed to add special boxes around the rows to make it obvious that it is not an array. Another visual chrome, making the whole component 300% larger than a simple textbox.

    Google Analytics has this nicely sorted out in Segments definition. It is a list, so it is always sorted vertically.

    Again, thanks for sharing, you did an amazing job with the whole design process. I am not the smart guy who knows better, I have no idea about your target audience. They might prefer mouse input without even touching the keyboard, which is different to Enterprise and professional apps environment where I am working in. I just wanted to share my design feedback 😉