Confusion over radio button and terminology

Question

I am designing a mobile application and was looking for some guidance on how to structure the inventory management section. This app allows for users to scan products and update the current Stock on Hand (SOH). From some initial testing I have found users are getting confused between the two radio buttons. See here for the example.

Update stock means that the database will be updated to the value entered by the user. Add to stock means the current database value will be increased by the amount entered by the user (i.e. SOH 30 + entered value 5 = SOH 35).

Users are not really understanding the difference between the two. Did anyone have any suggestions to help the UX here for this?

Thanks,

Answer 1

There was a similar question answered here. Adapting it to mobile might look something like this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

They key here is that the user can edit either the Stock on Hand or the Stock Added, but not both. As soon as one of those fields is edited, the Save button is enabled, and the other field is disabled. You might want to have a cancel button to allow them to reset to previous numbers, but that would require testing.

I didn't add in the the search bar, and the layout is slightly different than you've got in your original screenshot:

• Split the Product Details and Inventory into separate sections (easy to scan)
• Made clear the distinction between editable and non-editable fields (it was not clear in the original if underlined fields were editable), and right-aligned the product details
• Used enclosure to group the Inventory fields with a Save button

Answer 2

My question would be (and it might be a stupid question mind you), why offer both options?

Why not just keep a single option where the user just selects:

"Add to stock". The user has to put the extra items they have for the system to keep it updated.

That way all they need to do is add any new SOH items they have received with the database being updated on its own.

I understand your logic of giving the users extra freedom.

But sometimes providing tunnel vision and removing cognitive load like: "err, do I add these or are these my total", tends to be better for the users.

Answer 3

I think the confusion might come from the word "update".
That may also be because I am not a native speaker but this word does not suggest that the old value will be overwritten.

It might sound a bit naive but maybe renaming the radio button to "set as current SOH value" could help.
(space for extra letters does not seem to be a problem in your screen)

Or just follow Socrates Kolios' advice and remove the choice altogether.

Answer 4

TL;DR version

From the information given so far I think you will nearly always only want an add to stock (SOH) option on this screen. However, as discussed below, this may add either to the system's idea of stock-on-hand, or to a running-total when performing a stock-check. (Essentially the same screen would be used for both actions).

The update/set stock option would most likely live elsewhere (possibly on a manager's screen only) and would only be used once a stock-check process is complete.

---

It's not entirely clear what processes your users' are performing, and therefore it's not entirely clear when adding to stock-on-hand (SOH) or updating/setting SOH make the most sense. If you haven't already, you need to clearly define the actions/processes your users will be performing in order to decide the best way of presenting the UI.

However, the two actions that immediately spring to mind are:

• Processing incoming deliveries – a parcel/shipment arrives from your suppliers and users scan/enter a stock-code and the number of items received.

• Performing a stock check – here they would be roaming the shelves (in a shop and/or a warehouse) manually counting what is physically present to check against the system.

and I will discuss these below. If these actions are incorrect, or there are other actions being performed, please indicate.

In the case of processing incoming deliveries, I can only conceive of add to stock being useful – the person opening a delivery has no idea how many items may actually be in stock (nor has any need to know); all they need to do is tell the system that there are x more items available.

In the case of stock-checking, it gets more complicated.

• If all instances of a given item are guaranteed to be in the same location, then the user can go to that location, count the items and enter that number. For this use, update stock (or set stock level) would be the appropriate option.

However, that use-case seems fairly limited: it won't work if there's any possibility that stock may be in more than one location (multiple places in a warehouse; in both the warehouse and on shop shelves). In addition, it won't easily allow anyone to analyse differences between what the system thought was in stock, and what is actually in stock. For a small organisation, this might not matter; however, a larger company may well want to know when there's a discrepancy between the two: this could indicate poor working practices (deliveries not being processed properly; items not being registered when sold); excessive breakages or theft.

To provide this level of checking, you will need to maintain two counts: the SOH as currently implemented (increased on delivery; decreased on sale) and a running total of stock-checked items. The procedure (for a given stock-item) would be:

1. Clear the running-total of stock-checked item(s). This might be for a single item you want to check, or for all stock items if performing a full stock check.

2. User(s) roam the shop/warehouse, either looking for any instances of the single-item being checked, or processing everything they find. In either case, they will scan/enter the stock-code and the number of items found and use essentially the same add to stock function (on essentially the same screen) as when processing deliveries (the difference being that the running stock-check-total is incremented instead of the normal SOH figure).

3. At the end of the exercise, someone – probably not the users doing the checking – will review the stock-check-total count(s). Only at this point (after noting any discrepancies for further investigation) will the day-to-day SOH count(s) be updated from the stock-check count(s).

Answer 5

Add a field New Stock to show what the stock will be after saving

You're already showing the SOH. Add a field below the Counted Quantity that shows what the New Stock will be after clicking on save, based on the selected radio button.

That way, the user can see that the SOH will be increased by the Counted Quantity, or will be set to the Counted Quantity.

Using Jonathan's design as a basis:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Other changes:

• Changed "Update SOH" to "Set as SOH"
• Last Counted date should be updated automatically

---

Let the user see the consequence of their options.