
AGENCY: Catalyst, 2020
ROLE: Discovery, UX / UI Design
Project Overview
The New Zealand Defence Force and Lockheed Martin came to us for some much needed help in bringing their methods for allocating equipment into the current century. Their pain points were many, but a key point was the reliance on spreadsheets and lack of real-time information on the status or location of a piece of equipment. Delays in the transfer of information made it difficult to accurately provide necessary equipment to the different bases for a specific time period. We worked with them to architect and design a bespoke, web-based system using a headless CMS and React.


"We need 20 MHOV's with sides for 2 weeks"
The Sgt’s putting in the requests for their equipment, in this case, we are focussing on “vehicles”, starts the process. The person in charge of allocation then needs to find where these vehicles can be sourced from. Many times, the vehicles may need to come from more than one location. The allocators also need to know if the vehicle has been serviced, and if it’s fully operable. We had several workshops with the allocators and the base team to sort out the common issues, and where things usually got stuffed up. We knew this system would need to pass through a lot of data in real time, so it was also important to prioritise the things that they would need to know first.
A complex, but quite usable design solution
One of the primary screens designed was the one used by the allocators to find the equipment and see it’s status. We netted out sorting by vehicle category, and then listing each vehicle in inventory. The interface shows a sort of “agenda” for that vehicle and it’s activity over a course of time. This allowed the user to plug in the necessary dates to see what vehicles were where and their state of operation at any given point during the year. It would also show them if there were conflicting requests for vehicles so that they could rearrange accordingly.


The Deconfliction process was the trickiest
Instead of just denying a request for equipment if there was a conflict, the allocators would see if they could allocate a similar vehicle to one of the bases instead. This is something they preferred to do by phone instead of overcomplicating the matter.
Because of the complexity, and continuous testing with the client, it took approximately 2 years for the tool to be built, and the MVP would only allocate a select number of equipment types. As it gets used, the learnings continue to show us ways to make the tool better, and then allow for more inventory types to be added.

No more spreadsheets
This tool allowed the equipment allocators to not be tied to their piles of spreadsheets showing inventory.
Real time data for inventory
A web-based tool means that they can see equipment requests and status of specific pieces of equipment in real time.
Ability to fix conflicting requests
With real time data for their inventory, the allocators could see where equipment could be moved or substituted so that everyone could have their requests met.
Faster, easier and much more accurate
Allocators can now see what other allocators from other locations are doing as it happens. This makes it easy for them to pick up a phone to quickly sort out a possible conflict.