Blunt truth time: The real-life users of a data product really don’t care how a product team intends the application they’ve painstakingly researched, deliberated and laboured over to be used.
Chances are they don’t even think about the fact their favourite tool has a product team behind the scenes. And that’s not a bad thing!
We’ve all heard the truism about good UX being invisible, right?
When it comes to the complex platforms we typically work with, the average user’s priority is the masses of information they can gain access to, not the interface that sits atop it. As long as they’re able to grab what they need relatively painlessly, then happy days.
And even if a product team thinks they know exactly the path that’s needed, the people they’re designing for are likely still hacking some downright unexpected routes to their desired outcomes.
Accidental gamification and the unpredictable nature of product development
When we designed a tool for an insight giant, we didn’t expect their researchers to use it like this!
What do you mean by ‘hacking’ a data product?
It’s probably worth explaining at this point what we mean by ‘hacking.’ Of course no-one’s suggesting product teams should welcome black hats in to compromise their software and leak sensitive info.
That would be bonkers, obviously.
Instead we’re talking more about what Ipsos MORI director Duncan Fergusson calls ‘lead-user innovation’ when he describes…
Observing how users at the leading edge of categories develop solutions, or hacks, to meet their needs better.
What makes users hack a data product?
Users perform hacks when they come up against limitations that prevent them completing the goals they need to achieve within a tool.
When we’re talking about a data product, we could reasonably expect these needs to focus around surfacing the type of content they need.
Complex search UX
Search is a massively complex area for tools that handle a lot of data. It’s something we’ve taken a deep dive into recently in another article and there’s a ton more to say about it still.
The complex task of designing search for data heavy products
We take a look at three major reasons that designing search is one of the biggest UX challenges out there.
Taking a good look at the ways users are searching may well give product teams some clues into hacks that are taking place there because of UX design problems.
- Are users finding that repeated specific searches give them what they need more easily than performing a broad search then filtering the results? If so, revisiting the platform’s capabilities for sorting through data is probably necessary.
- Are they using boolean operators, or trying and failing to do complex database queries with a search function that lacks that power? If the search function is being used as a means to manipulate data, there’s likely an appetite for the tool to expand here.
- Are they hacking search to help them find their way around the platform because there are problems with its navigation and entering a query is simpler?
- Are results presented in a way that makes them easy to interpret, or are users having to deploy a hack to fit everything on the page, for example?
Why is finding out about hacks helpful?
Learning how users are bending or expanding on a platform to more fully meet their needs means you’re learning more about both users’ behaviour and the product itself.
Just because you planned for something to be used in a particular way doesn’t mean that there isn’t value in people using it differently.
Knowing these insights allows a product team to make intentional decisions around actual user behaviour rather than being left in the dark.
With an understanding of the entire journey of the data provided, from being needed to the decision it informs, it’s possible to pick which part of the journey the product fulfils and which it doesn’t.
Ultimately, there’s likely to be a decision to make as to how much functionality it’s feasible to provide in light of this knowledge.
For example, product teams may find themselves making a call as to whether they try and keep a maximal number of users in their product for data analysis by providing more powerful manipulation capabilities, or whether instead to make a conscious feature of the data’s ease of export.
Similarly, it’s worth taking into account which user types to prioritise. Making substantial feature changes because a small subset does something unique is probably not a worthwhile business decision.
A focused product will always enjoy more growth and be more successful than an unfocused one.
People take their activities outside of the platform because their hacks are easier to use and fulfil their needs, despite the original tool’s dataset being top class.
A strategic decision that mitigates against that in a way that’s feasible to deliver will keep them onboard.
Learning about user behaviour
So, how should a product team get worthwhile information into the hacks users are deploying?
The possibilities for tracking user behaviour and learning what people are actually up to within a platform (and identify the points where they step away from it) are almost limitless.
We talk all the time about the importance of rigorous user research and learning directly from users (no, really, it’s constant), but a smart mix of statistical insight and knowledge straight from the users’ mouth is going to be most effective here.
It’s something we’ve written about in some detail previously – including a surprising discovery when we married the two for data giant IJGlobal.
Stats don't lie - backing up user research with analytics to reveal the whole truth
Learn all about coupling user research with hard data to validate assumptions.
In brief, people will say one thing when asked about their behaviour, but sometimes end up doing something quite different.
There are a ton of top tools out there to help gather statistical insight. Our pick is Heap for understanding user journeys, as well as the OG Google Analytics still being a reliable place to start.
Add some behavioural research such as heat mapping ( we rate Hotjar or Mouseflow) and/or eye tracking (take a look at Tobii or Gazepoint) technology into the mix, and there’s so much to discover.
However, we’d definitely advise product teams to be a bit strategic here and set some KPIs and expectations before installing anything. It’s all too easy to drown in data by turning every possible product on at once (trust us, we’ve done it. 🤯).
It’s way more effective to focus on one area at a time, collect sensible data and be methodical in using it.
Every data platform on the market is likely to have users deploying hacks and unexpected techniques to make it best fit their needs.
This isn’t a failing, it’s simply a fact about what happens when digital tools get into the hands of real people.
A smart product team will want to find out about these hacks in order to capitalise on them and the opportunities they present.
Whether that means refining the product’s functionality and features, backing up existing research or validating assumptions, a wide range of tools are out there to make gathering worthwhile insights both simple and actionable.