Our users need to specify multiple ranges of quantities and specify a price for each range. I can't post an image or I would show this concept mocked-up.

enter image description here

My question is: Imagine the user is able to specify a quantity of 10.5 (maybe it's a software license for 10.5 years)...what is the price?

Some would argue that the ranges should be:

  • From 0-10, my price is $50.
  • From 10-15, my price is $40.
  • From 15+, my price i $30.

But, then what if my quantity is exactly 10?

What is the best way to handle ranges like this, assuming the user can enter decimal values for the quantity, but also avoiding having to require the user to enter 0 to 10.99, 11 to 15.99, etc?

  • Post a link to the image, and one of us will insert the image. – JohnGB Apr 1 '13 at 22:15
  • Wait, the users are choosing ranges of quantities and prices. Who is choosing the specific quantity of 10.5 then? The system? Is it like those auctions for electric power? – Pasha Apr 1 '13 at 22:25
  • The best interface for such a problem that I have seen is a graph where you can add, delete and drag points with a mouse. It can be anything - a piecewise-linear combination, a mess of constant values etc. – Deer Hunter Apr 2 '13 at 7:15
  • Okay, got what you mean: open vs closed interval endpoints. – Deer Hunter Apr 2 '13 at 9:16
  • @PashaS This is a backend interface for a pricer to set the prices. The end user then uses another interface to specify a quantity to add to a quote. Calculations are done and it spits out a final cost. – csader Apr 2 '13 at 15:22

I suspect you might be misunderstanding the business logic here. Let's take your first example. Under those prices if I buy 10 units, I expect to pay $50 * 10 = $500 (+tax :). What if I order 12 units instead? Would it be $40 * 12 = $480? If yes, then no reasonable person would ever order 9 or 10 units — ordering 11 is cheaper!

However this is not how that price schedule is typically interpreted. Usually, the range 11–15 at price $40 means that any unit ordered ON TOP the first 10 will have the price of $40. Thus, if I'm ordering 12 units I'll have to pay $50 * 10 + $40 * (12 − 10) = $580. And if I order 10.5 units I'll have to pay $50 * 10 + $40 * (10.5 − 10) = $520.

If you use these rules, there is no real ambiguity at q = 10. It will cost $50 * 10 + $40 * (10 − 10) = $500.

  • There are two possible scenarios (that are specified via another control in the interface). "Normal" pricing is the situation in which a Qty of 12 = $480. "Graduated" pricing would be the latter example, where Qty of 12 = $580. The ambiguity is not at 10, it's at 10.5. – csader Apr 2 '13 at 15:35
  • Re-read your comment and realized that you were referring specifically to the second example. In the "Graduated" example, I would agree that there is less ambiguity, but in the "Normal" example, Qty of 10 could mean either $400 or $500. – csader Apr 2 '13 at 15:58
  • My point is: the case that you call "Graduated" is actually the normal one; whereas the case you call "Normal" is never used in practice, hence it has no standard name. You don't want to adopt a business rule where nobody ever buys 9 units because buying 11 is cheaper. – Pasha Apr 2 '13 at 17:44
  • Never say never. :) We have customers who use our product who have such a business rule. I think the issue you're coming up against is the example prices I chose. Imagine the example used $50 and $49 for the first two scale breaks: if I sell 10, it's 10*$50 = $500. If I sell 11, it's 11*$49 = $539. – csader Apr 2 '13 at 18:32
  • Well, you just make the problem less prominent, without eliminating it completely. If I order 10.01 units, I'll pay 10.01 * $49 = $490.49, which is better than ordering 10. But well, if you DO have this kind of customers, then your UI should do 2 things: (1) forbid fractional transactions, (2) give warning if price differential creates a gap where buying more than you need may be beneficial. – Pasha Apr 2 '13 at 18:55

Taking the above example, I cannot think of a scenario which in which 10.5 could be required but if it had to be, your increment/decrement controls must have a 0.5 as the "step value". But here another question could be what about 10.25 - 10.75 OR 10.33 - 10.66? For situations like that, you cannot have concept of range (1.25 to 7.44) but rather use exact value model for ordering (6.44)

BUT if you were looking to use a combination of range and discounts, you might want to use something similar.

enter image description here


Unless you are going to add non consecutive ranges why not just remove the "From" value:


download bmml source – Wireframes created with Balsamiq Mockups


Your UI layout is sufficient for integer quantities, but not for float values. For the latter, you should use

From      To       Price
      x < [   10]  $[   50]
10 <= x < [   15]  $[   40] 
15 <= x            $[   30]

in the back-end UI. Of course, this can be expressed less mathematical, but you get the idea of it.

  • Thanks for the feedback nibra. I'm struggling with how to represent exactly what you're proposing, but in a less mathematical way. – csader Apr 3 '13 at 16:38
  • Since it is the backend, you can use the mathematical notation (and provide a help text). If you don't want that, use something like "10 or more, but less than 15". Personally, I'd prefer the variant with less literal text, but in the end, it depends on your target group. – nibra Apr 4 '13 at 1:46

You could write: "From (Incl.)" e "To (Excl.)"

In the BackEnd UI there are three columns: From, To, Price. I am suggesting to call them: From (incl.), To (excl.), Price. In this way the user knows that the first row, for instance, would be 0<= Quantity< 10 and so on.

  • 2
    Could you expand on this? – Mayo Feb 6 '18 at 15:24
  • I wasn't clear. I meant to say that you should edit your answer to include this. – Mayo Feb 7 '18 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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