Finding the real problem with ON!Track's storage assets

The Problem

Storage assets had a reputation inside the ON!Track team as a source of bad UX and of churn, but nobody could say how bad, for whom, or whether fixing them would matter more than anything else on the roadmap. The team set four questions. What do customers need from storage assets, and where does it hurt? Which usability issues exist, how severe are they, and are there any the team didn't know about? Is fixing storage assets enough, or do related areas such as the asset list, quantity items and the location hierarchy need to be in scope too? And are storage assets being used well in the van-gateway tracking flows and the enhancements planned next?

The work was scoped to the problem space only: no concepts and no solution testing. That let the findings, not a favorite solution, decide what came next.

Research Principles

• Understand the problem before designing for it. The team could prioritize precisely only once the issues were mapped.
• "Not worth solving" is a result too. A counter-intuitive success would be learning that storage assets mattered less than other topics, and moving on.
• Connect it to the business. Without a link to revenue or another business metric, there is no way to size the investment or measure the impact of any change.

Four Methods, in Order

I combined three qualitative methods with one quantitative one, and ran them so each fed the next. Interviews with internal specialists came first: they are the fastest way into a problem space and they sharpen the questions for customers. But specialists are a step away from the customer and can bring their own assumptions and ideas, so customer interviews came next. An expert evaluation then consolidated earlier evaluations by product owners, product managers and designers, and followed up everything the interviews raised. Finally, a hypothesis-driven analysis of storage-asset data across Hilti's market organizations tested what the interviews suggested.

The option I didn't take was to rely on the data alone. It can show what is happening, but not why people behave the way they do. That takes talking to them.

What the Specialists Said

ON!Track specialists implement the product with customers and support them afterwards. I interviewed four specialists and a product manager from Great Britain, Finland, Denmark and Sweden, an hour each, and asked them for blunt feedback to counter friendly bias.

All five said the same thing: storage assets were not a top-half issue. What customers wanted was automation: Bluetooth tags, gateways, automatic transfers. Every specialist had reached that conclusion independently, and customers paid a premium for it. Almost every one of them had also tried setting up a toolbox as a storage asset, and each had decided it wasn't worth the effort, mainly because batteries get swapped between tools rather than transferred.

They still named plenty of storage-asset issues: the contents are hard to view, navigating back from them is confusing, and selecting a storage asset when adding or transferring is often overlooked. What matters also depends on the type. For a van, the responsible person matters most; for a container, the location. Browser back navigation, which lost the user's place and scroll position, hurt both efficiency and sentiment.

What the Customers Showed

I then interviewed five users at two infrastructure companies in Canada: three warehouse managers and two back-office managers. They confirmed that storage assets weren't their biggest concern, and showed why the feature still mattered: as built, it could not be used successfully.

When one customer found a storage asset through search or a filter and selected it, the contents didn't transfer with it, and it wasn't clear what had been selected. The workaround they built cost six months of effort during their migration, left them with no trust in the system and a very negative view of the new version of ON!Track. Their specialist saved the relationship.

The workarounds said the rest. One customer tagged the expensive item inside a kit instead of the kit. Another used the notes on an excavator to record which buckets and loaders belonged to it, so search would find them together. That relationship is exactly what a storage asset is for. Accurate records mattered to these customers because they account for where equipment has been for regulatory audits, where mistakes cost money. They also explained why records drift: unless it's enforced, people avoid transferring tools to themselves so they aren't accountable for anything lost, broken or dirty.

One Root Cause, Eight Symptoms

Transfer is one of the primary jobs of ON!Track, and before transferring anything you have to be sure you've selected the right thing. Walking that path with a storage asset turned up eight problems, each of which had been reported before as a separate, minor issue:

1. You can't see everything inside a storage asset in one place. Checking its contents takes you to another page, and coming back loses your selection and your place.
2. The number of stored assets on the list card doesn't match the number in the details.
3. Duplicate template images make storage assets hard to tell apart.
4. It isn't clear what is selected, and selection behaves differently in browse and in search.
5. Even with the right selection, not all the contents transfer.
6. After a transfer, it's hard to confirm it worked; the current location doesn't always update.
7. When receipt must be confirmed, the recipient can't confirm or reject the contents.
8. The result is asset costing that is probably inaccurate, and at best hard to trust.

Specialists and customers could each describe symptoms, but neither could see the cause restricting what they wanted to do. Treating the eight as separate bugs would have fixed each one and left the workflow broken. Treating them as one problem made the severity clear: sentiment, time lost to migration and use, and a higher chance of churn.

What the Data Said

To test what the interviews suggested, I defined the variables and ran five hypotheses against storage-asset data from Hilti's market organizations. Exposure meant a customer had at least one storage asset, and adoption meant more than three. Market size and maturity was the number of ON!Track customers in the market.

Three hypotheses held: larger, more mature markets had more exposure and more adoption, and customers who had used ON!Track longer tracked more assets. Two weren't supported: that larger markets are better at converting exposure into adoption, and that customers add more storage assets the longer they use ON!Track. Adoption followed exposure, not time.

Adoption rose with market size, from 21% of customers in the smallest fifth of markets to 41% in the largest. That gave a benchmark of 41%, with 46 markets below it. The markets with the highest adoption were New Zealand, Ireland, the Netherlands, the United Kingdom, Denmark and Germany, all at 50% or more. The cheapest lever wasn't a redesign: it was making sure customers were shown the feature at all, and asking the leading markets how they did it.

The data also raised the larger question, which it couldn't answer: does it matter? Unless storage-asset adoption is tied to a business outcome, pushing it onto customers may not be the right call.

Prioritizing 25+ Issues

Not every issue needed the same response, so I scored each one on two axes. Effort was four points, one for each thing it would need: further research, concept designs, concept validation and an A/B test. Zero to two points was low effort, three or four was high. Severity weighed how often the issue occurs, how many customers it could affect, its impact on sentiment, and whether it sits on a critical path.

The matrix gave the team four buckets: 5 quick wins, 13 major projects, 8 fill-ins and 3 thankless tasks. The quick wins and fill-ins needed no further research and little design effort; some were bugs that could simply be fixed. For the major projects, I recommended that anything touching a critical path, such as selection, ship as an A/B test, so a significant change could be shown not to be worse before full release.

Recommendations

Evaluate the issues against the rest of the ON!Track roadmap, and use the matrix to decide what earns time next. Before investing in the major projects, establish whether storage-asset adoption correlates with revenue or another business outcome. If it does, the 41% benchmark becomes a target for each market, and a way to see which markets can teach the others.

To measure any change, set a baseline and watch the trend. The report listed candidate metrics: subscription upgrades, tool sales, churn, the conversion and adoption rates, NPS and CSAT, app store ratings and support tickets that mention storage assets. The one most likely to move first is the time between exposure and adoption, which changes in days or weeks. Churn moves on a contract cycle of years.

What Came Next

I presented the results to the ON!Track team in July 2023, with a detailed report, a spreadsheet of every issue, and Figma references showing each one in the product.

The research then fed straight into design. I sketched concepts for the two problems at the center of it: whether to show assets as a nested or a flat list, and how to show which assets sit inside which. In the concepts, the main asset list stays flat. A storage asset's details show what it contains, and a stored asset's details show what it sits in. Selecting a storage asset selects its contents too. The sketches later became Figma designs and prototypes.

What I'd Do Differently

Recruit more customers before starting. We could only schedule two customer interviews, which leaves room for sample bias. I would secure at least five before the research began, and fix the recruiting process that made two the limit.

Answer the business question first. The research framed the question of whether storage assets affect revenue or churn from the start, but finished with it still open. I would get that correlation from the data before the interviews, so every finding could be sized as it came in.

Watch the work, not just hear about it. A full day of contextual inquiry with warehouse managers, plus session recordings and funnels from a behavior-analytics tool, would have shown the path I reconstructed from interviews. I would also have separated web and mobile from the start, rather than relying on customers to say which platform an issue was on.

Credits

Jussi Silfver: ON!Track Software Product Manager
Kelvin Dsouza: ON!Track Product Owner
Boris Milutinovic: ON!Track Design Manager