Designing a condition builder: A tweak that made everything easier
Have you ever been prototyping user interface for a condition builder? If you did, you might remember the pressure for speed and quality. Or the number of contradicting ideas coming from the team. Perhaps the tedious hacking of prototypes at the edge of what your prototyping tool can do? I remember all of them. (My mind works great when it comes to retaining memories of unhappy times and yes, I wish I could recall more practical information instead!)
The last time I was working on such a user interface component, I decided to search for a shortcut to the process. To give you more context, the last time was designing a condition builder for marketers. They needed to create a segment of their website audience based on a specific condition.
Instead of jumping into requirements clarification, as usual, I started with breaking down the task of defining a condition. Based on this mental activity, I listed all the high-level design decisions we had to make. In our case, the list looked in the following way:
- What wording style we’ll choose?
- How the mini-process for a single rule definition will look like?
- Do we need to categorize the rule types and if, then how?
- How much freedom the user will have when combining the individual rules?
- What mental model of building nested conditions should we follow with the UI?
- What wording to use when building nested conditions?
Of course, one of them actually popped up later on in the process but it’s not important right now. More important is that for me, they were the key to simplifying the design process. Once I had them, I could come up with potential answers, also high-level ones. Staying on the high-level turned out to be the shortcut.
This higher level is a bit hard for me to define precisely. For example, the difference between possible answers (approaches) was a number of steps the user will have to take to complete a single rule definition. Or the amount of freedom given to the user when structuring the condition. Things like which UI component to use, layout nuances or exact wording were too low-level. I left making decisions about them for later.
To illustrate how the conceptual solutions looked like in our case, here are two examples:
1. What wording style we’ll choose?
Correct me if I am wrong, I believe that for conditional builder there are two wording style options only, the sentence style and the parametric style.
2. How the mini-process for a single rule definition will look like?
When abstracting from visual design, what gets left here is a decision about how many steps to take and what the user will do in each of them. Based on what I’ve seen so far, nobody defines a single rule in more than three steps.
You might ask in what sense this approach was a shortcut, I probably had to user test, fail and iterate anyway, right? I did, however, the testing went faster than before. I made these conceptual solutions hypotheses for the first two rounds of user testing. Disproving most of them simplified the following prototyping a lot. I could skip certain combinations completely because I knew they are a dead-end and I understood why. Instead, I could focus on finding the best combination of the concepts that turned out to work. At the very end, I enjoyed the luxury of fine-tuning the choice of UI elements, their layout and wording coherence.
I understand this was no bullet-point list of shortcuts you might expect at the beginning. But still, approaching the problem in such a structured way saved me from several more prototype iterations. It also turned out to be a great approach to communication with my team and everyone else involved. Touring them through the list of design questions and conceptual approaches helped me to communicate the actual complexity of what we’re going to do. Not only me but everyone involved could see it will simply take some time to build a marketer-friendly condition builder.
What is your approach to the design of complex components? Do you slice the task for yourself in a similar way or work differently? How and how come?
