Pie Charts - Great for Hiding Information

/

Part of the job of product managers (or anyone in business for that matter) is to communicate data.  "How good is this thing?"  Often, people use pie charts to communicate this data in dashboards or presentations. Why do people do this?  

Part of the job of product managers (or anyone in business for that matter) is to communicate data.  "How good is this thing?"  Often, people use pie charts to communicate this data in dashboards or presentations. Why do people do this?  

As Stephen Few (guru on dashboard design) says:

The truth is, I never recommend the use of pie charts.  ...  Pie charts don't display quantitative data very effectively.  Humans can't compare two-dimensional areas or angles very accurately.

And he's right.  This is an example I pulled from one of our recent internal dashboards.  The problem with this pie chart is that you can't really tell, without reading the numbers the relative size of the pies.  Is the 9.6% slice smaller than the 10.3%?  Is the 22.7% slice double the others or 3x the others?  

You should be able to look at a graph and QUICKLY see the relative comparison without having to read the numbers.  

A better of use of this would be a bar or column chart.  Without the % called out, I can much more quickly see relative size in the bar chart example below.  

Now, I actually disagree with Stephen Few in one respect.  There are cases where you SHOULD use pie charts.  You should use pie charts to hide information.  If you don't want your user to immediately know the differences in values because you want to minimize that particular data point then by all means, use pie charts.  And I'm being honest when there are cases where this can be useful. You may really want your audience to focus and understand one data point, and not pay attention to this other one (if the "other one" is required to be there).  In which case, use a pie chart for the "other one".  This will help make sure they focus on the metric you really want them to be looking at.  Of course, it is best if you can not include the "other one" metric in the first place.  But that isn't always feasible.  

Now, I actually disagree with Stephen Few in one respect.  There are cases where you SHOULD use pie charts.  You should use pie charts to hide information.  If you don't want your user to immediately know the differences in values because you want to minimize that particular data point then by all means, use pie charts.  And I'm being honest when there are cases where this can be useful. You may really want your audience to focus and understand one data point, and not pay attention to this other one (if the "other one" is required to be there).  In which case, use a pie chart for the "other one".  This will help make sure they focus on the metric you really want them to be looking at.  Of course, it is best if you can not include the "other one" metric in the first place.  But that isn't always feasible.  

I know that the topic of use of "Pie Charts" isn't world changing.  Really, this post is about communication.   The small stuff does matter in communication.  Is showing the value of your product important?  YES!  Get it right.  Spend time on it.  

A/B Testing Post from 37Signals

/

I found this post from 37 Signals to be an interesting viewpoint on testing.  It is about the process, not about the outcome.  

 

I only judge a test based on whether we designed and administered it properly.

As an industry, we don’t yet have a complete analytical model of how people make decisions, so we can’t know in advance what variations will work. This means that there’s no shame in running variations that don’t improve conversion. We also lack any real ability to understand why a variation may have succeeded, so I don’t care much whether or not we understood the results at a deeper level.

The only thing we can fully control is how we set up the experiment.....

 

See more at...  http://37signals.com/svn/posts/3169-ab-testing-its-not-about-the-results-and-its-definitely-not-about-the-why

Dam Breaks

/

We completed a big successful product launch.  There was massive alignment across the organization to get this product out.  When you have that kind of alignment, it tends to push all other requests and ideas off the table for a while.  This is a great thing to make sure you keep the momentum and success of the big launch.  

However, the moment we finished the big product luanch, the rest of the ideas came rolling back in.  A lot of them.  The dam broke and everything and everyone tries to take vie for position to be top priority.  This includes small things and big things.  We have the capacity to do about 3 big projects, and we are seeing about 8 big projects trying to get top spot.  Me and the team are trying to manage through all this.  Set priorities, expectations, and lots and lots of milkruns.  Some of this is resource constraints.  Some of it is just mind-share constraints.   

Eventually we will manage ourselves to the next big product launch, get alignment, and build the next big dam.  I do always find this por