Original article posted on Medium.
While working on a project earlier this year, an interesting tidbit emerged from research: users tended to have just a few simple needs when it came to accessing data. Given that the tool we were working on is pretty robust, the lightweight nature of the most common use cases was a surprise… there is more “tool” available than what is necessarily needed.
This reflects a broader trend among analytics providers: there’s a popular interface-first reflex when it comes to building data products. We opt for flexibility over convenience, often attempting to satisfy all plausible use cases rather than optimizing for the most frequent ones. Here’s an outline of some analytics use-cases, addressed in a one-size-fits-all way:
The approach is, in a way, straightforward. Give the user access to the data. If they have a question, they can go to the interface and “tell” it what they need. They then digest the information, isolating some meaningful insight (hopefully) before disseminating the information to their peers, supervisors, or other stakeholders.
The interface-first approach is capable of satisfying many use cases for end users. Analytics tools can be used for all sorts of purposes — from status updates to fact-finding to open-ended exploration — but it’s not unusual to see a user base rally around a few lightweight ones (hint: open-ended exploration is usually not among them). Let’s think through a simple use case: a gym owner wants to know if member attendance has changed this week, as weather has been especially nice. Here’s how that scenario looks for an interface-first analytics tool:
Taking a look at different approaches to analytics products: interface as a "tool" vs technology as an "assistant." Inspired by research done in the field.