Good Charts: Turning Visuals into Strategic Tools (Not Just Pretty Pictures)

In most game and software organizations, charts are everywhere—but insights are rare.

Sprint reviews, dashboards, KPI decks, bug triage meetings, monthly exec updates—we’re all looking at charts. But too often, those visuals either confuse the room, get politely ignored, or require a five-minute voiceover to explain what’s going on. The result? A team that stares at data but struggles to act on it.

That’s the gap Good Charts by Scott Berinato is built to close. His message to leaders is direct: if you want to lead with data, you can’t just present charts—you have to design meaning.

This book isn’t a “how to use Excel” manual. It’s a guide for thinkers, strategists, and operators who need their charts to make people understand, decide, and move.

Here’s how Berinato breaks it down—and how you can apply it immediately in a game or software development context.

There Are Four Types of Charts—Know Which One You’re Making

Berinato introduces a simple but powerful framework. Every chart falls into one of four types:

• Declarative and Conceptual – You’re explaining an idea or framework (e.g. a vision, a pipeline model, a user journey).
• Declarative and Data-Driven – You’re presenting known data to make a point (e.g. a release summary, retention curve, P1 bug rate).
• Exploratory and Conceptual – You’re thinking through possibilities or mapping ideas (e.g. postmortem diagrams, team accountability models).
• Exploratory and Data-Driven – You’re digging through metrics to find a pattern (e.g. telemetry dives, A/B results, churn analysis).

Dev Application: When you're building a chart, stop and ask: “Am I explaining or exploring? Am I showing an idea or showing data?” That decision changes everything about how you design, label, and share.

Good Charts Are Intentional, Not Just Informational

Most charts fail not because the data is wrong—but because the design is random. People pull whatever chart type looks nice or fits in the template and hope the meaning will emerge.

Berinato’s advice? Don’t start with the chart. Start with the point.

If your message is “retention dropped after Day 3 due to tutorial confusion,” the job of the chart is to support that message—clearly, visually, and immediately.

Dev Application: In every review deck or dashboard, label your chart with the insight, not the metric. Title it: “Day 3 retention drop tied to tutorial bounce” — not “30-Day Retention by Feature Use.”

Use Visual Hierarchy to Guide the Eye

Our brains don’t scan charts randomly. We follow visual cues—what’s big, bold, bright, or distinct. That’s called visual hierarchy, and it’s your superpower as a communicator.

Good charts don’t just present data—they direct attention.

Dev Application:

• Use bold or color to highlight the key trend line.
• Dim irrelevant data.
• Annotate the spike, drop, or change.
• Use arrows and labels to show “why this matters.”

Don’t just display information. Guide your viewer through a journey—fast.

Think in “Story Arcs,” Not Data Dumps

Data doesn’t land when you present it all at once. It lands when you pace it. Berinato recommends shaping your visual message like a mini-story:

• Set the context (What are we looking at?)
• Highlight the change or insight (What just happened?)
• Explain why it matters (So what?)
• Point to what’s next (What should we do?)

It’s not about making your charts theatrical—it’s about making them usable.

Dev Application: In a sprint review, don’t walk through every chart in order. Instead, guide your team: “Here’s the change that surprised us. Here’s what we think is behind it. Here’s the next step we’re proposing.”

Most Business Charts Are Too Simple—or Too Complicated

Berinato makes a great observation: bad charts fall into two traps. They’re either:

• So basic that they say nothing new (e.g. a bar chart with five unremarkable numbers).
• Or so dense that no one knows what to do with them (e.g. a spaghetti graph of bug reports by region by platform by sprint).

The goal is the sweet spot: a chart that’s simple enough to grasp, but sharp enough to say something.

Dev Application: Before sharing a chart, ask yourself:

• “Is this obvious?” If so, cut it.
• “Is this overwhelming?” If so, simplify or break it up.
• “Does this make a point?” If not, you don’t need it yet.
  
  

Use Sketching as a Thinking Tool

One of Berinato’s most actionable tips: start with a sketch. Before you open PowerPoint, Tableau, or Figma, draw what you want to show—by hand.

Sketching helps you figure out what matters, what to emphasize, and what kind of story you’re telling. It’s a thinking process, not an artistic one.

Dev Application: Grab a whiteboard or tablet before every major metrics review. Sketch the chart. Annotate what you want people to see. Then build it.

This extra 5–10 minutes will save your team from 30 minutes of confusion later.

Annotations Are Where the Insight Lives

A good chart uses annotation to say what matters. Not just legends and axis labels—but callouts, arrows, notes, and phrasing that direct the viewer’s attention.

Your chart should have an opinion. And your annotations are how that opinion shows up.

Dev Application: Label:

• “Engagement dips here—coincides with ad pop-up change”
• “Bug rate spikes post-feature release”
• “New onboarding flow reduces Day 1 drop-off by 11%”

Don’t assume your audience will notice the insight. Show them.

You Don’t Have to Be a Designer to Be Effective

Berinato is clear: this isn’t about graphic design. It’s about leadership.

If you’re leading a product, a project, a studio, or a roadmap—you’re already making decisions that rely on data. You don’t need to be a Tableau ninja or an infographic wizard. You just need to care enough about clarity to make your charts work.

Dev Application: Use tools you already know—Google Slides, Figma, Power BI, Canva, whatever your org uses. The most important thing is message first, visual second.

Charting Is a Leadership Skill

Berinato closes the book with a key insight: your ability to create and communicate with good charts shapes how others perceive your thinking.

In a game or software company, that matters. A clear, confident, insight-driven chart builds trust. A confusing one loses the room.

You’re not just presenting numbers—you’re showing how you think. You’re demonstrating whether you’ve done the work.

Dev Application: Don’t outsource the message. Even if a data analyst builds your chart, own the insight. Ask, “What are we saying? Is that clear on the screen?”

Final Thought: From Pretty Pictures to Practical Insight

Good Charts doesn’t romanticize data. It reminds us that data alone doesn’t lead—it follows. What leads is the story you tell, the way you frame it, and the decisions you drive from it.

In game and software development, where attention spans are short and meetings are packed, your chart might have 10 seconds to land. If it doesn’t get read, it didn’t matter.

Berinato gives us the tools to fix that. The moment you start designing charts as arguments—not just artifacts—you stop being a reporter and start being a leader.