{"id":7233,"date":"2015-03-09T16:00:38","date_gmt":"2015-03-09T23:00:38","guid":{"rendered":"http:\/\/intercom.com\/blog\/?p=7233"},"modified":"2020-07-30T13:02:23","modified_gmt":"2020-07-30T12:02:23","slug":"design-principles-insights-are-not-about-analytics","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/design-principles-insights-are-not-about-analytics\/","title":{"rendered":"Design principles: insights are not about analytics"},"content":{"rendered":"

Anywhere there are numbers in a product, users will eventually ask for them to be visualized, but to do that effectively you have to understand how those visualizations will be used. People ask for \u201canalytics\u201d, but what they really need to do their job are insights.<\/p>\n

Ever since we launched a shared inbox<\/a>, we\u2019ve been getting feature requests that fall into the blurred category of statistics\/analytics\/visualisations. Inbox Insights is our response and we\u2019d like to share some of the design process and principles that informed it.<\/p>\n

Supporting your customers with Intercom is different to traditional support platforms; it\u2019s about conversations with customers rather than creating, tracking and closing tickets. But this shift from tickets to conversations doesn\u2019t change the questions that people running support teams have. For example: Are you good at getting back to your customers? How do you measure team performance? Are you being efficient with your resources? How busy are you? Who are your most productive team members?<\/p>\n

Answering these questions adequately means making sure you are tackling the right questions, and that you\u2019re answering them in the right way. Put simply, you have to get the right data, and then get the data right. Right?<\/p>\n

Applying the Jobs-to-be-Done theory, rather than creating archetypal customer personas, we try to understand what motivates customers to use Intercom and what jobs they are addressing with the product. This practical implementation of Jobs-to-be-Done helps us to create what we call a Job Story<\/a>.<\/p>\n

Understanding the Job to be Done<\/h2>\n

Most of our requests from customers simply listed metrics they wanted to see – things like conversation volume, response times, how many conversations they had answered as a team, and per teammate, etc.<\/p>\n

It\u2019s the nature of feature requests to contain the what, but not the why. \u00a0But without understanding the why, you risk building an incoherent set of features that address very specific use cases or the needs of vocal customers, without solving the real problems that are common to the majority of your user base.<\/p>\n

In this case we could have simply started spitting out the metrics requested, but we fought to understand how these numbers were being used within a business. We knew we had to dig deeper so we went back and talked some more to our customers.<\/p>\n

The project brief<\/h2>\n

As we outlined previously<\/a>, we start building product by writing the Intermission, a single page that describes exactly what problem we are trying to solve and why, and sets out the job story. The Intermission is the mission statement for the project, which is the benchmark for evaluating all our design work and ensures we never stray too far off course.<\/p>\n

For this project, our Intermission looked like this:<\/p>\n

Problem : Our current product doesn\u2019t surface quantifiable information about inbox activity. People who manage support teams have no way of seeing how many conversations they are having with their users, or how busy their team are. \u00a0Our opportunity is to motivate communication by showing aggregates and trends over time, showing admins an overview of team performance, and helping them predict how they might grow.<\/i><\/p>\n

Below are the main Job Stories we identified from talking with our users:<\/p>\n