I'm looking for a known design pattern or algorithm that can be used to effectively determine a set of available options to be presented to a user based on previous decisions.

An extremely simple example of this could be Year > Make > Model where Model and Make are dependent on the prior selections the user made.

I'd like this to scale to an industrial scenario like machine equipment, that can have dozens of options, each with dependencies on the prior selections the user made. I had considered a decision tree, but I felt modeling it with this many decisions could be a scalability challenge.

What would be the right learning path to pursue to build such a feature?

  • I see this was downvoted to close as 'off-topic' however reading the 'help center' scope this clearly falls under the criteria of 'requirements, architecture, and design', so please clarify specifically what is off-topic.
    – Kyle B.
    Mar 12, 2018 at 14:14
  • You are asking for existing software that applies actions based on rules. Either rephrase your question, or visit the Software Recommendations forum on stackexchange Mar 12, 2018 at 16:44
  • I removed the very last statement which is the only piece inquiring to if something like this existed already. I would like to build this myself. I will ask separately on the Software Recommendations forum if something like this already exists.
    – Kyle B.
    Mar 12, 2018 at 18:14
  • 1
    @KyleBallard learning path sounds like career advice, which is also out of scope. By the way, this subject is far too broad. You'd need a full book on statisticcal analysis, one on machine learning, and one on recommendation systems (the latter topic being extremely competitive for merchants, so that there is some reluctancy to share)
    – Christophe
    Mar 12, 2018 at 18:21
  • 1
    @Christophe machine learning? I think he is asking for something far simpler, rather, how to traverse a tree of possibilities. Mar 12, 2018 at 21:31

1 Answer 1


I would recommend NOT trying to apply a pattern to this and simply hard-code each form.

In my experience the relationship between the criteria is a Business Requirement and as such follows no logic that can be generalised.

For example; your Make and Model might seem like a simple parent child relationship at first, the same as many others. But after implementing itas such, a change request would come in saying

'Don't show Models X, Y and Z when the purchaser is in Michigan'

This breaks your model and forces you to make it more and more complicated until it becomes more complicated that the programming language you are using to implement it.

You will revisit the code months or years later and wish you had just coded out each form seperately.

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.