Graphic designer to Power BI developer: layout skill, data gap

Start here: the query that sits under every good dashboard

Before any canvas work, run this. It uses synthetic order data for a fictional print studio, the kind of business a designer might know from freelance work.

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  order_date TEXT,
  client TEXT,
  product TEXT,
  amount INTEGER
);
INSERT INTO orders VALUES
 (1,'2026-04-03','Asha Bakery','Menu cards',4200),
 (2,'2026-04-11','Kiran Clinic','Brochure',9800),
 (3,'2026-04-19','Asha Bakery','Stickers',1500),
 (4,'2026-05-02','Nidhi Salon','Brochure',8700),
 (5,'2026-05-14','Kiran Clinic','Signage',15600),
 (6,'2026-05-27','Asha Bakery','Menu cards',3900),
 (7,'2026-06-05','Nidhi Salon','Stickers',1200),
 (8,'2026-06-21','Kiran Clinic','Brochure',10100);

SELECT
  substr(order_date,1,7) AS month,
  COUNT(*) AS orders,
  SUM(amount) AS revenue,
  ROUND(1.0 * SUM(amount) / COUNT(*), 0) AS avg_order_value,
  COUNT(DISTINCT client) AS active_clients
FROM orders
GROUP BY month
ORDER BY month;

It returns three rows:

month    orders  revenue  avg_order_value  active_clients
2026-04  3       15500    5167.0           2
2026-05  3       28200    9400.0           3
2026-06  2       11300    5650.0           2

Look at avg_order_value. It is revenue divided by orders for that month, recalculated from the totals — not an average of per-order averages. That distinction is the single most common mistake in dashboards built by people who start from visuals: they compute a ratio at row level, drop it into a card, and the card silently averages the ratios. The number looks plausible and is wrong.

Why the query comes before the canvas

In your design work, the content arrived finished and your job was arrangement. In BI, the content is calculated at the moment the viewer clicks a filter. A slicer set to "Brochure" recomputes every card, and it can only do that correctly if the calculation is defined as a measure over a clean table.

The Power BI equivalent of the ratio above is a measure, not a column:

Avg Order Value = DIVIDE ( SUM ( Orders[amount] ), COUNTROWS ( Orders ) )

DIVIDE returns blank instead of an error when a filter leaves zero orders — which matters on a report where a client can filter to an empty month. Learn measures, filter context and a simple star schema (one fact table of orders, dimension tables for client, product and date) before you learn any custom visual.

What transfers from the studio, specifically

Some of your habits map almost one to one onto report design:

What does not transfer: the instinct to decorate. Gradients behind charts, 3D effects and icon-heavy cards reduce readability of numbers. Your restraint as a designer is an asset here — use it.

The gap, stated plainly

• Data modelling: relationships, cardinality, why a many-to-many join double-counts revenue.
• DAX filter context: why the same measure gives different answers in a card and in a table row.
• SQL and Power Query: cleaning client names, splitting dates, removing duplicates before the data reaches the model.
• Checking your own numbers: reconciling a report total against the source, every time.

The Data Analyst programme covers SQL, Power BI modelling and reporting in that order, which suits a designer because the visual layer comes after the foundations rather than before them.

Your first portfolio report

Take the synthetic studio data above, extend it to twelve months and around a hundred orders, and build a two-page report:

1. 1Page one — overview: revenue, orders and average order value as cards; monthly revenue as a line; revenue by product as a sorted bar.
2. 2Page two — client detail: a table of clients with last order date and months since last order, so the studio owner can see who has gone quiet.

Then document three things in the README: the model diagram, the measure definitions, and one reconciliation where you show the report total matches SELECT SUM(amount) FROM orders. Include a before/after screenshot of a page you redesigned for clarity — that is where your background becomes visible evidence.

Reporting analyst before Power BI developer

Power BI developer listings often expect data engineering you do not have yet. BI analyst, reporting analyst or dashboard analyst roles are a more realistic first target, because they weigh presentation and stakeholder communication more heavily. Read each posting for the balance between "build reports" and "build pipelines".

Answering "why leave design?"

I haven't left design so much as changed what I design. In the studio I noticed clients trusted the reports we made for them more when the layout was clear, but I couldn't check whether the numbers were right. So I learned SQL and Power BI modelling. In my portfolio report, the first thing I did was reconcile the total against the source query, and I found that one of my early card values was averaging row-level ratios instead of dividing the totals. I fixed it with a measure. I'd like a role where I own both: the number being right, and the page being readable in ten seconds.

If you are unsure whether analyst or a deeper data-science path suits you, the comparison in data analytics vs data science sets out the difference in daily work.