Asking UX Questions: Designing the New Relic Browser Breakdown Feature

A couple weeks ago we released a major UI redesign of New Relic’s browser monitoring and front-end development features. This is a story about how the dev team approached the UX for one of those redesigned features: the Browser breakdown tab. Today, the browser breakdown tab looks like this:

New Browser Breakdown Tab

Browser breakdowns weren’t new to New Relic. For a few years, we’ve provided data on which browsers were active on a site, but until a few weeks ago that tab had looked like this:

Old Browser Breakdown Tab

This version of the feature wasn’t heavily used by customers. We know this because at one point a developer accidentally broke the tab entirely and it took over a day for anyone to complain. Our web apps serve thousands of request per minute, but clearly not many of them were going to that tab. Before the redesign we categorized browsers by operating system, browser name, and browser version. For example, we might show a graph that compared response time or throughput for Windows Chrome 28, Mac Chrome 28, and Windows Firefox 27. This approach made it hard to see the forest for the trees — I could easily determine my response time for “Linux Firefox 23.0”, but I couldn’t easily tell if a good iPhone experience was important to my site.

The UX Questions

Our first step in redesigning this feature was to decide what questions our customers should be able to easily answer by using it. We came up with this list:

  1. Which browsers should I care about? (Also, should I be optimizing for the iPhone?)
  2. What’s the difference in page load time between phones, tablets, and desktops?
  3. Do I still need to care about IE 8?

These questions helped us focus on the value we’d be providing to our developer customers and on building the simplest possible interface necessary for these users to reach their goals.

It Fits on a Whiteboard

After we’d come up with the above questions, which we’d use to judge our success, we set to work designing the UI. The feature itself didn’t need to be complicated. We thought the best strategy was to make it easy to answer the common questions developers have about their browser traffic so they would be able to better target their efforts to improve their sites’ performance and experience. Our goal was for a customer to be able to answer those three questions after using the feature for only a minute or two.

Ultimately, we decided not to classify browsers by operating system. We knew from our own experience building websites that there’s not much difference between Windows Chrome users and Mac Chrome users — they’re both using a desktop version of Chrome. So we instead decided to switch to categorizing browsers by device type first (Desktop, Tablet, Mobile) and only then by browser name (Chrome, Firefox, etc). We’d also create the ability to drill down into the version breakdown of a specific browser (IE 8, IE 9, IE 10, etc.) Because we thought our customers would usually have questions like “how much is this browser used?”, we emphasized throughput numbers, over response times, in the UI.

The result of our planning was a whiteboard drawing that looked like this. It shows the browser breakdown overview page and the drill-down for a specific browser (e.g. Internet Explorer).

Whiteboard Design

I talked through the design with one of the engineers on the team, and together we sorted through some details and questions about how it would work.

The Answers

A day or two later we had an awesome new Browsers tab, which I now use all the time to better understand how people use my sites. I sleep soundly at night knowing I can easily tell you which versions of iPhone Safari are the most important for me to test against.

Mobile Safari

Jose, who wrote most of the code, may have put it best when he wrote this on the feature ticket:

  1. What browsers should I care about? (Also, should I be optimizing for the iPhone?)
    I was surprised to find that Mobile and Tablet traffic on the site is less than for 1%… so no, we shouldn’t be optimizing for iPhone. We couldn’t answer this question before.
  2. What’s the difference in page load time between phones, tablets, and desktops?
    Page load time for tablets is less than or equal to desktops (nice surprise here). Mobile page load time is about twice the desktop time – but #1 tells us that we shouldn’t care about it.
  3. Do I still need to care about IE 8?
    Nope. It’s barely noticeable in the version breakdown for IE.

Try it out for yourself! There’s more details on this feature in this doc, and you can learn more about our New Relic Browser product in our announcement here.

If you have any feedback or questions for us about this or our other Browser features, let us know in our new forum for New Relic Browser.

Sam Goldstein is engineering manager, agents, for New Relic. He manages Browser Application Monitoring team. He's been writing Ruby for almost a decade and is the author of several semi-popular gems, including diffy and timetrap. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!