Data Visualisation

Purposes of Data Visualisation

🎯 (EC-12-02, EC-12-11)

📌 Explain the purposes of data visualisation

• simplifying understanding
• telling a story
• highlighting significant results

What data visualisation is

NESA's glossary defines visualisation as the presentation of data or information through pictures or graphics to help the intended audience understand its significance. The important words are intended audience and significance: a chart is not decoration, it is a tool for a particular reader who needs to notice something in the data and do something about it. An enterprise such as a regional hospital, a logistics firm or a school canteen collects far more data than anyone can read as rows in a table. Visualisation is how that data becomes information a manager, a customer or a community member can use.

Simplifying understanding

The human eye is very good at comparing lengths, positions and colours, and very poor at scanning hundreds of numbers. A well-chosen chart lets a reader see in seconds what a table would take minutes to reveal: which month is highest, whether the trend is up or down, which region is the odd one out.

Simplifying does not mean removing the truth. It means removing everything that does not help the reader: unnecessary gridlines, decorative effects and unrelated series. A chart of 12 months of sales as a single line is simpler to read than 12 separate numbers, and it makes the seasonal pattern obvious.

Telling a story

A good visualisation has a message, a title that states it, and a sequence that leads the reader to it. Data stories usually follow the same arc as any story: a context (what is normal), a change or conflict (what has moved), and a resolution (what to do). Compare two titles for the same chart: "Bookings by month" only labels it; "Bookings fall by half between January and June" tells the reader what to notice. Designers help the reader by ordering charts logically, using annotations and using colour to draw the eye to the part that matters (see data journalism in Interactive Media).

Highlighting significant results

Enterprises rarely need all the data; they need the results that matter for a decision. Visualisation highlights significant results by making them stand out: one bar in a contrasting colour, a reference line for the target, an annotation on the spike, or a red marker when a value passes a threshold. Significant means important to the decision, not only unusual. A drop in canteen sales on the day of an excursion is unusual but explained; a slow, steady drop in enrolments over five years is quiet but significant. A dashboard used by a hospital's bed manager highlights wards over 90% occupancy because that threshold triggers action.

Choosing the right chart for the question

The most common mistake is to choose a chart first and ask the question afterwards. Decide what you want the reader to compare, then pick the chart whose shape matches. NESA's Course Specifications name five chart types students should be able to generate in spreadsheet software (bar, column, line, scatter graph and pie, see the Course Toolkit); other types suit particular questions.

Worked example. A school canteen manager asks, "Which day of the week should we roster the most staff?" This is a comparison of categories (days), so the answer is a column chart of average orders per weekday, sorted from busiest to quietest, with the busiest day highlighted. A pie chart would be a poor choice: the seven days are not parts of something the manager cares about, and the slices would be almost equal.

Software Features for Understanding Data

🎯 (EC-12-05, EC-12-08)

📌 Describe how features of software contribute to a better understanding of datasets through data visualisation, including spreadsheets, creative design applications and combining applications to track trends and forecast

No single program does everything. Each type of application contributes something different to understanding a dataset, and skilled analysts combine them. Enterprise Computing expects you to describe what each type does well and how the features track trends and support forecasting. The detail of each feature is in the Spreadsheet Software and Graphics and Presentation Software sections of the Course Toolkit; this section explains why they matter for visualisation.

Spreadsheets

Spreadsheet software is the analyst's first stop because it holds the data, calculates on it and draws it in one place. Features that improve understanding include:

• Charts: the five NESA types (bar, column, line, scatter and pie), configured with titles, axis labels, scales and colours so the message is clear.
• Formulas and functions: SUM, MEAN, MAXIMUM, MINIMUM and COUNT summarise a dataset; IF flags values that pass a threshold.
• Sort and filter: reorder rows or hide those that do not matter to see a subset.
• Pivot tables: regroup thousands of rows by category or month and total them, which is the spreadsheet's version of the OLAP operations described later on this page.
• Conditional formatting: shades cells automatically when a rule is met, so outliers and targets are noticed at a glance.
• Multiple sheets and linked cells: keep raw data, calculations and the finished dashboard separate but connected.

Tracking trends and forecasting in a spreadsheet

To track a trend, plot the values in time order as a line chart, then smooth the noise. A moving average replaces each value with the mean of the last few, so short spikes fade and the direction shows. To forecast, add a trend line to the chart and extend it forward; the next section explains what the line means and its limits. Spreadsheets also support "what if" analysis: change an assumption cell (such as expected growth) and every chart that depends on it redraws.

The month-on-month change bounces between 2.2% and 6.0%, which is hard to read, but the moving average climbs steadily by about 13 to 16 orders a month. Plotting column C beside the raw orders shows the trend without the noise. Fill the formulas down (relative referencing) and the whole column updates.

Creative design applications

Graphics software (see the Course Toolkit) turns an accurate chart into a clear and attractive one. Vector graphics keep lines and text sharp at any size, so charts, icons and infographics stay crisp on a phone or a printed poster. Bitmap tools suit photographs and textures. Features NESA lists that help: templates and colour themes for a consistent look, transparent backgrounds so a chart sits on any slide, cropping and resizing, and importing and exporting in a variety of formats. Presentation software adds slide order and animation, which lets a presenter reveal a chart one idea at a time so the audience follows the story rather than reading ahead.

Combining applications

Combining applications plays to each program's strength. A common workflow: query a database and export the results as a CSV file, import them into a spreadsheet to clean and analyse, generate a chart, export it as an image or vector file, polish it in graphics software, and embed it in a presentation or report. There is a choice when placing a chart in another document:

• Embedded objects are a copy stored inside the document. The document is self-contained, but it does not change when the source spreadsheet changes.
• Linked objects point to the original file. The chart updates when the data changes (which supports tracking a trend month after month), but the link breaks if the file moves.

Identifying Patterns and Trends

🎯 (EC-12-04, EC-12-05)

📌 Identify patterns in data by interpreting and comparing datasets for an enterprise, social or ethical issue to highlight trends and for predictive data analytics

What patterns look like

Identifying a pattern means noticing that data behaves in a regular, repeatable way. Common patterns are:

• a trend: a general rise or fall over time;
• seasonality: a repeat at regular intervals, such as canteen sales that dip in every school holiday;
• a cluster: values that group together, such as customers who all order on Friday evenings;
• a correlation: two variables that move together, such as temperature and cold-drink sales;
• an outlier: a value far from the rest, which may be an error or something important.

You find patterns by interpreting one dataset carefully and by comparing datasets: this month against last year, one suburb against another, or a measure against its target. Comparisons must be fair, so compare like with like: the same period, the same units, and rates (per person, per hour) rather than raw totals when the groups differ in size.

Predictive data analytics

Predictive analytics uses patterns in historical data, with statistical methods or machine learning, to estimate what is likely to happen next. It answers "what is likely?" where descriptive analytics only answers "what happened?". A prediction is an estimate with uncertainty, never a fact. The rest of this section works through two small, fictional datasets. Machine learning models are covered in Data Science; here the tools are a trend line and a correlation.

Worked dataset 1: a trend and a forecast

A fictional online shop recorded its monthly orders for a year. The orders rise steadily.

A trend line (also called a line of best fit, or a linear regression line) is the straight line that sits closest to all the points. "Closest" has a precise meaning: the line chosen makes the total of the squared vertical gaps between each point and the line as small as possible (the least-squares method). Spreadsheet charts can add this line automatically and display its equation. For these data it is y = 14.4x + 296.5, where x is the month number and y the orders.

• The slope, 14.4, says orders have grown by about 14 a month.
• The intercept, 296.5, is where the line meets the y-axis at month 0. It anchors the line; it is not a real month.
• R² (0.996) measures how much of the variation in orders the line explains, from 0 (none) to 1 (all). A value this high says a straight line describes the past very well.

To forecast, substitute a future month into the equation. For month 13: 14.4 × 13 + 296.5 ≈ 483 orders. The same steps give about 498 for month 14 and 512 for month 15 (using the unrounded slope and intercept).

Limits of the forecast. The line assumes growth stays steady. Twelve months cannot reveal a yearly seasonal pattern, so a school-holiday or Christmas surge would be missed. A price rise, a competitor or a supplier problem would also break the pattern. The further beyond the data you extend the line, the less reliable the forecast, so a good chart shows forecasts as estimates, often with a range around them.

Worked dataset 2: a relationship

A fictional kiosk recorded the daily maximum temperature and the number of cold drinks sold on ten days.

Plotted as a scatter graph the points climb from bottom left to top right. The correlation coefficient r is about 0.99: close to +1 means a strong positive relationship. The trend line is approximately drinks = 4.65 × temperature − 46.6, so at 30°C the model predicts about 93 drinks.

Three warnings apply. First, correlation is not causation: heat probably drives both drink sales and beach crowds, and the crowd may be the direct cause. Second, do not extrapolate: the data stop at 35°C, so a prediction for 42°C is a guess. Third, ten days is a small sample; a real analysis would use months of data.

Evolution of Hardware and Software

🎯 (EC-12-06)

📌 Investigate the impact of the evolution of hardware and software on the field of data analytics

• processing power
• storage/memory
• communication media

Data analytics is not new: businesses have always counted stock and sales. What changed is how much data can be handled, how fast, and by whom. Each change came from advances in hardware (the physical equipment) and software (the programs), and each opened new kinds of analysis. The three factors NESA lists are best investigated by asking the same questions of each: what was the limit, what removed it, and what does that make possible now?

Processing power

Early business computers ran batch jobs: the sales report was requested in the afternoon and printed the next morning, because the machine was slow and shared. Since then the number of transistors that can be put on a processor has grown enormously, computers have gained several processor cores that work in parallel, and graphics processing units (GPUs) and other specialised chips do thousands of small calculations at once. Clusters of computers, including rented ones in the cloud, split one job across many machines.

• Impact: queries that once took hours finish in seconds, so analysts can ask follow-up questions while they think. Dashboards can recalculate as filters change. Statistical models and machine learning that need millions of calculations became practical for ordinary enterprises.
• Limit: more processing costs money and electricity, and a model can be run faster but still run on poor data.

Storage and memory

Storage moved from paper files and magnetic tape, to hard disks, to solid-state drives with no moving parts, and to cloud storage that grows on demand. Memory (RAM) became larger and much cheaper per gigabyte. Two consequences matter for visualisation. In-memory analytics loads the working dataset into RAM, which is far faster to read than disk, so charts respond instantly when a user clicks a filter. And cheap storage means an enterprise can keep years of detailed records in a data warehouse or data lake instead of throwing away detail and keeping only monthly totals.

• Impact: longer history for spotting trends, finer detail to drill into, and the storage of new kinds of data (images, sensor readings, logs).
• Limit: keeping everything increases the amount of personal data at risk in a breach and the responsibility to secure it; the Privacy Act's Australian Privacy Principles also expect organisations to delete or de-identify personal information they no longer need.

Communication media

Dial-up modems, then broadband and fibre (including the nbn), Wi-Fi and 4G/5G mobile networks moved data faster, more cheaply and to more places. Data no longer has to be carried on disk to an office: sensors, tills and vehicles send it continuously, and staff view the results in a browser on a phone or tablet. Standard interfaces (APIs) let one system feed another automatically.

• Impact: live dashboards, data collected at the source (IoT sensors on a farm or a bus fleet), cloud collaboration on the same chart, and analytics delivered as an online service.
• Limit: a live view depends on connectivity, and regional areas can have slower or less reliable links, so design for the connection your audience actually has.

How the software evolved

Judgement

Taken together, the impact is that analytics moved from occasional, specialist, backward-looking reports to continuous, self-service and forward-looking analysis. Processing power made complex analysis quick, storage made long histories affordable, and communication media made the results available anywhere and in near real time. The limits are now less about capacity and more about data quality, skills, privacy and cost. Data centres also use large amounts of electricity, so the environment is a stakeholder too. A balanced answer names benefits and limits for at least two groups, such as the enterprise, its customers and the community.

Online Analytical Processing (OLAP)

🎯 (EC-12-04, EC-12-05)

📌 Describe online analytical processing (OLAP)

What OLAP is for

Online analytical processing (OLAP) is a way of storing and querying data so that people can explore it from many angles, quickly. It works on multidimensional data, usually held in a data warehouse, and returns summaries such as "sales by product, by quarter, by region" in seconds even when millions of transactions sit underneath. It contrasts with online transaction processing (OLTP), the everyday system that records each sale as it happens.

Cubes, dimensions and measures

OLAP arranges data in a cube (the shape can have more than three dimensions, but three is easiest to draw). The parts are:

• a dimension: a way to categorise the data, such as Product, Time or Region;
• a measure: the numeric value being analysed, such as sales in dollars or units sold, held in each cell;
• a hierarchy: levels within a dimension, for example Year, Quarter, Month, Day, or Country, State, City.

Because the cube stores summaries ready-made at each level of each hierarchy, moving between views is fast. A spreadsheet pivot table works on the same idea for a single table of data, which is why pivot tables are the closest tool many students have used.

The five operations

Every operation works on the same cube (Coast and Inland, three products, four quarters, sales in $000). The Coast layer is the front face in the diagram; the Inland layer is behind it.

• Slice fixes one dimension at a single value and shows the rest. Slice Region = Coast:

• Dice selects a sub-cube by choosing values on two or more dimensions. Dice Product = Coffee or Cake, Quarter = Q3 or Q4, both regions: this gives 2 × 2 × 2 = 8 cells (Coast: 52, 48, 26, 30 shown above; Inland: 33, 31, 17, 21).
• Drill-down moves down a hierarchy to more detail. Coast Coffee sales in Q3 were 52; drilling down from quarter to month shows July 17, August 18 and September 17 (which total 52). Drill-down may go all the way to individual transactions (called drill-through).
• Roll-up is the reverse: it aggregates to a higher level of a hierarchy (months to quarters to year) or removes a dimension. Rolling up Quarter into a whole year gives annual sales by Product and Region:

• Pivot (rotate) swaps the axes to view the same data from another angle, for example Quarter down the side and Product across the top. The numbers do not change, only the arrangement, and the pattern that was hard to see in one layout may be obvious in the other.

Where OLAP lives

OLAP tools differ in how the cube is stored. Multidimensional OLAP (MOLAP) keeps pre-calculated cubes for the fastest response; relational OLAP (ROLAP) computes the summaries on demand from ordinary relational tables, so it handles larger volumes but is slower; hybrid OLAP mixes the two. You do not need to know the vendors' products, only the idea: a dashboard filter or a drill-down click is an OLAP operation happening behind the scenes. In the NESA course, SQL is limited to SELECT, FROM, WHERE and ORDER BY, so OLAP-style grouping in this course is done with spreadsheet pivot tables.

Data Integrity

🎯 (EC-12-03, EC-12-10)

📌 Assess data integrity in the development of a data visualisation

• ownership
• source
• validation
• risk

Data integrity is the accuracy, completeness and consistency of data, and the trustworthiness of that data across its whole life, from collection to the chart on the screen. A visualisation inherits every flaw in its data and can make them look convincing, so assessing integrity comes before design. To assess is to make a judgement of value or quality, so your answer should rate each factor and justify the rating with evidence.

Ownership

Someone always owns or is responsible for a dataset, and that decides what you may do with it. Ask:

• Who owns it, and under what licence? A licence such as Creative Commons Attribution lets you reuse a dataset if you credit the source; a dataset with no licence should not be assumed free to reuse. The Copyright Act 1968 (Cth) applies to some datasets and their presentation.
• Is it personal information? If people can be identified, the Privacy Act 1988 (Cth) and the Australian Privacy Principles govern how it is collected, used, kept accurate (APP 10) and secured (APP 11). See Data Science for the legal framework.
• Who has the right to govern it? Aboriginal and Torres Strait Islander Peoples have the right to govern data about their communities, Country and cultures. Two frameworks guide this: the Maiam nayri Wingara Indigenous Data Sovereignty principles from Australia, and the international CARE Principles for Indigenous Data Governance (Collective benefit, Authority to control, Responsibility and Ethics). In practice, you seek permission and follow community protocols before using or publishing such data, and you do not assume that "publicly available" means "free to use".

Learn more at the Maiam nayri Wingara website and the Global Indigenous Data Alliance.

Source

The source tells you how far to trust the data. Primary data is collected by you (a survey, a sensor); secondary data was collected by someone else (a government agency, a company report). Assess a source by asking who collected it, how (method and sample), when (is it current?), why (could the collector benefit from a particular result?), and whether the method is documented. Data from a statistical agency such as the Australian Bureau of Statistics documents its methods; an unsigned spreadsheet passed around on social media does not. Where possible, cross-check a key figure against a second independent source.

Validation

Validation checks that data is reasonable and allowed before it is accepted; verification checks that it was transferred or entered correctly (for example, by double entry or by comparing totals with the source). Common validation checks are:

When a dataset arrives already collected, run the same checks as a cleaning step: count and handle blanks, remove duplicates, standardise formats (dates, spelling, units), and investigate impossible values. Record every change so the process can be repeated and explained. In a spreadsheet, filters, sorting (to spot extremes), conditional formatting and an IF formula such as =IF(OR(B2<0,B2>120),"Check","OK") can flag suspicious rows. The data dictionary in the Course Toolkit records the rules each field must meet.

Risk

Data integrity risks are events that damage the accuracy or trustworthiness of data, with consequences for people who act on it. Risk is judged by likelihood and consequence (see the risk matrix in Principles of Cybersecurity).

Worked assessment

Judgement. The dataset is suitable for showing broad seasonal patterns once the bad rows are handled, but it is not strong enough to justify a precise staffing figure on its own. The poster should say so.

Data Warehousing and Visualisation

🎯 (EC-12-02, EC-12-04)

📌 Explain the impact of enterprise data warehousing on data visualisation

• analysis and use of historical data trends and patterns
• correlation with current data
• data refinement/optimisation

What a data warehouse is

An enterprise data warehouse is a large, central store of data copied from many operational systems (sales, stock, human resources, web orders), organised around subjects such as customers or products, and kept over a long period for analysis and reporting. Operational databases are optimised to record transactions; a warehouse is optimised to answer questions. Data is loaded on a schedule through a process called ETL (extract, transform, load): extract it from each source, transform it into consistent formats and definitions, and load it into the warehouse. A smaller warehouse for one department is a data mart, and a data lake stores raw data of many formats before it is refined.

Analysis and use of historical data trends and patterns

Because the warehouse keeps years of history in one consistent form, visualisation can show what a single year cannot: long trends, repeating seasonal patterns, and year-on-year comparisons. A line chart of five years of daily sales reveals a school-holiday dip each January, a steady growth rate, and one unusual week. That history is also the training material for predictive models, since a model can only learn patterns that are in the data it has seen. The value of historical analysis depends on comparable history: if a product code or a store's boundaries changed halfway through, the warehouse team must record the change or the chart will mislead.

Correlation with current data

History becomes useful when it is set beside the present. Visualisations do this in three ways:

• Baselines: show today's figure beside the average for the same weekday over the past eight weeks, with a band for normal variation, so unusual days stand out.
• Forecast against actual: a model trained on history predicts today's demand; the chart shows the prediction and the real result, and a large gap triggers a review.
• Correlating sources: joining sales history with weather, holidays or promotions on a shared key such as the date or location, then checking whether the relationship still holds in current data.

A correlation found in history may weaken, so it needs to be re-checked against current data; a dashboard that is never compared with reality slowly becomes wrong.

Data refinement and optimisation

Refinement improves the quality of data and optimisation improves the speed of using it; both change what a visualisation can do.

• Refinement during ETL: remove duplicates, fix or flag errors, convert units and date formats, fill or mark missing values, and apply the same definition of terms such as "sale" and "customer" to every source. The result is a single trusted version of the figures, so two dashboards no longer show different totals.
• Optimisation: store pre-calculated summaries (daily totals rather than every transaction) for common charts, build indexes on fields that filters use, keep only fields that analysts need, and archive rarely used old detail. Faster queries mean a dashboard that responds when a user clicks; a slow one gets abandoned.

Big Data and Visualisation Design

🎯 (EC-12-04, EC-12-06)

📌 Explain how big data affects the design and development of data visualisation

• scope of visible information
• types and depth of insight provided by the data

NESA's glossary describes big data as extremely large datasets that may be analysed computationally to reveal patterns, trends and associations. Big data is often described by four features: volume (how much), velocity (how fast it arrives), variety (many formats, from tables to text, images and sensor readings) and veracity (how trustworthy it is). See Data Science for how big data is collected and stored; this section is about what it does to the design and development of a visualisation.

Scope of visible information

Big data changes how much of the data can be seen at once. A chart has perhaps a million pixels; a big dataset can have a billion rows. Drawing one mark for each row produces an unreadable blob (called overplotting) and a slow page. Designers respond by deciding what part of the data to show and how:

• Aggregate before drawing: total or average by hour, suburb or category. The one-line summary replaces a million rows.
• Bin and shade: divide the plot into cells and shade each by count, as in a heat map or density plot.
• Sample: draw a random subset for a quick look, and say that it is a sample.
• Overview first, then zoom and filter, then details on demand: show the big picture, let users narrow the scope, and reveal individual records only when asked. This is the pattern behind dashboards, and it is the same as the OLAP drill-down.
• Pre-compute: summarise in the warehouse so the dashboard reads a small table, not the raw data.

Each choice hides some detail, so the design must say what has been hidden (for example, "each cell is the average of about 10,000 tap-ons") and let the user check.

Types and depth of insight provided by the data

Big data offers more kinds of insight and greater depth. Analytics is often described in four levels, each answering a deeper question:

• Descriptive: what happened? (weekly boardings on each bus route)
• Diagnostic: why did it happen? (boardings fell where a road was closed and on wet days)
• Predictive: what is likely to happen? (expected boardings next Saturday given the weather forecast)
• Prescriptive: what should we do? (add a bus on the route and time where demand is forecast to exceed capacity)

The volume and variety of big data enable finer segments (down to a stop, an hour or an individual customer), the joining of data from different sources (location, weather, social media text), and pattern-finding by machine learning that no person could do by inspection. Each level should be visualised differently: descriptive views are charts of the past, predictive views need forecasts drawn as estimates with ranges, and prescriptive views end in a recommended action.

Cautions. More data does not mean better data: a huge dataset can still be biased, for example if it only includes people who own smartphones. With many variables, some chance correlations will appear by luck, so a pattern needs a plausible explanation and to be tested on new data. And finer detail brings privacy risk: charts of very small groups can identify individuals, so enterprises combine small groups or suppress tiny counts.

Bias in Visualisations

🎯 (EC-12-03, EC-12-07)

📌 Evaluate bias in data collection, storage and analysis when developing visualisations

• accuracy
• audience
• data source
• unconscious bias

Bias is a systematic distortion that pushes results in a particular direction. It can enter at any stage: when data is collected (who and what is measured), stored (what is kept, cleaned or dropped) and analysed (which comparisons and charts are chosen). To evaluate bias, you weigh how serious it is, what causes it, and how well it can be reduced, and then reach a judgement. The figure below shows why it matters: biased data can feed a loop that produces more biased data.

Accuracy

Accuracy is how closely the data and the chart match reality. Bias affects it when measurement is systematically off (a scale that reads 2 kg high), when the sample does not represent the population (a survey of gym-goers about attitudes to exercise), or when records are missing for a reason (people with low incomes skipping a question). In storage, accuracy is damaged by out-of-date records, rounding, and silently dropping rows with blanks. In analysis, it is damaged by choosing an average that hides a skewed distribution. Evaluation: ask how the data was measured, who is missing, and how large the error could be, then state the uncertainty on the chart.

Audience

Bias can come from the audience or be aimed at it. A designer who assumes the audience shares their knowledge may leave out context that changes the meaning. An organisation may show only the results that suit its audience, such as a sales chart with the good quarters and not the bad. Language, colour and imagery carry cultural assumptions: a red-green scale that is unreadable for a colour-blind viewer excludes part of the audience. Evaluation: identify who the audience is, who was left out, and what they would need to see to make a fair judgement.

Data source

Every source has a viewpoint. Data from social media over-represents people who use it and are vocal; data from a company's own customers says nothing about non-customers; historical records reflect the decisions of the time (such as who was offered a loan). Combining sources can compound the problem when their populations differ. A source with a stake in the result (a sponsor's survey praising the sponsor's product) needs extra scrutiny. Evaluation: ask who produced the data, for what purpose, and who is absent from it (see the Data Integrity section).

Unconscious bias

People have assumptions and preferences they are not aware of, and these shape every choice in a visualisation: which questions to ask, which variables to include, which outliers to treat as errors, and which story to look for. Confirmation bias makes us favour data that supports what we already believe; survivorship bias makes us study only the cases that survived (successful start-ups) and miss those that did not. Evaluation: unconscious bias cannot be seen by looking harder, so it is reduced by process: state the question before looking at the data, have someone with a different viewpoint review the chart, and test the finding against data you did not use to form it.

Bias at each stage

Misleading-chart techniques

Some distortions are deliberate; many are accidents. Learn to spot them, and never use them.

Judgement: how serious is the bias?

To evaluate bias in a visualisation, weigh these questions and reach a verdict. Does the bias change the decision the audience would make? Could it harm particular people or groups (an ethical and, in some cases, a legal issue under discrimination law)? Is it deliberate or accidental? Can it be corrected, and at what cost? For example, a truncated axis on an internal draft is easy to fix and low-harm; the same chart on a public health notice is high-harm and the enterprise should correct it publicly. The best defence is transparency: state the source, the period and the method, and show the whole scale.

Evaluating Visualisation Tools

🎯 (EC-12-08, EC-12-10)

📌 Evaluate the effectiveness of software tools used to develop data visualisations

• spreadsheets used to develop dashboards
• presentation software used to present data analysis
• business analytics services, including ‘as a service’ products
• custom software solutions

To evaluate a tool is to judge how well it does its job against criteria that matter to the user. There is no best tool, only the best fit for a purpose, an audience, a budget and a set of skills. The four categories below are not exclusive: many projects start in a spreadsheet, present in slides and later move to a business analytics service as they grow.

Criteria for evaluation

• Cost: licence or subscription, hardware, training and maintenance, not just the purchase price.
• Ease of learning and use: how quickly a new user becomes productive.
• Data volume and sources: how much data it handles and what it can connect to.
• Interactivity: filters, drill-down and dashboards, or only fixed charts.
• Sharing and live refresh: whether many people can see current data without emailing files.
• Governance and security: access control, audit trails, where data is stored.
• Tailoring and integration: how far it can be adapted to the enterprise and connected to other systems.

Spreadsheets used to develop dashboards

A spreadsheet dashboard combines a data sheet, a calculation sheet and a display sheet holding charts, pivot tables and key figures, often with slicers or drop-down cells so the user can filter. Most staff already know the software, so cost and training are low, and a prototype can be built in an afternoon.

• Strengths: familiar, cheap, flexible; formulas are visible and easy to check; good for small and medium datasets and for one-off analysis.
• Limitations: row limits and slowing performance on large data; manual refresh unless connected to a source; version chaos when copies are emailed around; formulas can be broken by accident; weak access control.

Presentation software used to present data analysis

Presentation software organises charts and commentary into a sequence for an audience, with templates, themes, animation and embedded or linked charts. It is the right tool for telling a story to a room, such as a board meeting or a class presentation, where the presenter controls the pace.

• Strengths: strong storytelling and design control; audiences know how to follow slides; easy to combine with spreadsheet charts.
• Limitations: static (a chart on a slide is a snapshot); limited data handling; the audience cannot explore; numbers are copied and go out of date.

Business analytics services, including 'as a service' products

Business analytics (or business intelligence) services are purpose-built for turning enterprise data into interactive dashboards. Many are delivered online as a service, so the enterprise rents access rather than buying and running the software (see cloud service models in Networking Systems). Categories include:

• Software as a Service (SaaS) dashboard tools used through a browser: connect to data, drag fields to build charts, publish to colleagues. Examples include Microsoft Power BI, Tableau and Google Looker Studio.
• Cloud data warehouses and analytics platforms (a platform or infrastructure service) that store and query very large data, which dashboard tools then read. Examples include Google BigQuery, Amazon Redshift and Snowflake.
• Embedded analytics: charts and dashboards built into another product, such as the sales report inside an accounting package.

The product names are examples of the categories, not something you need to memorise. Strengths: scalable to big data, live refresh from many sources, interactive and shareable, security and access controls managed centrally, updates handled by the provider. Limitations: ongoing subscription cost, a learning curve, dependence on the provider and on internet access, and questions about where data is stored. Personal information sent to an overseas provider raises Australian Privacy Principle 8 (cross-border disclosure), so an enterprise checks the provider's data location and terms.

Custom software solutions

A custom solution is written or commissioned to fit one enterprise's needs, for example a web application using a programming language and a chart library, or an application built by an external developer. It might display a fleet's live positions on a map with rules the enterprise defines.

• Strengths: complete control of features, appearance and integration; can handle unusual data; no licence fee for the tool itself; the enterprise owns the result.
• Limitations: highest up-front cost and time; needs programming skills; must be tested, secured and maintained for its whole life; risk that the developer leaves and no one understands it.

A worked evaluation

Each criterion has a weight (3 = very important, 1 = minor). Each tool is scored from 1 (poor) to 5 (excellent) and the score is multiplied by the weight. The maximum possible total is 80.

Judgement. The analytics service scores highest because live sharing and interactivity matter most and staff can learn it. The spreadsheet is a sound second choice and a good prototype: the co-op could build it first to settle which charts they need. Custom software is powerful but its cost and skills demands outweigh the benefits at this scale. The result depends on the weights: if the co-op had no budget and only a monthly report, the spreadsheet would win. A good evaluation therefore states its assumptions.

Interrogating a Visualisation

🎯 (EC-12-05, EC-12-10)

📌 Interrogate data from a data visualisation

• interpreting what you see
• aggregation
• filtering
• the effect of outliers
• reasoning

To interrogate a visualisation is to question it: What does it show? How was it built? Would the message survive a change in aggregation or a filter? A good analyst does not just accept the picture; they poke at it. The interactive chart later in this section lets you do that with a small fictional dataset.

Interpreting what you see

Read a chart in a fixed order, so that you look at what is drawn before what it seems to say:

1. Title and purpose: what question is it answering, and for whom?
2. Axes and scale: what is measured, in what units, and where does the axis start?
3. Encoding: what do length, position, colour and size stand for? Check the legend.
4. Data: what period, place and population does it cover? What is the source?
5. Pattern: what is highest, lowest, rising, falling, or unusual?
6. What is missing? Whose data is not shown, and what comparison is absent?

Keep three statements apart. An observation says what the chart shows ("the March column is the tallest"). An inference says what it probably means ("March is the busiest month"). A conclusion says what to do ("hire more staff in March"). Each step needs more evidence than the one before.

Aggregation

Aggregation combines many records into a summary, such as the total, average or count for each month or category. The level you aggregate at, and the measure you use, changes the story. Using the fictional hire-shop data in the widget below, the monthly totals fall from $640 in January to $350 in June. That looks like weaker bookings. But the monthly counts fall from 10 bookings to 5 while the average booking value stays between $55 and $73. The shop is not earning less per booking; it has fewer bookings. Different measures answer different questions:

• Total (sum): how much overall. Sensitive to how many records there are.
• Average (mean): the typical size. Sensitive to outliers.
• Count: how often. Ignores size.

Aggregation also hides detail: a healthy total can conceal one failing region. Good dashboards let the user aggregate at several levels, which is the roll-up and drill-down of OLAP.

Filtering

Filtering shows only the records that meet a condition, such as one category or a range of months. It answers "what happens within this group?" and removes clutter. In the widget, filtering to Kayak bookings gives an average of about $86, well above the $45 for Bike. Filters have risks. A filter that is not obvious changes the meaning of the chart without the reader knowing, so the chart should state the active filters. A very narrow filter leaves too few records for a reliable pattern. And filtering out inconvenient data is a form of cherry-picking (see the Bias section).

The effect of outliers

An outlier is a value far from the rest. It may be an error (a price typed with an extra zero), or a real but unusual event (a corporate group booking). Outliers affect summaries differently. The mean uses every value, so one extreme value pulls it towards itself. The median, the middle value when the data are in order, barely moves. In the widget's data the median booking is $65 and the mean $66.78. Add one $2,400 corporate booking and the mean jumps to $117.50, while the median stays at $65. The March total leaps from $530 to $2,930 and, with a zero-based axis, every other month looks tiny.

What should an analyst do? First find out whether the outlier is an error. If it is, correct it or remove it and document the change. If it is genuine, keep it but do not let it mislead: show results with and without it, use the median for a "typical" value, and annotate the chart. Never delete a value silently because it spoils the pattern. A common rule of thumb flags values more than about three standard deviations from the mean, but the outlier itself inflates the standard deviation, so always look at the data too.

Reasoning

Reasoning links evidence to a claim. A useful structure is claim, evidence, reasoning, followed by a check for alternatives. In the hire-shop data: Claim: kayaks are the shop's best earner. Evidence: total kayak bookings are $1,380, against $955 for paddleboards and $670 for bikes. Reasoning: kayaks have the highest average booking ($86 against $68 and $45) while the counts of bookings are similar (16, 14 and 15), so the difference comes from higher value per booking, not more bookings. Alternative explanations to test: is kayak hire simply the most expensive item, and does the pattern hold in every month?

Good reasoning respects the limits of the data. Correlation is not causation. A pattern in 45 bookings may not hold for next year. And you cannot generalise beyond the population the data represent: the hire shop's customers are not all beachgoers.

Try it: interrogate the chart

The widget uses 45 bookings from an imaginary beachside hire shop, plus one optional corporate booking. Change the grouping and the aggregation, apply the filters, and watch the summary figures below the chart. The table behind the chart shows every record.

Graphic Design Tools

🎯 (EC-12-08, EC-12-11)

📌 Use graphic design tools to assist in the graphic development of a data visualisation

Spreadsheet charts are accurate but plain. Graphic design tools let you refine the look, add annotations and adapt the result to a poster, a website or a slide. Course Specifications page 21 lists what graphics software should allow you to do: create and manipulate bitmapped images and vector graphics, rotate, crop, resize and distort images, import and export in a variety of formats, apply textures, patterns and transparent backgrounds, and use templates, colour themes and animations. The Course Toolkit describes each feature. Here you apply them to a chart.

Choosing the tool

The programs are examples only; use whatever your school provides. Vector formats (such as SVG) keep shapes editable and crisp, while bitmap formats (PNG, JPEG) are pixels and blur when enlarged. Interactive Media covers UI design tools in more depth.

Design principles for data graphics

• Hierarchy: make the message the most prominent element (title and highlighted data), then supporting labels, then the source line.
• Colour with purpose: use a neutral base and one accent to highlight what matters. Use colour to encode meaning (for example, sequential shades for low to high), not decoration. Avoid pairs that colour-blind viewers cannot separate, such as red and green, or add a second cue such as a label or pattern.
• Contrast: the Web Content Accessibility Guidelines (WCAG) ask for a contrast ratio of at least 4.5:1 for normal text (contrast minimum) and 3:1 for graphical objects such as chart lines and bars (non-text contrast).
• Typography: one or two typefaces, a readable size (not tiny axis labels) and consistent styles for titles, labels and notes.
• Layout and alignment: align to a grid, group related items, and leave white space so the eye can rest.
• Reduce clutter: remove heavy gridlines, borders and decoration that carry no information, but keep labels, units and the source.
• Direct labels: label lines and bars on the chart when you can, instead of making the reader hunt in a legend.

Worked example: making a chart audience-ready

1. Export: save the chart from the spreadsheet as a vector file (SVG or PDF) if possible, or as a high-resolution PNG (see "save a chart to a file format" in the Spreadsheet Specifications).
2. Set up the canvas: create an A3 portrait document in vector software and apply the council's colour theme (or a limited palette of a neutral, a main colour and one highlight colour).
3. Import and simplify: place the chart, delete gridlines and the legend, and label the columns directly. Make sure bars start at zero.
4. Highlight: recolour the peak week in the highlight colour and add a short annotation ("School holidays: buses full").
5. Add text hierarchy: write a headline that states the message ("Weekly boardings double in the school holidays"), a subtitle with the period, and a source line ("Source: fictional shuttle tap-on data, 2024").
6. Check accessibility: test the contrast of text and bars and check the colours in a greyscale or colour-blind preview. Write alt text that states the message for screen readers.
7. Export: PDF for print, PNG or SVG for the website, and a copy on a transparent background for slides. Keep the editable original.

User Experience and Visualisation

🎯 (EC-12-10, EC-12-11)

📌 Explain how user experience (UX) influences the development of effective data visualisations

• relevance to the audience
• audience interpretation
• customisation
• live analysis

User experience (UX) is the overall quality of a person's interaction with a product: whether they can find what they need, understand it and trust it. For a visualisation, good UX means the audience gets the right insight quickly, with little effort. UX is covered in Interactive Media (UI and UX); here it is applied to data. The figure shows where the four factors NESA names appear on a typical dashboard.

Relevance to the audience

The most common UX failure is showing everything because the data is available. A relevant visualisation starts from the audience's decisions: a hospital executive needs a few key indicators and trends; a ward nurse needs today's bed availability; an analyst needs detail and filters. The same data becomes three different visualisations. Relevance also means a suitable level of detail, familiar vocabulary and units, and content that is current. To design for relevance, ask "what will this person do with this?" and leave out anything that does not help.

Audience interpretation

Audiences interpret charts through their own knowledge, expectations and abilities. A specialist reads a box plot easily; a general audience may not. Readers assume conventions: time runs left to right, higher means more, red means bad. Breaking a convention (a reversed axis, red for good) invites misreading. Interpretation also depends on accessibility: colour-blind users, people using screen readers who need a text or table alternative, and people on small screens. Designers reduce misinterpretation by using plain titles that state the message, labelling units, offering short explanatory notes, and testing the design with real users, because what is obvious to the designer is often not to the audience.

Customisation

Users differ, so visualisations often let them shape what they see: filters, choice of measure, date range, chart type, units, saved views, or light and dark themes. Customisation lets one dashboard serve several audiences and lets users answer their own follow-up questions. It also has costs. Too many options overwhelm and make results hard to compare between users, and a customised view can be used to cherry-pick. Good practice is to offer sensible defaults, show the active filters clearly, and provide a one-click reset.

Live analysis

Live analysis means the visualisation updates as new data arrives, so users see what is happening now: a traffic map, a stock level, a hospital emergency waiting list. It supports fast decisions and alerts (a tile turns red past a threshold). UX questions include how often to refresh (too often is distracting and expensive), how to show when the data was last updated, how to handle a lost connection, and whether the audience needs live data at all: a monthly board report does not. Live views also depend on the communication media and processing power discussed earlier.

Criteria for Evaluating User Experience

🎯 (EC-12-10)

📌 Develop and implement criteria for evaluating the effectiveness of user experiences

To evaluate a user experience you need criteria you decided on before looking at the design, so the judgement is fair and repeatable. Developing criteria means deciding what makes this visualisation effective for this audience; implementing them means gathering evidence and applying the criteria to reach a rating and actions. The rubric below is a starting point you can reuse and adapt.

A reusable rubric

Score 3 lies between 2 and 4 and score 1 is "not met". Decide the weights first if some criteria matter more than others (a public health dashboard might weight accessibility heavily).

Implementing the criteria: a worked evaluation

1. Set tasks that match the purpose: (1) find last month's total sales, (2) show only the Friday sales, (3) explain why March was so high.
2. Test: record success or failure and the time for each user and task. Afterwards, ask each user to rate "It was easy to use" from 1 (strongly disagree) to 5 (strongly agree).
3. Summarise the evidence:

The five satisfaction ratings were 4, 4, 3, 5 and 3, a mean of 3.8 out of 5.

4. Score against the rubric: the student rates Purpose 4, Clarity 3, Accuracy 4, Navigation 2, Accessibility 2, Design 3, Interactivity 3 and Performance 3. The total is 24 out of 32, or 75%.
5. Decide actions from the weakest criteria: Task 3 failed for most users because the March outlier is not annotated, and nobody could find the drill-down (navigation, score 2). Fix: add an annotation and a "click a bar for detail" hint. Accessibility scored 2 because red and green are the only difference between "up" and "down": add arrows and labels.
6. Retest and record: after the changes, repeat the tasks with different users and compare the results with the first round.

Emerging Technologies in UI and UX

🎯 (EC-12-06)

📌 Investigate the impact of emerging hardware and software technologies on user interface (UI) and UX design and development

Interfaces change when hardware and software do. Each new technology gives visualisation designers new opportunities and new problems. To investigate, look at what the technology changes about how people interact with data, weigh benefits against limits, and draw a judgement. Interactive Media also covers hardware for interactive media.

Effects on design and development

• New interaction patterns: touch, gesture, voice and gaze replace the mouse, so designers rethink controls such as filters and tooltips.
• Responsive and adaptive design: one visualisation must adapt from a wall display to a watch, often by showing fewer elements as space shrinks. Designers plan the essential view first.
• New skills and processes: building for AR or VR requires three-dimensional tools; voice interfaces require language processing; all need prototyping and testing with real users on real devices.
• Accessibility opportunities and risks: voice and audio (sonification, a chart rendered as sound) can help users who cannot see a chart, but immersive interfaces can exclude users who cannot wear a headset.
• Privacy and ethics: headsets, microphones and cameras collect body movement, voice and surroundings; enterprises must handle this data under the Privacy Act and be clear with users.
• Trust: the more the software decides what to show, the more important it is that the user can see the source data and check the result.

Judgement. Emerging technologies improve access to data (more people, more places, more natural interaction) but do not remove the need for sound design: a badly chosen chart is just as misleading in VR or read aloud by a voice assistant. AI-generated insights offer the biggest gain in speed, and also the biggest need for human checking. The technology worth adopting is the one that fits the audience, the task and the environment, not the newest one.

Sourcing and Organising Data

🎯 (EC-12-03, EC-12-04)

📌 Research, source, organise and store data appropriate for a data visualisation

The verbs here are practical: research, source, organise and store. A visualisation project is only as good as the data behind it, so this stage deserves as much care as the design. The steps below give you a process you can follow and evidence for your project documentation.

Research: define what data you need

Start from the question and the audience, then list what data would answer it: which variables, over what period, for which places or groups, and at what level of detail. For a question such as "how does temperature affect beach shuttle use?" you need daily boardings and daily maximum temperature for the same dates. Research also means finding out what already exists and how others have measured the same thing.

Source: find data you may use

Judge a candidate dataset with the factors from the Data Integrity section: ownership and licence, source, validity, and risk. Also check it fits: is it detailed enough, current enough, and large enough? Record every source with its title, publisher, date accessed and licence, because you will need them for a source line on the chart and for your documentation.

Organise: make it analysis-ready

Raw data is rarely ready to chart. The usual target is a tidy layout: one row for each observation, one column for each variable, and one table for each type of thing (see relational databases for splitting data across linked tables). Use consistent formats, and describe every field in a data dictionary. A small before-and-after shows the work:

What changed, and why it matters: three date formats became one (and "3/1/25" was checked to be day-month-year); the site name was standardised so it counts as one place; the thousands separator was removed so the value is a number; the duplicate row for 3 January was removed; and the "n/a" was replaced by a blank with a note, because a missing value is not zero. Keep a log of these decisions.

Store: keep it safe and findable

• Keep the raw data untouched. Store the original download in a read-only folder, and do all cleaning in a copy. You can always return to the source.
• Use a clear structure: for example folders named 01_raw, 02_clean, 03_analysis and 04_outputs, and file names with a date and version such as shuttle_daily_2025-06-30_v2.csv.
• Choose a format to fit: CSV (simple, opens anywhere), a spreadsheet (formulas and charts), or a database for large or linked data.
• Write a README: what the data is, its source, the date accessed, the licence and the cleaning steps.
• Control access and back up: restrict who can edit, and keep backups (see the Maintaining Data Security section).

Designing and Developing a Visualisation

🎯 (EC-12-05, EC-12-08, EC-12-11)

📌 Design and develop a data visualisation for a specific scenario to represent trends, patterns and relationships, and illustrate predictive analysis incorporating big data

This is the practical heart of the topic: design and develop a visualisation for a specific scenario, showing trends, patterns and relationships and illustrating predictive analysis that incorporates big data. Below is a complete worked project in ten steps. Every figure is fictional. Use the same steps for your own scenario, and adapt the tools to what your school provides. Spreadsheet features are in the Course Toolkit.

Step 1: define the question, audience and success criteria

Question: how many passengers can we expect on Saturday, and does it depend on the weather? Audience: the operations manager (not a data specialist), who has one minute on Thursday morning. Success criteria: the manager can find Saturday's predicted boardings in under 30 seconds and can see how sure the prediction is. Write these down; you will test against them in Step 9.

Step 2: plan and source the data

• Tap-on records from the council's card system (the big dataset): date, time, stop and route. Any card number is removed or replaced with a random code before analysis, to protect privacy.
• Daily maximum temperature from a weather data provider, matched by date.
• A calendar of school holidays and public holidays, which explains unusual days.

Check ownership and licence for each, and record the source and date accessed.

Step 3: prepare the big data

Plotting 1.8 million points would be unreadable and slow, so reduce the data to what the question needs. Aggregate the tap-on records to one row per day (date, day type, boardings) in the council's database or with a pivot table, then join the daily maximum temperature by date. In NESA SQL, a query can select a filtered, ordered subset of a daily summary table that already exists:

SELECT Trip_date, Boardings, Max_temp
FROM Daily_summary
WHERE Trip_date >= '01/11/2024' AND Trip_date <= '30/04/2025'
ORDER BY Trip_date ASC

Counting the raw records per day needs grouping, which is beyond NESA's four SQL keywords (SELECT, FROM, WHERE, ORDER BY); in practice a pivot table or the database tool's grouping feature does it. Validate as you go: check for missing days, negative values, and totals that do not match the source.

Step 4: analyse for trends, patterns and relationships

Explore the data before choosing the final charts. Three questions match NESA's three ideas:

A sample of ten summer Saturdays and Sundays shows the relationship (also fictional):

The mean is 1,139 boardings, from a total of 11,390 over the ten days. The trend line the spreadsheet fits is approximately boardings = 50.7 × temperature − 279 and the correlation is about 0.99. Each extra degree is associated with about 51 more boardings. Typical differences between the line and the actual values are around 26 boardings.

Step 5: make the prediction

The forecast for Saturday is 32°C. Substituting: 50.7 × 32 − 279 ≈ 1,340 boardings. Because real values scatter about 26 either side of the line, and the temperature forecast is itself uncertain, show a range of roughly 1,290 to 1,390 (about two typical differences), not a single number. The data stop at 35°C, so no prediction should be made for a 40°C day. A holiday weekend is not in the model at all, so the dashboard should say so.

Step 6: design the visualisation

Sketch a wireframe first (the dashboard figure in the User Experience section is a template), decide the reading order, and choose a limited palette with enough contrast. Give every chart a title that states its message. Add a source line and the date the data was last updated. Plan the customisation: a weekday filter and an input for a temperature to test.

Step 7: build it in a spreadsheet

1. Sheets: Data (the cleaned daily table), Analysis (calculations) and Dashboard (charts and key figures).
2. Summaries: in Analysis, =SUM(Data!C2:C11) for the total, =MEAN(Data!C2:C11) for the mean, and =MAXIMUM(Data!C2:C11) and =MINIMUM(Data!C2:C11) for the extremes.
3. Flag days: =IF(Data!C2>=1300,"Extra bus","Standard") in a new column, and conditional formatting to shade those rows.
4. Charts: insert a scatter graph of temperature (x) against boardings (y); add a trend line and display its equation and R². Insert a line chart of weekly totals. Configure titles, axis labels, scales, colours and remove default clutter.
5. Prediction cell: put the forecast temperature in an input cell (say Dashboard!B2) and use =50.7*B2-279 for the prediction, plus and minus the range in the next cells. Changing the temperature updates the figure straight away: a live "what if".
6. Assemble: arrange the key figure, filters and charts on the Dashboard sheet as designed, and protect the Data and Analysis sheets so viewers cannot break formulas.

Your school may prefer a different tool, such as a business analytics service or a program you write; the design and analysis decisions are identical.

Step 8: check accuracy

Reconcile the totals on the dashboard with the source data; recalculate one figure by hand; check that the trend line equation matches the chart; and confirm that axes start at zero for column charts. Ask someone else to try to break it.

Step 9: test with users and refine

Give the operations manager (or a classmate playing the role) the three tasks from Step 1 and time them. Score the dashboard against the UX rubric. Record what needs to change, fix it and retest. Compare the results with your success criteria.

Step 10: publish, document and maintain

Publish the finished version and name the owner. Record the sources, cleaning steps, model assumptions and limits in a README. Put the "as at" date on the dashboard, set a refresh routine, and protect the files as described in the next section. Finally, evaluate: did the visualisation meet its success criteria, and what would you change with more time or data?

Maintaining Data Security

🎯 (EC-12-03)

📌 Investigate and implement methods to maintain data security

• cybersecurity
• data backup

A visualisation project handles data that may be personal, commercially sensitive or simply hard to replace. Investigate the threats and methods, then implement them for your own project. NESA lists two areas: cybersecurity, which stops others from getting at or changing the data, and data backup, which lets you recover when something goes wrong. Principles of Cybersecurity covers protecting data and cyber law in more depth.

Cybersecurity

Threats specific to visualisation work include stolen login details (through phishing), ransomware that encrypts files, a cloud dashboard accidentally shared with "anyone with the link", an insider copying data, and leakage through the chart itself. Charts and files often contain more than is shown: the data behind a chart embedded in a presentation, hidden sheets, and file properties can all be opened by the recipient.

The Australian Signals Directorate's Australian Cyber Security Centre publishes the Essential Eight, eight baseline mitigation strategies: application control, patching applications, configuring Microsoft Office macro settings, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication and regular backups. Several apply directly to a visualisation project. The law also matters: Australian Privacy Principle 11 requires organisations to take reasonable steps to protect personal information, and under the Notifiable Data Breaches scheme an organisation must notify affected people and the OAIC about an eligible data breach that is likely to result in serious harm. The full text of the principles is on the OAIC website.

Data backup

A backup is a copy of data kept separately so that it can be restored after loss, corruption, deletion or ransomware. The widely used 3-2-1 rule is shown below.

Two measures plan a backup. The recovery point objective is how much work you can afford to lose (a daily backup means up to a day). The recovery time objective is how long you can afford to be without the data. Two cautions: a file-sync service is not the same as a backup, because an accidental deletion or an encrypted file is copied across immediately, so enable version history or keep a separate backup; and a backup that has never been restored is untested, so test a restore regularly.

Implement: a security and backup plan for the project

1. Classify the data: does it include personal information? If so, remove or replace identifiers before analysis.
2. Set up storage: the folder structure from the Sourcing and Organising Data section, with raw data read-only.
3. Secure accounts: turn on multi-factor authentication and set sharing to view-only for named people.
4. Plan backups: working files copied automatically each day (incremental) to school cloud storage; a full copy each week to an external drive that is disconnected afterwards; a third copy in a different building or a different account. Recovery point objective: one day.
5. Test: restore one file and the whole folder onto a different computer and check that the dashboard opens. Note the date and result in a log.
6. Sanitise before sharing: export a PDF or image, remove hidden sheets and check the file properties.
7. Review: repeat the checks each term and after any incident, and record what you changed.