Insights
Not on its own. Heavy use shows something is happening, not why: value, a forced path, retries or a workaround. How to check before you invest. When Google researchers Kerry Rodden, Hilary Hutchinson and Xin Fu introduced the [HEART framework for user-centred metrics](https://research.google.com/pubs/archive/36299.pdf)
Not on its own. Heavy feature usage tells you that something is happening around a feature, not why. People may use it because it does the job well, or because it is the only route the product leaves them to something it does not let them do directly: exporting to a spreadsheet because reporting is weak, re-running a search because the results are poor, duplicating a record because editing it feels risky. Before you read your most-used feature as your strongest one, find out what is driving the numbers, and the most direct way is to watch and talk to the people producing them.
What a usage count can and cannot tell you
When Google researchers Kerry Rodden, Hilary Hutchinson and Xin Fu introduced the HEART framework for user-centred metrics at CHI 2010, they warned that a rise in page views for a feature may mean it is genuinely popular, or that a confusing interface has users "clicking around to figure out how to escape". Search research agrees: in their CIKM 2013 study of search satisfaction, Ahmed Hassan Awadallah and colleagues at Microsoft note that a user who clicks can be dissatisfied and one who does not click can be satisfied.
At least one analytics vendor has revised its own measure on similar grounds. Pendo used to define adoption as the share of features that generate 80% of clicks, and in a January 2021 post explained why it replaced that definition: it measured how concentrated usage was, not whether that usage was meaningful. A guest on our first podcast, Mastering Design Decisions (August 2023), put the practical consequence plainly: the factors behind the data have to be investigated before the data can validate anything.
So a usage count is a good question and a weak answer. It tells you where to look.
Six readings of a heavily used feature
A spike or a plateau in one feature's usage can have at least six explanations. They are not exclusive, and the signals below are prompts to investigate, not proof.
| Reading | What is going on | Signals that help separate it |
|---|---|---|
| Value | The feature does the job people came for. | Use spread across many accounts, steady return over weeks, and the next event is an outcome (saved, shared, sent) rather than another attempt. |
| Habit | People use a familiar route they learned first, though a better one exists. | Longer-standing users concentrate on it while newer users take a different path to the same result. |
| Forced path | It is the only way through a step, so everyone passes through it. | Close to every session in a flow touches it, and its volume tracks the upstream task rather than choice. |
| Workaround | People bend the feature to do something the product does not support directly. | Unusual sequences, such as an export straight after viewing a report, or a duplicate followed by deleting the original; support questions that begin "how do I". |
| Failure and retry | The feature does not work first time, so people repeat it. | The same action repeated within seconds or minutes, errors logged around it, and similar searches re-run within a few minutes, which the Microsoft study above treats as a sign of dissatisfaction. |
| Misuse | The feature is used for a purpose it was not designed for, sometimes with risk. | Content that does not match the field's intended format, such as structured data typed into a notes field, and data quality problems further down the line. |
Session-level signals help with the failure-and-retry reading. Microsoft Clarity's documentation, for example, describes rage clicks (repeated clicks in one area in rapid succession) as strong indicators of user frustration, and dead clicks (clicks that get no visible response) as a sign of a poor experience. Two cheap checks cut across all six readings: how much of the volume comes from a small number of accounts, and whether the usage started on a release date, a pricing change or a customer's onboarding.
How to check a usage spike before you invest in it
The method starts with the numbers and uses UX research to explain them. Methodologists call this order a sequential explanatory design: quantitative data first, then qualitative data in a second phase that helps explain the results of the first (Ivankova, Creswell and Stick, Field Methods, 2006).
- Describe the anomaly precisely. Which event, how many users and accounts, since when, and what share of the volume comes from the top tenth of accounts. "Reports are popular" is not yet a finding; "exports from the monthly report rose after the March release and come mostly from finance users" is.
- Write down the competing explanations before you look further. Take the six readings and, for each, note what you would expect to see if it were true. This stops the team looking only for evidence of the explanation it already prefers.
- Check the sequences. Look at what happens immediately before and after the feature in the same session. Repetition, a jump to export, or a return to the same screen a minute later each favour a different reading.
- Watch a sample of sessions. Recordings show what people did, including hesitation and repeated attempts, but not what they were trying to achieve.
- Talk to a handful of the heaviest users, and watch them work. Ask each to show you the last time they used the feature on a real task. The heaviest users may have found an uncommon route that works, or be the people most trapped by a gap. Public health has a name for learning from the first group: the positive deviance approach, as described by David Marsh and colleagues in the BMJ in 2004, identifies four to six people who achieved an unexpectedly good outcome despite high risk, then interviews and observes them. Include one or two light or lapsed users for contrast.
- Test the explanation small before you commit. Change the feature for a subset of users, or for one segment of accounts, and see whether the numbers move the way your explanation predicts before you redesign it for everyone.
The order can also run the other way. In our Eden AI work, the problem was raised repeatedly in the client's user feedback sessions and then confirmed with analytics and session recordings, when only 6% of users were able to create workflows. What matters is that the qualitative and quantitative evidence end up describing the same thing.
What to do with a workaround once you find it
Workarounds are a studied subject, not just an annoyance. Steven Alter's Theory of Workarounds (Communications of the Association for Information Systems, 2014) treats them as goal-driven adaptations people make to get past obstacles in a work system, and notes that they can grow into larger planned changes to the system itself. There are three sensible responses.
Build it in, when the workaround is the feature people need. Retweeting began as a user convention: people copied a tweet, credited the author with an @mention and marked it as a retweet. In August 2009 Twitter co-founder Biz Stone announced plans to build it into the platform, calling the manual process "a bit cumbersome". Watch how people do it before you formalise it, though: Stone's sketch passed the original tweet on with a "retweeted by" attribution, and people who wanted to add their own words kept pasting the tweet's link into new tweets until Twitter launched retweet with comment in April 2015.
Design it away, when the workaround carries cost or risk. A study of barcode medication systems in US hospitals by Ross Koppel and colleagues (JAMIA, 2008) found 15 types of workaround with 31 types of causes, including scanners that failed and wristbands that could not be read. In one, copies of patients' wristband barcodes were fixed to carts, door frames or nurses' belt rings, so scans could be made without scanning the patient. The authors note that the system's override data did not directly reflect how often workarounds occurred, and they combined observation, shadowing and interviews with those logs. They recommended addressing causes in the technology, the task, the organisation and the environment, not only staff compliance, so that the safe procedure is easier than the workaround.
Leave it alone, when it is cheap, safe and rare. Some workarounds cost the people using them a few seconds and nobody else anything. Note them, and spend the effort where the gap is common or the risk is real.
Two questions decide between the three: is the need behind the workaround legitimate and shared by many users, and what does it cost in time, errors or risk?
Where usage data fits in a product decision
Usage data validates or kills an assumption only once the factors behind it are understood. Until then, a heavily used feature is a candidate for investment and a candidate for redesign at the same time, and the numbers cannot say which. If the question is broader than one feature, our guide to using a UX product audit covers how analytics and expert review are combined across a product.
