How could I handle product returns through this interface?

Question

I have a dialog where users allocate product on an order to various available lots of product.

So basically if there are 100 units on a line item of an order, the user would have to allocate this quantity out to the available lots of product in a warehouse. This part of the design will work well. The part I am having problem designing is the returns.

Consider that weeks later, some product may be returned for one reason or another. I would like the user to be able to go back to this allocation dialog and input the return in some way. The return would have to be specific to a certain lot of product, so I have considered putting an extra column of inputs labeled Returns next to the Quantities column.

Here's the issue however. Will the user assume that any amount entered in the Returns column will have to be removed from the original Quantity column manually? Or will they assume that they should enter the Return amount and leave the originally entered quantity alone? I could design it to behave either way, but I am trying to think of other ways to make sure that they expect it to behave the way that it actually does behave. Perhaps automatically subtracting from the quantity column when they enter an amount into the returns column (this would probably cause other problems however...)?

I thought of making the quantity column readonly after the requested pickup date has passed, but am worried about what if they are editing the order quantities after the pickup date due to a mis-ship or other exception case. What do you think? Any ideas on making this UI better?

Answer 1

Correct me if I’m wrong, but it seems that handling returns is a separate task from allocating an order –the user is not going to do both at the same time on the same order line item. Most business want to track each transaction with the customer -each order and each return, including when each return occurred, how was it handled (credit or refund) and why. The business probably doesn't want users going in and fudging allocations like that was the original order. What if some units in a lot are later found to be damaged? The business is going to want to know if that's from the manufacturer or a return from a customer. Processing a return has to be a distinct user operation.

If so, the returns reverse-allocate dialog should appear as a separate dialog from the order allocate dialog. It may be the same programmatic dialog with labels and fields dynamically modified, but you should have two functionally different dialogs, one supporting only order allocating (and correcting allocations after a pickup) and one supporting only return reverse-allocating. They’ll probably each be accessed via a separate menu items, for example.

To minimize workload, the reverse-allocate dialog should only have editable fields for the Quantities to Allocate Back for each lot. Do not make the user do double the work (with double the chance of error) by having them also manually subtract from the original Quantities fields. This is achieved without confusion by two possible means:

• Don’t have the original Quantities field. Unless it’s important for knowing how to reverse-allocate (e.g., by policy, the user should not reverse allocate more than the original allocation), don’t include this cluttering and potentially confusing information. If the users’ job is to read the quantity and lot number from the label on a bag of returned units, then maybe all your dialog needs is a read-only lot number (sorted) and editable quantity fields. Keep it simple for the user. If the user counts 15 units from Lot A, then have them enter "15" for "A." Don't make users have to perform additional arithmetic (e.g., subtract 15 from the original allocation, or add 15 to the quantity from an earlier return). That's asking for human error. Computers are better at that kind of thing.

• Make the original Quantities field read only. Label it to make it clear whether it represents the Original Order Allocation or the amount Remaining w/ Customer (the latter updating automatically). Perhaps you want both. Indeed perhaps you also want the quantity from Prior Returns and Total Returned for each lot. Depending on your users, it may be helpful to spell out the mathematical relation of whatever fields you have by inserting +, –, and = signs between the fields or labels: Original Order – (Prior Returns + Current Return = Total Returned) = Remaining w/ Customer. But again, include any of these only if they are helpful for properly completing a return.

Of course, the fact that each lot has certain attributes like Origin, Certs, and Age implies that each individual unit needs to be correctly allocated back to its original lot if returned. If that’s the case, then your system needs to track the lot identity of each unit sent out and returned. That may make it possible to automate whole Quantity Reverse-Allocated process (e.g., by scanning bar codes of returned units) and you don’t need the UI.

BTW, the standard is to label your execution button “OK” (or “Allocate” is even better), not “Okay”.

Answer 2

Keep in mind that the user interface for returns doesn't have to be a modified version of the interface you show above. Maybe a specialized returns interface would be a better way to go?

Answer 3

Do your users already use any paper forms that carry this data? These might already establish conventions for handling this data, conventions you can deploy in your own app.

On reflection, I would imagine that auto-subtracting from quantities is the best behaviour. Normally, it's bad to change something outside the user's immediate focus without their volition, but in this case, the change is identifiably linked to their action, the fields are close enough for the user to spot and identify the change, and forms that do similar things are becoming increasingly familiar. It also makes the relationship between quantities and returns completely unambiguous.

In this case, though, I think asking the community isn't the way to go. You're working in a specialist field that probably has well-established procedures we aren't privy too. Instead, conduct real-world testing on your application - even with a small user group.

Answer 4

I wonder if you actually need a second form?

I'm not suggesting it would be radically different but it seems like the difference between the two tasks (Quantities to Lots vs returns) could be significant enough to warrant a more dedicated UI.

Just because you're dealing with the same information doesn't automatically mean you can use the same UI; for something like this you should stick to a task-based approach rather than a data centric one.

often things are less clear when you try to do too much in the one place; sometimes there's a natural and logical break-point which allows you to get around this, sometimes there isn't.

Answer 5

Consider a website you have worked with that processes returns. For example, I can think of two return interfaces I have used recently - Overstock.com and Amazon.com. It can be helpful to look at some examples and evaluate what is good/bad about each design, and how the concepts could be applied in your application.

Another consideration may be if there is additional information you need to process the return (beyond just the quantity). Do you need to know why it was returned (damaged, incorrect product, etc.) for reporting or quality control purposes?