Group Statistics: Designing for Clear Insights

Ed. note: This belongs to our blog series on the genesis and thinking behind the design of LinkedIn's features. Check out similar posts here.

A month ago we launched our Groups Statistics dashboard to help our users learn more about LinkedIn Groups. In today's post, I'll delve into a few of the design decisions that made the product what it is today.

Genesis of the project

I came to work at LinkedIn because of the enormous potential we have with data. We can provide millions of members with unique insights to advance their careers. With Groups we saw a huge opportunity to make a tool our members could use to find the right groups for their professional development.

Understanding your audience

We can't build a tool that's perfect for everyone, so we have to narrow our intended audience a bit. We targeted this product at members who are looking to join a new group and members who want to gain a better understanding of the groups they are already members of.

While group administrators can benefit tremendously from this same information, we didn't design it primarily for them. This is one of the reasons our Group Stats dashboards are not more densely packed with data; we're aiming to show users the most important parts of the big picture, rather than overwhelm them with details.

Finding the right data to highlight

Choosing which data to surface is one of the trickiest steps. We want to show data that provides insights even in the most general case, and more importantly, wanted to show data that users care about. When joining a group, we know the key elements members care about -- group growth, demographics, and activity -- so we carefully chose to highlight data around those topics.

At the same time though, we had to choose not to show data about other items, such as more detailed trends in volume of job posts, schools members attended, or member age. Though this data is quite interesting, it's not pertinent to our audience and use case.

We assigned a priority to each of the types of data we included, which in turn helped determine the layout. Some very important pieces of data merited a chart (e.g., number of comments over time, which is sustained and substantial in a healthy group) while others (e.g., number of jobs posted last week) only needed a number. Within each tab, we placed data points users want to see first at the top of the page.

Finding the right design fit

We tried many designs until we narrowed in on our final one. I've included a few of them below. You can see that at various times we tried different layouts, typography, and color palettes.

One evening about a month into the project, we decided to scrap everything we had designed previously and start again. This was because we stepped back from the designs and realized that we were crowding the page with too much information, that we'd been designing for a much more technical user than we'd intended. And while it was a very difficult decision to make that evening, I look back on it now and am so glad we have a better product because of it.

Less is More

We aim to keep all of our products as simple as possible. In Group Statistics, this meant showing only the minimal data necessary. You'll notice that we never show more than one chart at a time, only show charts when direct comparison (across time or category) is necessary, and use just one color throughout. We even pared down the chart styles themselves, removing axis and divider lines and axis labels (the content of which is apparent by context alone) in order to de-clutter the page and let the data really shine.

Testing in the real world

When it comes to data, design is more about addressing real data than idealized situations. When we tested our initial designs on real groups, we realized we'd have to make some changes. For example, I had designed the group membership space to accommodate a group size up to 99,999.

But it turns out that we already have groups on LinkedIn with over 100,000 members, and several more about to break the barrier. So we had to adjust the area devoted to that metric and tweak the font size to make it more readable.

We saw this same issue when looking at growth rates for groups: Some groups grow so rapidly (5+ digit growth %) that area and font size tweaks wouldn't cut it; so we added a rocket ship badge for those explosive-growth situations... a badge that will always fit in the space we have. The extra bonus here is that the rocket becomes an award for our fastest-growing groups!

Testing with real data also helped us realize that some groups are not yet ready to benefit from Group Statistics. Some groups are so young that showing trends in their growth and activity don't make sense. So we spent some time honing the rules that determine when a group's statistics get displayed.

Even though we tried to test for all circumstances, we missed a few things. In cases like this, it's often our users who help us improve the product by giving us their feedback. Immediately after we launched the product, some users pointed out that they would like more explanation of the data categories, or a different metric for growth, and even pointed out specific issues with our geographic data that confused them. With this invaluable feedback, we can make future versions of Group Stats more useful.

The rocket ship of virality

When designing most web-based products these days, sharing is key. We want to enable discussions to spring from our data, let you share with friends and colleagues, and generate more interest in groups as a whole.

Our share buttons help users initiate discussions on several platforms. In order to allow users to share Groups data openly, we also made the aggregate data publicly shareable, even if the group itself is not open.

The Team:

This product was built by a team that had to adapt to changing designs and deadlines. I owe major props to Corine Yang for her help with layout and typography. I credit Steve Johnson with reminding us to step back in the middle of the process and ultimately to ensure we were focused on the end-user experience. Numerous developers and engineers - including Dylan Song, Antonio Contreras, Jennifer Tsai, Hans Brough, and Anand Prakash - put every piece of data and every pixel in place. And our trusty Product Manager, Ian McCarthy, continuously cleared the way for each of us to be as productive as possible.

This has been one of my favorite teams to work with, and it's my privilege to keep working with them every day.