Bulk scanning update
The project
The functionality of the Parsl app is built around scanning tags and then performing actions on them.
There are two ways every action can be performed,
SINGLE SCAN
By scanning the tag and then selecting from one of the contextual actions
BULK SCANNING
Selecting the action from the ‘Bulk Actions’ menu and then scanning multiple tags that are applicable for that action.
Feedback from clients using the Parsl Inventory app, and one significant potential client trialing the app was there were performance issues when scanning large amounts of tags, and in particular scanning large amounts of tags using the Inventory Count feature.
This was a significant blocker in delivering the efficiency gains that were being pitched as one of Parsl’s key USPs.
Research and testing
Client interviews
As this project was initiated due to client feedback, interviews were set up with myself, a key account manager, and the Chief Technical Officer, in order to understand when and where the issue was occuring.
These interviews occurred over Zoom, as the clients took us through how they performed various actions and when problems were encountered, ask detailed questions about the nature of the problem and any similarities with when they’ve encountered these problems before
In-house testing
With the same team as above as well as the QA team we replicated an inventory store-room environment and performed bulk actions to replicate the scale at which our client’s were encountering problems.
This stage of testing was informed by our initial client interviews in order to further explore technical and usability pain-points without being too much of a drain on our client’s resources.
UX Heuristic Audit
Due to some usability design issues that were identified in the above research and testing, as well as a course of general good practice, a full UX heuristic audit was performed on all Bulk Actions to find further efficiency and usability gains.
The defined problems
After analysis with Parsl’s Chief Technical Officer this problem was attributed to a few key factors:
The scanning was always ‘live’.
Each scan in a Bulk Action required a call to the server every time a tag was scanned. This caused a delay between each scan, which was exacerbated when a client had a large database.
Unclear indication of scan results
There was poor indication of the result of a tag being scanned. In addition to this it was hard to back-track to see if a recent tag had been scanned. This was resulting in unnecessary extra actions that were further slowing down any given bulk action.
Resource heavy UI
In the case of the Inventory Count feature, a full list of tags are preloaded on the scanning, with drop down menus on each Product Line. Having each of these dropdown elements actively responsive was predicted to be a significant drain on responsiveness.
The design solutions
Partial offline scanning
The clear first solution was to eliminate the amount of server calls during bulk action scanning.
Full offline mode was not a realistic solution in terms of development timeline.
A previously implemented improvement was to validate all tags at the end of the action, however, this also had several drawbacks.
- There was no visibility into what had been scanned until validation as each scan came up as an unidentified ‘tag’
- A bulk validation at the end meant that when errors were present there was no context to which tags scanned produced the errors (other than matching the physical serial code)
The solution that solved the core problem, and avoided both pitfalls listed above was a partial offline version.
Offline Toggle
The first aspect of this was adding an optional ‘offline’ toggle. The user reasoning behind this was the offline mode only enhanced large scale bulk scanning. Smaller bulk action were still viable via ‘live-scanning’. It was also a convenient was to perform a ‘soft’ A/B test with the feature.
Download defined scope
If the offline toggle is selected, downloading the scope of ‘expected’ tags locally to the users device. This allows the device to validated any viable tag for the selected action without a server call.
Implement flow to reduce server calls
If a tag is not viable for the selected action, the app will ask the user if they want to validate during the action or in bulk at the end of the action. This meant that server calls were only required if an incorrect tag was scanned, and there was an option to still delay those server calls to the end of the action. It also allowed a user-centric solution to identifying the tags that caused errors as the user are informed of a problem tag at the point of scanning.
Redesign Inventory Count screen for defining the scope of the Inventory Count
Something that became clear in the UX Heuristic Audit was the screen where users defined the Inventory Count did a poor job of giving the user the context of how the decisions they were making impacted the scope of their count, and how different scope filters impacted the end scope.
With this insight we developed the following design changes.
Introducing a Calculated Scope Preview
As the required fields are filled on the scope page the ‘Calculated Scope’ would calculate a preview of how many items were to be counted. This served the dual purpose of allowing the user to know how big the count was going to be, and informing the user how certain fields (such as ‘Include Boxes in Count’) functioned.
Merge the Box field into the Room/Vehicle toggle
It was identified that having a Room/Vehicle field and a separate Box field to define the scope of the Inventory Count was redundant as, if a Box is being selected, the Room or Vehicle that Box already belongs to can be auto-selected. Therefore adding Box to the existing Locations toggle reduced visual elements and made defining the scope more efficient. As all Boxes also have tags we added a button to scan this box directly allowing for a more efficient user experience.
These small changes produced a UX that allows users to have more clarity on what the Inventory Count they are defining is going to look like, and result in less errors and confusion when they begin performing the Inventory Count.
Redesign of the Inventory Count screen
In the case of the Inventory Count feature, a full list of tags are preloaded on the scanning, with drop down menus on each Product Line. Having each of these dropdown elements actively responsive was predicted to be a significant drain on responsiveness.
The key problem we wanted to solve with the Inventory Count screen was the resource heavy aspect relating to the Product Line drop downs.
However, insights that were gained in the client interviews told us that it wasn’t purely technical performance that were causing inefficiency issues. The UX Heuristic Audit allowed us flesh out changes that would solve both problems.
Progress bar replacing drop-downs
The resource heavy aspect of having each drop down element responsive, each product line would be represented by a card that would incrementally fill up as each product is scanned. Once a product line is fully scanned the progress card would be 100% ‘full’. These cards would then be ‘clickable’ to bring up a new screen with all required tags for that Product Line. This UX design change allowed for a massive reduction in resources the Inventory Count screen requires. It also gives the user a more intuitive sense of how far they are from completing the Inventory Count.
Progress bar replacing drop-downs
The resource heavy aspect of having each drop down element responsive, each product line would be represented by a card that would incrementally fill up as each product is scanned. Once a product line is fully scanned the progress card would be 100% ‘full’. These cards would then be ‘clickable’ to bring up a new screen with all required tags for that Product Line. This UX design change allowed for a massive reduction in resources the Inventory Count screen requires. It also gives the user a more intuitive sense of how far they are from completing the Inventory Count.
Dynamically reorder Product Lines based on last scanned
In addition to the ‘Scanned’ tab, a functionality was added to move the card of the most recently scanned Product line to the top of the UI. This change intended to give the user a direct indication of the tags they are working on.
The Results
The UI changes in these designs are yet to be completely implemented in the production app, however presenting these solutions recieved positive feedback from two key clients that were particularly impacted by the scanning problems.