Power BI skills for analysts: five areas to practise

When someone asks what they need to know in Power BI, I start with a complete task: receive data, understand the question, prepare a model, calculate a result and explain it to another person. Then check whether the report still makes sense after changing filters and refreshing the source. That is a more useful way to assess skills than counting familiar buttons.

This article organises practice into five areas: preparation and modelling, measures, clarity, interaction design and maintenance. We will use a small synthetic order example. The definitions and expected figures are calculated independently of Power BI. This is an exercise design; implement and verify the model and measures in your own report. I am not presenting an executed PBIX file or a performance benchmark here.

Decide who the report should help

Imagine a reader who wants to compare known order amounts across countries and months. They also need to see missing amounts so that an incomplete value is not mistaken for a complete sales total. This establishes the scope: show the value, its time context and data quality. We do not immediately need a map, forecast, ten indicators and an animated navigation menu.

First, define the amount. In this exercise, it is an imaginary order value expressed in one common unit. We have no costs, taxes or returns, so I would not call it profit or a financial result. The analysis uses order creation dates. A question about payments within a month would need a different event and suitable payment information.

Write down the usage scenario too: select a month, compare countries, inspect missing values and return to the full population. This short description becomes a basis for testing the page. Without it, you can spend an hour refining the layout while overlooking that the reader’s main question still requires exporting the data and performing another calculation elsewhere.

1. Prepare the data and design the model deliberately

Our fixture has five synthetic orders. Each appears once, and all amounts use the same imaginary unit. The final record has an unknown amount, which is different from zero. All dates fall in 2026. The example is intentionally small enough to predict the answer without trusting a chart or inspecting hundreds of records at the same time.

• A: 5 January, PL, amount 300.
• B: 6 January, DE, amount 100.
• C: 1 February, PL, amount 100.
• D: 2 February, DE, amount 0.
• E: 3 February, DE, amount unknown.

Before connecting tables, inspect types, keys and the date range. Order identifiers should be unique at this model’s grain. Country is a category, while amount is numeric and permits missing information. When importing text, check decimal separators and date interpretation. A correct-looking preview of a few records does not establish that the rest of the source follows the same conventions.

Power Query prepares and transforms data through steps that can be run again during refresh. Microsoft Learn describes the mechanism. For this exercise, I want you to explain each step, identify rejected records and repeat the preparation when another file with the agreed structure arrives. A repeatable process is easier to inspect than a collection of undocumented manual edits.

I would not remove every row with a missing value just to make the report look tidy. Order E exists even though its amount is unknown. Removing it changes the order count and hides a source issue. Order D, by contrast, has a genuine zero. Keeping that distinction matters more than quickly filling every empty cell with the same replacement value.

Separate events from the dimensions describing them

In the proposed model, the order table contains events, while date and country dimensions define selections. The country dimension has one record per code, and the date dimension has one record per day. Relationships connect each dimension to multiple orders. You should be able to explain why the one side is unique and what happens if that assumption stops holding.

Microsoft discusses facts, dimensions and consistent grain in its star schema guidance. I use this as a design starting point. Automatically suggested relationships still need inspection: keys, cardinality, active status and filter direction should match the reporting question. A relationship being technically possible does not establish that it expresses the intended business connection.

Try a country selection against a simple result table. Selecting PL should retain orders A and C, with a known total of 400. Selecting DE should retain B, D and E: known amount 100, three orders and one missing amount. If nothing changes, investigate the relationship and the field used in the selection before rewriting every measure in the report.

2. Understand measures and filter context

I assess DAX understanding through the ability to explain a result in different contexts. Distinguishing a calculated column from a measure is useful here. Our summaries need to respond to month and country selections, so I would design them as measures. Memorising every function is unnecessary, but knowing which records participate in the current calculation is essential to checking it.

The first expected figures are straightforward. There are five orders, four known amounts and one missing amount. Known amounts total 500. January contains 400 across two orders. February contains 100 across three orders, one of which has no known amount. Record these expectations before creating charts, then compare them with each relevant report view as you build the model.

The February value needs a visible note about one missing amount. A total of 100 can be calculated correctly while still being incomplete as a value for all selected orders. Checking whether a card displays a number is therefore insufficient. We also need to know whether the reader understands its coverage and whether formatting has concealed an important missing value.

A percentage needs an explicit denominator

Across the full fixture, PL contributes 400 out of 500 known amount units, or 80%. After selecting January, its share of January’s known amount is 300 out of 400, or 75%. These are different contexts. If the denominator should retain the month selection while removing only country selection, describe that operation clearly before translating it into a formula.

CALCULATE evaluates an expression in a modified filter context; the details are in the DAX documentation. Including that function does not establish that a measure is correct. Check which filters you change and which should remain. Accidentally removing the month as well produces a different denominator, even if the displayed percentage still looks plausible.

Check an empty population and a population containing only an unknown amount separately. No available data, a known zero and an undefined share should not automatically acquire the same meaning. Agree on presentation rules and add control cases. When there is no valid denominator, the report needs a clear indication that the percentage cannot be determined for the selected population.

3. Design a clear answer

For the first page, I would show known amount, order count, missing amount count and a country comparison. Add a month selection and a value unit. Each element answers part of the agreed question. Before adding another visual, ask which decision or check it helps the reader make. If the purpose is unclear, leave it out until the need becomes concrete.

A title should identify what the chart shows. Known order amount by country is more precise than Results. Mark incomplete data and avoid implying that the value covers all sales. Labels also help when a chart is exported or captured in a screenshot, because the reader may no longer see selections and notes located elsewhere on the original report page.

Clarity does not replace documentation of definitions. The reader should navigate the report comfortably and still have access to explanations of statuses, dates, units and missing values. Creation date and the unknown amount are meaningful assumptions in this exercise. Omitting them in the name of intuitiveness simply transfers the difficulty to the person interpreting the result later.

Test the report with a concrete task: select January, find the PL share and return to the full population. Observe where the reader hesitates or misinterprets something. Asking whether they like the report produces less actionable feedback. My article on presenting data in a dashboard develops this approach to explaining results and designing around the audience’s question.

4. Check interactions and accessibility

Selecting a bar can change other elements on the page. Readers should understand what they selected and how to restore the previous scope. Inspect interactions for the important cards and charts individually. Do not assume that default behaviour fits every question. Pay particular attention to whether an amount and its percentage still refer to compatible populations after a selection.

Use colours consistently without making colour the only way to understand information. Clear labels, contrast, keyboard navigation order and alternative descriptions belong in the design. Microsoft covers these features in its report accessibility guide. Appearance can help comprehension, but it does not establish the correctness of the numbers or the strength of a conclusion drawn from them.

Inspect the page at the size people will actually use. A large authoring monitor can hide small text and overcrowding. If the audience uses phones, prepare and inspect an appropriate layout. Information about missing amounts should remain discoverable when the main value card occupies most of a small screen and the rest of the content sits further down the page.

Design the no-data state as well. Empty space may resemble a failure when the reader has simply selected a month without orders. Agree on the message and filter behaviour. Then return to a populated month and check that all elements respond correctly. A useful test scenario includes these less impressive moments of report use, not only the attractive default screen.

5. Carry the report through its next refresh

A usable report needs a checked update process. Record its source, transformations, owner and expected delivery frequency. Establish separately when the data is complete. A successful refresh does not prove that the source delivered every record. A new file may import successfully despite missing some orders or changing the interpretation of a field that the report still uses.

Refresh behaviour depends on factors including connection mode and source. Understand the distinction between importing data and querying the source, and check connection requirements in the consumer’s environment. The Power BI refresh documentation is a useful reference. A report working locally on its author’s computer does not demonstrate that the same setup will refresh successfully in the service.

Before sharing, establish the intended audience and access method. Publish to web makes content publicly available without authentication and can expose underlying model data beyond what a visible chart shows. Microsoft explains this in its Publish to web documentation. Use data suitable for the chosen sharing method in a portfolio exercise, such as explicitly synthetic records prepared for public practice.

You do not need to know every administration option before beginning. You should understand whether you are handing over a working report or a design awaiting deployment, and who owns maintenance. Describe those boundaries in your example. A portfolio reader should be able to distinguish what you actually ran, what you only designed and which conditions are needed for the next stage.

Build fluency through a repeatable process

Speed develops through a reliable sequence: clarify the question, inspect the source, build the model, define measures, present results and test them. When something disagrees with expectations, return to the earliest stage where the discrepancy appears. Colour changes cannot repair a relationship, and more complicated DAX cannot replace a decision about whether a missing amount should remain visible.

For a slow report, first measure where time is spent. Performance Analyzer helps inspect report element timings; see the Microsoft Learn guide. Use that evidence to choose a change. A formula’s appearance or the number of tables alone does not justify promising a particular improvement in speed for the actual report and data source.

After changing the report, repeat relevant checks: 500 overall, 400 for January, 100 for February, an 80% PL share overall and 75% in January. Check the missing amount and the genuine zero too. This small set ties model behaviour, measures and interactions to specific expectations. A larger project needs comparable cases selected from its own definitions and likely failure points.

Write a small acceptance plan

Before showing the project to another person, prepare a repeatable sequence of checks. Start with no active selections, then select a month, a country and their intersection. Finally, clear the selections. For each step, record the expected records and result. This helps locate whether a discrepancy comes from a filter, relationship, measure or only the way a particular card presents its value.

Check for additional filters the reader may not notice. A number can be consistent with the technical context while disagreeing with what the user believes they selected. Labels and page layout can help resolve that problem. The tester should be able to describe the visible population without inspecting every project setting or relying on the report author to explain hidden choices.

Include reopening the report and refreshing the source. Agree on the expected selection state after returning and whether the displayed update time refers to the data rather than merely the page being viewed. A written acceptance plan becomes useful documentation for the next change. It saves the team from redefining correct behaviour from scratch whenever someone adjusts this particular report.

Show your reasoning in a job application

In a portfolio, describe the question, source, grain, measure definitions and checks performed. Include an error you found and explain the correction. A finished page image mainly demonstrates appearance. Explaining a relationship and the result after filtering gives a reader more evidence that you can independently adapt the report when someone asks for a different scope or interpretation.

I would not prescribe a magic number of projects required to get hired. Extending a project with a source change, another measure and a missing-value check can teach more than collecting similar-looking screens. Requirements vary by role and team. Practise explaining your decisions and identifying what remains untested, without presenting a learning exercise as a company deployment you completed.

For your next step, recreate the tiny fixture and write predictions before selecting filters. Then add an order from another month, refresh the source and compare the result with an updated expectation. If you can explain that whole cycle to another person, you are practising a useful Power BI skill and a more general ability to reason clearly about data.