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.

Mobile Application inventory management

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?


  • are users manually counting the SOH? Are they comparing what they physically see with the SOH that is currently in the database?
    – Mike M
    Aug 25, 2017 at 6:19
  • They are manually counting the SOH and updating it accordingly. The main purpose is for updating and keeping track in that way. Aug 25, 2017 at 6:50
  • 1
    This looks like the difference between "add to" and "set at" - where "add to" increases the database by the amount entered (say database = data + n) and "set to" fixes the database at the amount entered (say database = n). Is that correct? Aug 25, 2017 at 7:38
  • Hi Andrew, yes that is correct and very well put indeed. Aug 26, 2017 at 6:22
  • Wow, what a great response from everyone. I was thinking along the lines of having the value of the previous stock and new stock, along with some more instructions in the text box (i.e. 'update you current stock on hand' and 'add to your stock on hand'. Along with some of the suggestions, this should improve the user understanding. Aug 26, 2017 at 6:32

5 Answers 5


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

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.

  • 2
    I'd go with that but with the caveat that you must show the current stock level (before any additions) somewhere. Aug 25, 2017 at 11:04
  • 1
    What if the user does a recount, and discovers that the SOH value is too high? Would you allow to 'add' negative items?
    – JAD
    Aug 25, 2017 at 11:22
  • 1
    I think in day to day work (with a shipment coming in, while other items are already on the shelves) adding to stock is way more convenient. I wouldn't remove that. Adding the first suggestion is basically what the radiobutton does, if I understand it correctly.
    – JAD
    Aug 25, 2017 at 11:28
  • 1
    Right now we have both functions within one line basically, with the radio buttons to differentiate between them. Your suggestion is to remove one of them, while that function might be useful still. Would moving both functions to different lines be an alternative?
    – JAD
    Aug 25, 2017 at 11:32
  • 1
    By which I mean, creating two separate inputs for both functions: "Add new stock to SOH" and "Manually set SOH value".
    – JAD
    Aug 25, 2017 at 11:33

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.


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).


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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