Article: Charting with Outcomes in Mind
With everyone having access to Excel, Tableau, Power BI, Alteryx, etc. charts are more and more commonly displayed during meetings and in tools. The downside of everyone making charts is that many of these charts aren't very good. They don't have a reason for being, and the viewers most often don't understand what they are expected to do with those charts. This article describes the process I use to design charts that make a meaningful contribution to achieving intended outcomes.
This article is a worked example of how I created the charts and analytics in "Blocked" my new blocker and dependency management tool. I used this process to drive all of the product decisions, and want to share the process in case you find it useful.
1. START WITH OUTCOMES
Before touching the data and charting tool, you need to have an outcome in mind. The biggest failure in charting is not knowing what you want to achieve by charting that data. The viewers gaze longingly at the beautiful lines you drew expecting divine inspiration to hit them, and action to follow. When you get someone's attention, make it count. If you don't know what you want, the viewer won't either. Start by coming up with your intended outcomes.
When designing "Blocked" the blocker and dependency management application I started with the following outcomes in mind -
2. WHAT DECISIONS WILL CAUSE THOSE OUTCOMES
- Lower work item and feature delivery lead-time
- Fewer Blocked items
- The smoother more predictable flow of items
From the listed outcomes, I created as many decisions as I could that if people made (well) would cause those outcomes to be more likely. It's hard, you have to put yourself in the shoes of the other people, and think, what do I need them to decide to do as a verb to reach those outcomes. Asking them what decisions they make day to day now, or observe the decisions they make in meetings will give you a starting point.
For the "Blocked" outcomes, here is the list of decisions I came up with -
3. INSIGHTS TO MAKE THOSE DECISIONS
- To unblock blocked work faster by taking action
- Fix the causes of blocked items to avoid them in the future
Thinking from a decision perspective, what insights/AHA's do those people need to see in order to make that decision. What information if they knew, would cause the decision to be made. If you are following, you can probably pick-up that the job of our charts is to make these insights UN-MISSABLE and OBVIOUS. Anything that doesn't support the viewer seeing these insights is noise and likely impeding seeing the intended insights (doing more harm than good).
For "Blocked" here are the insights I thought supported the decisions -
Phew. That's a lot of insights. I find for most decisions people make they draw on two to three sources of insight, so I keep brainstorming until I get 2-3 insights per decision, so we are about right with six insights. Now. we can think of charts!
- I need to know I'm blocking someone
- I need others to know I'm blocked
- I need to know when a blocker affecting me is resolved
- We have an abnormal number of open blockers
- What blocker is most urgent to resolve next
- The most common and impactful causes of blockers
- Did our process changes make an impact on reducing blockers?
4. DATA AND MEASURES
We are now at the first responsible moment to think about charts. The ONLY goal is to build a chart that makes the chosen insights obvious. You might need to find a way to capture that data (or at least a sample of the data) required to show those insights. In the case of "Blocked" I didn't find this data accessible in Jira or Azure DevOps, so decided to offer one. And then, and only then could I chart that data to show these insights. But, by knowing the insights that mattered, I simplified data entry to JUST NECESSARY to build the charts.
My measures were -
1. Blockers ON MY team and because of MY TEAM
2. Blocker urgency and age
3. Blockers in progress trends
4. Blocker causes by quantity and impact
5. What teams depend (block) on each other the most
HOW DO YOU CAPTURE THIS DESIGN PROCESS
I use a simple post-it note Miro or physical canvas. I put Outcomes - Decisions - Insights - Measures as titles, and start from the outcomes. Here is my canvas for "Blocked" the app.
In "Blocked" it's going to take some time to give every insight its day in the sun, but I've made a start with the following charts in the analytics tab. I like to think my development methodology was INSIGHT-DRIVEN-DESIGN, and hopefully, you will now understand how I linked the analytics to outcomes.
Firstly - a chart wasn't the right tool for the insight, what blockers should I resolve next, a list was needed. So, all open blockers filtered by the team are sorted top to bottom by urgency and age -
Seeing the trend of open and resolved blockers over time for a team gives the insight, "is this week abnormal," I chose a simple column-chart trended over time, color-coded by "age" so the teams can see if blockers are not being resolved in the usual lead-time.
And the determine what reasons work is blocked, I used a slope-graph that gives ranking and CHANGE over a time period (this case monthly). If a process has changed, I'd expect a decrease in impact by the tags associated with that cause/fix.
As you can see, the process for designing charts needs to have an outcome in mind before we start doodling with charts. You need to consider exactly what insights to highlight so that people make better decisions. Leave out anything that isn't related to insight, and charts begin to be useful.