I'm working on a project where we need to create a form builder that allows nesting of follow up questions based on a questions answer.

Currently we're thinking of a treeview that allows dragging and dropping of question types (multi-select, free form text) onto the tree like so:

TreeView of questions

We would then have an editor panel next to or below to add answers or modify the question.

This will work, but it doesn't really feel like you're creating a form.

I did a bit of research, and it looks like most form builders use drag and drop on to a realistic form:


And then have conditional logic on future questions:

enter image description here

This seems much more flexible, but seems like it could quickly become complicated, and I couldn't find an example that seemed intuitive (which question was triggered by which answer).

So my questions are, any examples of this done differently? Any advice on whether I should pursue the treeview vs the conditional logic?

  • I don't have enough information, so I'll try to add my 2 cents in brainstorming mode :-) Maybe you don't want to create a form, but a conversation? For what I see in your sample, what you seem to achieve looks more like an interactive exchange of information than a form.. Have you tried word recognition? Some sort of basic IA that creates a field if certains terms are detected? That would be cool.
    – user44384
    Commented Mar 2, 2014 at 17:03

3 Answers 3


This is a very abstract customization problem. Flexibility creates complexity. I don't think there's going to be an elegant solution that will meet all the boundary cases.

Having said that, can you use domain knowledge to narrow scope? i.e. who is the form builder for?

  • Are you building this as a general tool? In which case, we can't predict how deep a form will be.
  • Is this for a specific domain? Perhaps this will allow you to create templates. Maybe it'll restrict the question-types. If you foresee a 100-level deep branch, maybe a form isn't even the right interaction. Or questions as a unit is too granular and you should be looking at this at page-level.

Re: tree vs. conditional-logic.

You would need a condition wizard regardless of tree or form view: When you're adding a new node to the tree, you would need to know if you need to branch. When you add a new field to the form, you need to know if it has subsequent questions. (Although the example of the condition wizard that you provided isn't very good. It's too systematic/technical for the general user.)

I'm partial to the tree. It clearly communicates the decision points. It's harder to communicate that logic in a form. Although I would go with a visual tree rather than a text tree:

Visual tree diagram

I would not fixate so much on it not looking like you're creating a form. You're really performing two actions: (1) Creating the interface--the form, (2) Creating the behaviour--the conditions. It's hard to mash the two together because the behaviour requires the user to interact with a form that doesn't yet exist. How can you show something that doesn't exist yet?

In the diagram that I provided, the user is seeing the behaviour. When he clicks on "Add a field", the system would launch a dialog that initiates task (1). This is the condition wizard that I didn't mock up.

The drawback of the visual tree is breadth (limited by horizontal real-estate). Whether or not this is the right approach, again, will depend on the context of the form builder.

  • I really like this idea. From talking with potential users, I see the average depth being 2-3 questions, it might make sense to 180 degrees to have the root questions vertical and the branches horizontal.
    – Mike
    Commented Nov 9, 2012 at 17:24

Yes, this will quickly become convoluted.

You add iterations (how many employees do you have? 5 Give us the name of employee 1.. Give us the name of employee 2) and basically you have a complete programming language.

A complete programming language makes people want complete programs, and a decision tree of an average enterprise program can be 10-100 levels deep, so I wouldn't recommend a tree representation.

Another visual abstraction would be pipe-based, like Yahoo! Pipes or Apple's Quartz Composer:

enter image description here

You can also do flowcharts, or perhaps block diagrams, like Scratch or App Inventor:

enter image description here

enter image description here

(Image credit: The Open Sourcery)


You could simply have every possible question on your tree present on the page(s), but only show and mandate completion of the ones users ought to see based on their previous responses using if/than + javascript

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.