Bulk scanning update
The project
The functionality of the Parsl app is built around scanning specific tags and then performing actions on them.
This functionality is necessary in order deliver the inventory accuracy required for the cannabis industry, but it leads to efficiency problems when it comes to bulk actions. However, we had feedback from multiple clients that they were encountering problems when performing these actions.
After analysis with Parsl’s Chief Technical Officer this problem was attributed to a few key factors:
Live Scanning
The scanning was always ‘live’ requiring a server call after
Misleading UI
Unclear indication of scan results
Technical limitations
Resource heavy UI
Below are the solutions that were developed through client interviews, in-house testing, and a full UX heuristic audit.
The design solutions
Partial offline scanning
Download defined scope so relevant tags can be locally verified
The clear first solution was to eliminate the number of server calls during bulk action scanning.
Full offline mode was not a realistic solution in terms of the development timeline. So we implemented a partial offline mode that allows users to download the scope of relevant tags locally to the phone. This means that anytime a relevant tag is scanned it can be validated without a server call.
Implement flow to reduce server calls for tags outside the defined scope
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.