Conditional logic with pricing in variations

Hey team. I’m currently in the process of building out a prototype for a computer configurator spoke page, and would like to get some opinions on the direction i should take to build it. You can see the bones of my prototype in the attached RP file. Axure - variations example.rp (79.1 KB)

The Ask
When a variant is selected, the entire spoke will reconfigure to match the products that adhere to that variation. There may be certain variations that appear as greyed out / unavailable.

We also want to have price changing between the variants based on the SKU # of the item. Price not only effects the variation you’re configuring, but all variant rows on the page.

The way I’m planning to attack this in my head is build out states for each variant row, and switch between the states depending on how the other rows are configured. My concern is that this task seems rather laborious, and I’m just wondering if there’s an easier way to wire everything up.

You’ve got some hefty requirements there, so a fair bit of labor will be involved regardless, I’d say…

My first thought was you’d be better off using a repeater for your options list. Your “variants conditions” would then just be a matter of updating certain rows in your repeater. Thinking through the details, that could get complex pretty quickly as well. I gave a shot at multiple repeater lists–one for each class of option (Processor, Memory, etc.) and that went together pretty well. This makes it easy to expand, change or update the categories and items (as long as you know how to work with Axure repeaters. Took me a bit of stumbling around to figure out the relative price differences for items within a category, and how that would affect an overall price. There may be a more elegant way to calculate this, but you can have a look at the repeater code on Page 2©.

Page 2(b) is a manual approach at building the options lists without repeaters, but with “less brute force” than trying to build out all the permutations of states. Here, each option is a group made up of the option name and its “relative price flag”. This seemed easier to deal with than constantly changing all the text values–and is more reusable. Selection grouping takes care of selecting only one option within a category, and the “price flags” reset their relative pricing when selected. Also, the selected price flag has an opacity of 0% (hiding it) to match your example page layout, which is a little odd, but is easier to handle than hiding/showing the selected price.

price variations example2.rp (255 KB)

Thanks MBC, this is great!!!

You’ve given me a terrific starting point, I’m going to digest this and will follow up if I have an questions.

Thanks agian!!!

  • E