How to Describe Charts and Data in English at Work

Every sprint review, QBR, or incident post-mortem involves presenting data. Whether you're showing deployment frequency to leadership or explaining user retention to product stakeholders, your ability to describe charts clearly determines whether your audience understands the story behind the numbers.

Many tech professionals can build beautiful dashboards in Grafana or Looker, but struggle to explain what those visualisations actually mean. This creates a gap: your data is only as valuable as your ability to communicate it.

Line charts are everywhere in tech — monitoring dashboards, adoption metrics, sprint burndowns. When presenting a line chart to stakeholders, structure your description: start with the overall trend, then highlight specific changes with precise vocabulary.

Here's a model description for a tech scenario: 'This line chart shows our API adoption rate over the past 12 months. Overall, we can see a steep upward trajectory. Adoption tripled from January to June, then climbed more slowly to 85% by December. The growth slowed down noticeably in Q4, which suggests we may be approaching market saturation.'

Bar charts compare categories — team performance, feature usage across user segments, or hiring metrics over time. The key vocabulary focuses on comparisons, proportions, and relative changes.

Model description for a hiring metrics bar chart: 'This bar chart illustrates the engineering team composition from 2020 to 2024. It can be seen that the number of senior engineers grew steadily from 8 to 22. In contrast, junior hires fell slightly from 15 to 12. Overall, seniors now make up the majority of the team, whereas in 2020 there were nearly two juniors for every senior.'

Pie charts show how a whole breaks down into parts — traffic sources, device types, or budget allocation. The vocabulary focuses on fractions, percentages, and relative size.

Model description: 'This pie chart shows the breakdown of our cloud infrastructure costs by service. From the chart, it is clear that compute resources account for the majority of spending at 45%. Storage represents about a third of total costs. Networking makes up 15%, while monitoring and logging account for only a small minority at 7%.'

Data descriptions use specific grammar structures. Mastering these patterns helps you sound natural and professional when presenting metrics.

Notice the difference between 'by' and 'to': 'Errors increased by 50%' means they went up by that amount (e.g., from 100 to 150). 'Errors increased to 50%' means they reached that level (e.g., from 30% to 50% of total requests).

How you describe data changes based on context. A quick Slack update to your team uses casual language, while a QBR presentation or written report requires more formal phrasing.

A particularly common error: confusing 'raise' and 'rise'. Raise is transitive (needs an object): 'We raised the alert threshold.' Rise is intransitive: 'Error rates rose dramatically.' In data descriptions, you almost always want 'rise/rose' because the metric itself is the subject.

These terms appear frequently in data presentations. Mispronouncing them can distract stakeholders from your message.