Conditional Questions

Problem

Levelpath is a procurement platform. It touches vendor onboarding, intake requests, and the long chain of approvals that connects a business need to a purchase. Forms are central to how it works. And the forms were a problem.

Customers had built out large, complex intake forms to capture everything they might ever need from a submitter. The issue was that most of the form was irrelevant to most users most of the time. Someone breezing through a simple intake request had no way to skip the questions that didn't apply to them. They waded through the whole thing anyway. It slowed down submissions, introduced friction, and made a process that should feel routine feel like a compliance exercise.

There was no concept of conditional logic in the product. Questions appeared or they didn't.

Role

I was the sole designer on this feature from start to finish: research, exploration, direction-setting, and final design. No conditional question system existed in the product before this work. Everything had to be defined from scratch: the interaction model, the creation experience for form builders, and the end experience for users filling out the form.

The work was driven heavily by customer input. I had a strong set of user stories from existing customers describing exactly where their forms broke down and what they needed to be able to do. That grounding kept the exploration honest.

Insight

The first instinct was to look at how other enterprise software handled conditional logic. There was no shortage of examples. Large platforms with mature form builders had all solved some version of this problem. But none of what I found mapped cleanly onto Levelpath's context. Most implementations treated conditionals as a field-level concern: one field triggers another field. That model works for simple forms. It falls apart when the branching is complex and the groups of follow-up questions are substantial.

The pattern that actually fit came from outside the category entirely. Years earlier I had worked on a test creation and delivery platform. It used a concept called question banks: a library of questions that could be grouped, reused, and surfaced dynamically. The mental model transferred. Instead of thinking about one field triggering another field, the right frame was: a question triggers a group of questions. The condition is set at the question level, and what it surfaces is a bank — a coherent set of follow-ups scoped to that answer.

That reframe changed how the whole feature came together.

Solution

The conditional questions system was built around two connected ideas: conditions and question banks.

A form builder could designate any question as a conditional trigger. When a user answers that question in a particular way, a question bank appears inline. If the condition wasn't met, the bank stayed hidden. The form stayed short for users who didn't need it and expanded precisely for the ones who did.

I explored two structural approaches before landing on this one. The alternative was to set conditions at the field level, where individual fields above a question would determine whether it appeared. That model is more granular, but for the complexity of procurement intake forms, it was the wrong fit. The branching in real customer forms wasn't one field to one field. It was one answer to a whole category of follow-up. The question bank model matched how form builders actually thought about their forms, and it matched the user stories customers had given us.

The creation experience was designed to feel close to how the rest of the form builder worked. You defined a question, marked it as conditional, created or attached a question bank, and set the trigger condition. The structure is explicit and auditable. Form builders can see exactly what will appear for each answer without having to mentally simulate the logic.

Outcome

Conditional questions shipped as a net-new capability. There was no prior version to compare against, just the before and after of having it at all.

The customer response was strong. The problem it solved was one they had articulated clearly during research, and seeing it addressed landed well. Users were especially relieved to be able to present shorter, more focused forms to submitters who didn't need the full intake. For procurement workflows where speed and clarity matter, reducing unnecessary friction in a form isn't a small thing.

The shift was less about a single metric and more about what became possible. Form builders could now design intake experiences that adapted to the person filling them out, rather than forcing everyone through the same path regardless of relevance.

What I'd Do Differently

The question bank model was the right structural call, but the creation experience could go further. Building and managing banks as a separate object — something you define once and reuse across multiple forms — was an idea that didn't make it into the first version. As forms grow and organizations standardize their intake flows, reusable banks would reduce redundant work significantly.

The other thing I'd push harder on earlier is the visibility of conditional logic for form builders. When a form has multiple conditional branches, understanding the full tree of what a submitter will see in each scenario gets complicated fast. Better tooling for previewing and auditing that logic — something closer to a flow map than a linear list — would make complex forms easier to design and maintain.