Estater × Power BI

RoleLead Product Designer

CompanyEstater

ScopeUX · System Design · BI Integration

CollaborationEngineering · Data / BI Teams

Redesigned the reporting workflow by integrating Power BI into the Markets platform — cutting report turnaround from full sprint cycles down to minutes, while working within strict third-party UI constraints.

01 — Context

As the platform grew, reporting couldn't keep up

After Markets evolved into a more advanced analytics platform, demand for report updates and customizations accelerated significantly. The problem was that the reporting infrastructure hadn't evolved alongside the product — every change, however small, required a full engineering sprint.

Business and data teams had the knowledge to iterate on reports themselves. The product just didn't give them the tools to do it. The gap between what users needed and what the team could ship was growing.

02 — The Problem

Two problems in tension: agility and consistency.

Power BI offered a clear path to speed — it would let the data team iterate on reports without engineering involvement. But embedding a third-party BI tool into a polished product experience isn't as simple as dropping in an iframe. Power BI has its own UI patterns, interaction behaviors, and visual language that can jar against a carefully designed product.

Engineering dependency at every stepEven minor report changes required developer time. The team was a continuous bottleneck — and becoming more of one as the platform grew.

Reporting couldn't scale with demandEvery change, however small, meant a full engineering sprint. As the platform matured and requests accelerated, the reporting backlog only grew.

The people who could iterate couldn'tThe business and data teams had the knowledge to build and refine reports themselves — but the product gave them no tools to do it without filing an engineering ticket.

Third-party tools break the experiencePower BI could deliver the speed, but it brings its own UI patterns, interactions, and visual language — dropped in naively, it would jar against a carefully designed product.

03 — Design Strategy

Don't fight the constraint. Design around it.

The instinct with third-party integration is to try to make the embedded tool look like the host product. But that's a losing battle — you'll always be fighting the tool's defaults. Instead, I designed a strategy around four principles that worked with Power BI's constraints rather than against them.

01 · Map the constraints firstBefore designing anything, I mapped exactly what Power BI would and wouldn't let us change — theming versus layout versus interaction. Knowing the fixed edges up front is what made designing around them possible.

02 · Design the frame, not the toolWhere the embedded middle couldn't be changed, I controlled everything around it — entry points, loading states, error handling, exit paths — all built in the Markets system so the rigid core never defined the experience.

03 · Trade a little control for a lot of speedAccepting some of Power BI's UI defaults bought reporting that shipped in minutes instead of sprints. That trade was a deliberate product call, not a compromise of quality.

04 · Enable the data team, don't gate themThe point was autonomy — the data team owning report updates without engineering — so the conventions had to be something they could actually follow, not a spec they'd reference once and forget.

The Decision I Owned

The purist instinct was to fight for pixel-level control over the embedded reports. I made the opposite call — deliberately trading some visual control in the rigid middle for radical operational speed, and designing the Markets-native frame around it so users never felt the loss. I had to defend that trade to design-minded stakeholders as strategy, not a shortcut.

04 — Key Design Solutions

Four solutions that made a third-party tool feel like a first-party one

SOLUTION A

Seamless BI Embedding

Power BI dashboards were embedded into Markets within a carefully designed container — not dropped in as iframes. The entry points, loading states, and exit paths were all designed within the Markets system, so users moved into and out of BI content without feeling like they'd left the product.

↑ Zero "tool switch" perception in user sessions

SOLUTION B

Unified Interaction Layer

The hardest part of third-party integration is the moment a user crosses into different behavior. We solved this by aligning the key interaction touchpoints — filters, navigation patterns, and layout rhythm — between the native Markets UI and the Power BI embeds.

↓ User confusion at native-to-BI transition points

SOLUTION C

Rapid Report Editing Workflow

The primary operational win of the integration — reports could now be updated directly in Power BI Desktop by the data team, published, and reflected in Markets within minutes. No sprint scheduling, no engineering tickets, no waiting.

From 2–3 week sprints → under 15 minutes per update

SOLUTION D

UX Design Around Constraints

Where Power BI's UI couldn't be changed, we controlled what surrounded it. This meant deliberately designing the entry experience, loading state, error handling, and exit path within the Markets system — so the rigid middle didn't define the user's overall perception of the flow.

↑ Consistent perception of product quality despite third-party constraints

05 — Business Impact

The most operationally impactful change the product team had shipped

The gains here weren't about new features or redesigned flows — they were about fundamentally changing how fast the team could respond to user needs. For an enterprise analytics product, that speed became a competitive advantage.

8×Faster report updates vs. sprint baseline

~70%Reduction in engineering involvement for reporting

30+Reports deployed per month (up from ~4)

80%Report updates now handled by data team autonomously

Reporting cadence shifted from quarterly to continuous

With the bottleneck removed, the data team moved from quarterly report cycles to weekly — and in some cases daily — updates. Enterprise clients received fresher data without waiting for engineering cycles to close.

Engineering bandwidth freed for core product work

By moving report ownership to the data team, the engineering team recovered significant sprint capacity. Instead of fielding report update tickets, they could focus on the platform capabilities that required actual development work.

Experimentation with data became possible

The data team could now test new report structures, try different visualizations, and iterate on data storytelling without the overhead of a full feature request. This unlocked a meaningful cultural shift toward data-driven product improvement.

Increased responsiveness to enterprise client needs

Clients who previously waited weeks for custom report adjustments could now receive updates within the same business day — a change that directly improved perceived product quality and client satisfaction.

06 — Why This Matters

Most designers design ideal systems. This shows how to design practical ones.

The Power BI integration project is about a specific kind of design skill that doesn't always appear in portfolios: designing well within real-world constraints, with third-party tools, for operational outcomes rather than feature launches.

Constraint-first thinking🔧 Understanding which variables are fixed and which are flexible is a prerequisite for working with third-party systems. This project required mapping those constraints before designing anything.

Control vs. speed trade-off⚖️ The decision to accept some UI trade-offs in exchange for radical operational speed was a deliberate product strategy — not a design failure. Knowing when to make that call is a design skill.

Cross-functional coordination🤝 Design, engineering, and the BI team each had different goals and constraints. Aligning them around a shared integration spec — and the "constraint map" — was as important as any visual decision.

Systems-level design thinking📐 This wasn't about designing screens — it was about designing a system that connected two products into a coherent experience. That's a different (and more complex) design problem.

Business-first outcome framing🎯 The success metric here was operational: report turnaround time. Framing the design strategy around that business goal — rather than design metrics alone — is what made the project land.

Enabling team autonomy🔄 The best outcome wasn't a better UI — it was a data team that could update reports without asking for help. Design that unlocks others' capability is design that scales.

07 — Challenges

What made this genuinely hard

C1 · Limited control over the embedded toolPower BI's theming API covers colors and fonts but stops well short of layout or interaction overrides. Designing around hard constraints — rather than fighting them — required ongoing negotiation between what we wanted and what was possible.

C2 · Maintaining perceived product consistencyUsers don't know or care that they've crossed into a third-party tool. They just notice if something feels off. Keeping that seam invisible — especially across filters, navigation, and loading states — required extreme attention to the small details.

C3 · Avoiding experience fragmentation over timeWithout clear integration guidelines, every new Power BI report would drift from the last. The constraint map and design conventions had to be built in a way the data team could actually follow — not just reference once and forget.

C4 · Coordinating three teams with different fluenciesDesign, engineering, and the BI team spoke different languages and had different definitions of "done." Creating a shared spec that was actionable for all three — without over-designing the handoff — was its own coordination problem.

08 — What I Learned

Speed isn't the opposite of quality — it's a design requirement in its own right.

Design is not always about control. Sometimes it's about enabling the right outcome within the constraints that exist — not the constraints you wish you had.

This project challenged me to let go of the instinct to fully control the visual output. In an ideal world, every pixel in a product experience would be intentional. In practice, the most valuable thing I could do was design the system around the embedded tool well enough that users never felt the loss of that control.

It also reinforced something I believe deeply about enterprise UX: operational speed is a user experience. A platform that updates in 15 minutes feels more alive, more responsive, and more trustworthy than one that takes three weeks — regardless of how polished either one looks.

More Projects

Design Leadership

From Solo Designer to Design Function · Estater

Markets × Meter

Rebrand & Design System · Estater