Designing the software layer that makes RFID hardware worth buying.

RFID4U is a US-based end-to-end RFID solutions provider hardware (readers, antennas, tags, printers) and software (TagMatiks platform). The business model is hardware-led: RFID devices are the revenue. TagMatiks is the software ecosystem that makes those devices useful, and the reason enterprise clients choose RFID4U over a generic hardware vendor.

TagMatiks serves healthcare, warehouse and logistics, manufacturing, retail, oil and gas, and government. I joined as the sole designer. My scope covered the entire product surface web platform, Android and iOS mobile apps, Windows application, RFID reader device interfaces, and the RFID4U website and store. The products I owned: TagMatiks Asset Tracking (enterprise asset lifecycle across healthcare, logistics, and manufacturing), Set Tracking (surgical instrument sets for hospitals — fixed reader plate scans entire trays at once), TagMatiks Inventory Management (field inventory and cycle counts for warehouse environments), a custom mobile pairing app (offline-capable Android app for enterprise clients with non-standard hardware), TagMatiks Core middleware configuration surfaces, and the RFID4U website and store.

Every design decision from information architecture to high-fidelity screens was owned by me.

When I joined, TagMatiks worked in the sense that it processed transactions and stored data. But the interface had grown organically over years without a design system or consistent interaction model. Modules were built independently, so navigation varied between sections. There was no dashboard giving users an operational overview. Insights and status indicators were scattered. Users had to know where to look before they could act.

In operational environments a hospital sterile processing department, a warehouse floor, a manufacturing line this creates real friction. Users are not at a desk with time to explore menus. They are moving between physical spaces, handling equipment, operating under throughput pressure. Cognitive load in the interface translates directly to errors and slowdowns in the physical operation.

My first task was not designing a new feature. It was understanding the existing system well enough to restructure it building coherent information architecture and establishing design standards that every new module would follow.

Most software design problems start with a user and a screen. TagMatiks added a third variable: the RFID device itself. Clients deployed across fundamentally different hardware configurations — each with different screen sizes, input methods, and operational contexts.

The design principle I established: core workflow logic stays identical across all surfaces. What changes is the interaction layer — input method, screen density, action affordances — not the mental model. A floor worker scanning assets on a handheld and a manager reviewing asset history on the web are operating in the same system. They should feel it.

The core TagMatiks Asset Tracking product covers the full asset lifecycle: check-in, checkout, transfer, consumption, disposal, recovery, and inventory reconciliation. These transactions existed when I joined but there was no unified overview. You could perform any action, but you couldn't see the state of your assets without navigating into individual modules first.

I redesigned the dashboard as the operational centre: asset status distribution, recent transactions, and location summary visible before a user drills into any module. Transaction types (In-Stock, Check Out, Consumed, Disposed) surface as the primary KPIs the first thing an operations manager needs when they open the system.

The Check In transaction flow was redesigned around the physical act of scanning. The reader selector sits at the top the first decision before any transaction. Scanned assets populate the list in real time. The user reviews and confirms with one action at the end, not scattered across steps.

Inventory reconciliation was a specific redesign challenge. The old interface surfaced exceptions only after the scan was complete. I redesigned the scan summary to show Expected, Matched, Missing, Excess, and Misplaced as live counters so users can investigate discrepancies while still on the floor, not after returning to a desk.

TagMatiks supports RFID sensor tags that log environmental data — temperature, humidity alongside asset location. This introduced a new design surface: sensor profiles, threshold configuration, and alert management connected to asset records.

The sensor detail view combines static configuration (thresholds, sampling interval, RF sensitivity, notification settings) with live operational data (last temperature, battery status, memory status). I separated these into two panels on the same screen so a facilities manager checking on a temperature-sensitive shipment does not have to navigate away from config to see current status.

Enterprise deployments require configurable tag formats and role-based access these are deployment blockers, not optional features. The Tag Format screen handles EPC data format, prefix, bit length, and tag locking. The permissions matrix gives admins granular control per module with column-level permissions. Both screens are setup flows used once per deployment the design priority was clarity, not speed.

Standard TagMatiks mobile was designed around specific supported RFID handheld devices. Enterprise clients using different hardware or clients wanting to pair a standard Android phone with any RFID reader over Bluetooth had no path forward.

For a large US-based furniture retailer managing inventory across warehouse and retail locations, the requirement was a custom Android application: pair with any compatible RFID handheld, operate fully offline, focused entirely on scan, identify, and transact. The home screen surfaces four actions Find Item, Open Counts, New Count, Print Tags. That is the entire workflow for a floor associate. The Cycle Counts scan view shows Expected vs Matched vs Unread using the same reconciliation logic as the web platform, compressed into a one-handed mobile layout. Find Item returns product images, SKU, classification, quantity, and price enough context to make an inventory decision without leaving the screen.

The client's revenue for RFID4U was the hardware purchase the software was a delivery mechanism. A focused, constrained application is not a reduced product. It is a more honest one.

TagMatiks went from a feature-complete but cognitively demanding system to one that matched the operational reality of the environments it ran in. Floor workers on RFID handhelds completed primary tasks faster. Inventory reconciliation exceptions surfaced during the scan instead of after it. Enterprise clients with non-standard hardware had a viable software path.

Tracking accuracy improved by 25% post-redesign driven by real-time reconciliation exception surfacing, which eliminated the post-scan investigation cycle that had been masking missing and misplaced assets. Onboarding time for new client deployments dropped by 30%, driven by the navigation restructure and the consistent interaction model across modules.

The less visible outcome was the design system a shared component library and interaction standard that every new TagMatiks module inherited. New verticals, new device types, new workflow modules were added without rebuilding the experience each time.