Designer ↔ BI developer handoff

Native + report design

Who defines what: UX designer, BI developer and QA responsibilities per pattern.

What it is

An explicit split of the decisions each role owns when a table pattern moves from design into implementation.

When to use it

At specification, before development starts, and again at review.

Native Power BI capability

Process, not a Power BI feature.

UX considerations

A design is not ready until default state, empty state and interaction intent are written down.

BI developer considerations

Ask for the missing state definitions rather than inventing them.

QA considerations

Test against the written specification, not against the screenshot.

HTML prototype note

This interactive HTML example simulates the native Power BI behaviour. It is not Power BI itself and should not be interpreted as an implementation of the Power BI rendering engine.

Designer ↔ BI developer handoff

UX designer defines

Information hierarchy and column order
Required fields and measures
Default state (sort, filters, selection)
Interaction intent and what it should affect
Responsive priority and what may be dropped
Accessibility expectations and focus order
Empty, loading and error states

BI developer implements

Dataset fields, measures and relationships
Visual configuration in the format pane
Filters, sort order and interaction wiring
Drill-through / drill-down configuration
Conditional formatting rules
Row-level security and permissions
Query performance optimisation

QA validates

Data correctness against the source
Correct default state on first load
Sorting and filtering behaviour
Drill and selection behaviour
Permissions and row-level security
Empty states and responsive layout
Performance and export behaviour