01 - PROJECTS,,,
make it mean something
An upcoming complex project required an inventory management system that allowed for accurate recording of the status of inbound and in-stock items. This included maintaining locations, QA status, testing status, a QR code system and other key markers on hardware’s delivery to the field.
We had no system in place, and no workflows designed. I was given very little in the way of requirements and designed it myself, refining it in conjunction with our backend developer.
Post deployment I integrated a range of features quickly to allow for hands-free operation by using just a barcode scanner and a natural sequence of actions to avoid interaction with mouse and keyboard.
Key Features
- QR Code System Designed and integrated a QR code system allowing users to create lists belonging to a product code for check-in, moving, QA, undoing their last action, stocktake and more while completely hands-free with a scanner.
- Hands-free operation Large toasts, tailored operation text-to-speech to optimise fidelity to catch errors and a selection of success/deny ping sound effects to signal operation status.
- UX / QoL additions Reusable saved operation logs to avoid large re-scans and review user history, URL slugs for easy filtered view sharing, user friendly dashboard and more.
- Management-focused interface Interface surfaces the most "needed" management information.
- Stocktaking Dedicated stocktaking features with printable reports, edge cases and more.
- 3D warehouse render Lightweight 3D ThreeJS render of the physical space helping aid remote staff in understanding the space.
Issues Encountered
- Largely undefined project I was unfortunately unable to gather requirements, see the warehouse space or otherwise gain information on intended workflows meaning I had to design with my envisioned usage. Later changes impacted the workflows resulting in more development time for new features and/or adjustments.
- Changing CI/CD constraints Initially told no CI/CD or new code was possible post live, which later changed and then multiple features requested.
- Low pre-launch user engagement Difficulty getting users interested in pre-live testing or exploration to provide input in combination with the above.
- Backend disagreements Disagreement on backend behaviour, i.e. data models. Partially limited ease-of-use for end user; which was later changed to support the ease-of-use.
- Unclear hosting plan No information about how it would be hosted, utilised Netlify for early user testing which later had to be ripped out in favor of Docker / Kubernetes on Azure. Added a few avoidable hours.
What I'd Do With More Time
- Better mobile responsiveness — Due to planned usage patterns mobile responsiveness could be improved.
- Own more of the project from the start — If I were given more time and requirements I'd like to have handled the project start to finish including CI/CD and backend data structures. Caused some unneccesary development time and frustration.
Lessons Learned
- Demand requirements — A lack of requirements caused unneccesary speculation on the look and feel of the application ultimately leading to more development time than neccesary, frustation and post-live support.
- Lock down data models before building — Backend/frontend disagreement over data shape caused avoidable friction, turning a single logical action into multiple endpoint calls. Agreeing on models before implementation would've avoided that.
- User testing isn't optional — Get leadership buy in to push early user testing. I hosted an earlier version, walked staff through it but ultimately saw low engagement or feedback. This lead to a post-live flurry of requests.
- Get infrastructure decisions in writing early — Hosting and CI/CD constraints changed more than once mid-project; confirming those decisions up front would've avoided ripping out working setup later and design decisions.
After speaking with a business leader about issues which consume a lot of time or limit future growth I identified an auditing task being done largely manually which could be partially automated and done better.
Auditing and compliance costs hundreds of hours each year, including manual paperwork, information collation and the associated back and forth between internal and external parties. Data at this point was handled across several spreadsheets, both local and on the cloud, as well as other partial information living in different formats and locations.
Furthermore, setting up the auditing and keeping an eye on compliance schedules, as well as the different risk factors requiring earlire audits were all handled manually.
In short, this project was aimed at reducing time required from all parties, to standardise information, make communication easier and give a better overview of all relevant data points.
After reviewing currently recorded information I began to develop this project in my spare time to propose before official approval.
Key Features
- Dashboard Geographical display of auditable items and audit timelines to visualise what was once lengthy manual tasks into a quick view.
- Simplify the tasks Internal staff create audit projects, send them to external contractors and can visualise project progress, action from an audit review queue and more
- History at a glance Currently a user needs to manually parses dozens of documents and photos in disparate locations to understand the history of an auditable item. This dashboard builds all of that into a timeline on the item's page.
- Automatic report generation Generate audit histories, repair costs, compliance over time and financial costs in single click PDFs.
- Allow external staff to aid in data accuracy Auditable items have GPS locations and are sometimes difficult to locate. While performing an audit the external party can suggest GPS location updates using their location data.
Details for this project are coming soon.