It is important to remember that when you're entering variation ideas into the "Parameters" screen, you should include system INPUTS only. You should not include outcomes or expected results (most of the time - see this article for more nuances).

Let’s try with an example of an online order for pizza. At this restaurant you are charged specific amounts of money based on the size of the pizza, ranging from $ to $$$. 

This model includes expected results (prices) as a parameter, and the price is varied by the size.

Once the parameters & values are defined, we create the scenarios...

Let's examine the first three test cases to help understand why you should not include outcomes or expected results in the "Parameters" screen.

The large or medium sized pizzas should not cost the same $ that the small size pizza costs. Because we included "Expected Price" as an Parameter we are receiving invalid and incorrect scenarios. This could have been avoided simply by including "Expected Price" as an expected result in either the Auto-Scripts or Forced Interactions screens.

It is possible to create multiple constraints to ensure that the correct "Expected Price" appears with each size of pizza (see here). But even if you perfectly modeled these complicated constraints (which is easier said than done, and can be very tough on systems more complex than this example), the advantages are limited.

So the rule of thumb when defining your parameters is summed up in the below image:

You'll thank us later when your Hexawise models are organized, clear, and not overflowing with constraints. 

To learn more about including expected results, check our articles below:

​

​