A Power BI Insider on Visualization, Fabric, and What's Next

In this edition of Meet the Expert, we feature Ashish, a data visualization specialist whose work has redefined what an insightful, user-centric dashboard can look like. Currently a Product Consultant at Lumel, Ashish has spent years crafting award-winning Power BI dashboards that combine technical depth with an unwavering focus on User Experience - turning complex datasets into clear, actionable stories for business users. 

Beyond his client work, Ashish served as a Power BI Core Visuals Community Representative for Microsoft, where he has contributed directly to the roadmap of native Power BI visuals, bringing the voice of the global community into product development. He is also widely recognized for his generosity with the community - regularly publishing free PBIX resources, breaking down advanced DAX and modelling techniques, and championing IBCS principles in modern data storytelling. 

In this conversation, Ashish shares the philosophy behind his craft, the lessons learned from shaping Power BI from the inside, and his perspective on how the rise of Microsoft Fabric and AI is reshaping the future of analytics.

1. Your career path is fascinating - from a Sugar and Coffee Trade Consultant for over six years to becoming a celebrated Power BI expert. What triggered that pivot, and how does your commodities trading background still influence the way you look at data today? 

It looks like a big leap on paper - from sugar and coffee trading to building data models. But I wasn't switching careers; I was recognising what I'd been doing all along. In trading, before any market entry, I'd map out who's who in the chain and physically pin them on a map, just to see the structure first. Turns out that's basically data modeling. The instinct was just there, by chance. I was also pulling shipment data into a buyer-seller dashboard that instantly answered top markets, top buyers, average prices, most-used HS codes. That trading lens is still how I see data today - every dashboard, to me, is a market in motion made visible. 

The instinct showed up even earlier. Back in 1995, when pivot tables were new, I was keeping transactions in unpivoted format and building master tables - fact and dimension tables, without knowing they were called that. Those instincts were there long before I had the words for them. DAX or any other syntax -anyone can pick up. The harder part is the wiring underneath, and that takes years of sitting with data and caring about the people reading it.

2. You've often said that "simplicity is the result of refined complexity." Can you walk us through what that means in the context of a real dashboard you've built - perhaps your Forecast through CAGR or Sales Growth Between Dates visualization? 

The simplest analogy is the iPhone. Tap, swipe, done - it feels obvious only because thousands of edge cases were thought through behind the scenes, so you wouldn't have to. Good design quietly absorbs the mess. A small example from my own work is a visual called Sales Growth Between Dates. From the user's side, it's plain - pick any two dates, and the line chart highlights that period and shows the growth percentage. That's it. 

But to make those few seconds feel effortless, there's a fair bit of plumbing underneath - a disconnected date table to handle the user's picks, and several DAX measures stacked together for the running total and boundary highlights. The user never needs to know any of this. That's all I mean by refined complexity - doing the harder work on this side so they don't have to.

3. UX is at the heart of your work. In your view, what separates a dashboard that simply displays data from one that genuinely empowers its user to act?

It comes down to one thing - empathy for the person on the other side of the screen. A dashboard that just displays data pushes the work to the user - crowded layouts and numbers to decode. A dashboard that actually helps takes on that heavy lifting - so by the time the user looks at it, the answer is almost waiting for them. I start with the assumption that they're busy, distracted, and have maybe thirty seconds. 

In practice, three things matter. 1st: Declutter - every chart, number, and label should earn its place; whitespace isn't wasted space. 2nd: Intuition - guide the eye naturally, the way a good door tells you push or pull without a sign. 3rd: The why behind the what - not just 'sales dropped' but where, when, and by how much. None of this is rocket science. Just remember there's a real human on the other side.

4. Many developers obsess over DAX, but you give equal weight to data modelling and evaluation context. If a young Power BI developer could only master one of these three first, which would you recommend and why? 

If I had to pick one, start with Data Modeling and let Evaluation Context follow close behind. The way I think about it: DAX is the vehicle, the data model is the road network, and evaluation context is the traffic rules. You can have the fanciest car in the world, but if the roads are broken or you don't know the signals, you're not going anywhere safely. The model is the real foundation. If relationships or filter directions are off, even beautiful DAX will quietly give the wrong number. The scary part is that it will still look right in isolation. 

There's a modern twist worth knowing. When I share the right metadata and context with AI, it builds models faster than I could alone. But AI is only as good as the context you bring and that context comes from understanding the model deeply. The fundamentals don't fade. They become what lets you use AI well.

5. You regularly release free PBIX files to the community - Sales Growth, Forecast through CAGR, and more. What drives that generosity, and what have you personally gained from giving your work away?

It's less about generosity and more about gratitude. Moving into data, I learnt from people who freely shared their work ,Like random PBIX files, blog posts, YouTube videos. That's how most of us got started. Once I figured things out, sharing back felt natural. If a file saves someone a frustrating weekend, that's enough. 

With that said, I've gained more than I've given. It keeps me honest knowing, others will poke at your model, you can't be lazy. It opens a feedback loop where others spot edge cases you'd miss alone. And it builds connections. I wouldn't have been invited as Microsoft Community Representative for Power BI Core Visuals, or ended up at Lumel, without sharing openly all these years. Both came from just showing up. I owe them to the community. 

6. At Lumel, you're now working at the intersection of planning, BI, and Microsoft Fabric. For a Power BI developer who's built reports, what does the shift toward Fabric Planning and writeback actually change in their day-to-day?

For most of my Power BI life, the work was backwards-looking. I built reports that showed businesses what had already happened - clean, useful, but read-only. With Fabric and Lumel's planning and upcoming write-back capabilities, two things feel different. 

First, less plumbing. Planning used to live in one tool, reporting in another, and time went into moving data between them. That bridge-building now shrinks. Second, dashboards are becoming two-way. As full write-back rolls out, a user can update a target or forecast inside the Planning Sheet, and it flows back to the underlying data. You're not just showing what happened anymore; you're building spaces where teams can plan and analyse together. It's still early, but the direction feels useful. 

7. There's a view that "The Power BI Developer", role is quietly evolving into "Analytics Engineer" as Fabric expands. Do you agree and what new skills should developers be picking up right now to stay relevant?

Yes, I think that's right. With Fabric pulling storage, transformation, and reporting together, the work has already widened beyond just the semantic model. The skills to pick up next are on the engineering side — data pipelines, medallion architecture, and CI/CD with proper source control. Honestly, none of this is new in the broader data world; it's just newly expected of us. 

8. If you could give one piece of advice to someone who wants to build award-winning dashboards five years from now - in a world of Fabric, AI, and real-time data - what would it be? 

Learn the new tech to save yourself time, but never let go of empathy for the person reading your report. Five years from now, the tools will look different but the human brain won't have changed. A good dashboard will still be the one a tired manager can glance at and walk away with the right decision. Let AI carry the heavy stuff across research, semantic models, design ideas. And real-time only matters if it leads to action. A wall of moving numbers is just noise. Let the tech do the speed. Keep the empathy yours.

9. Copilot and generative AI are now writing DAX and M code. Is this a threat to the craft you've spent years honing, or is it freeing developers up to focus on the more strategic, design-led parts of the job?

It's freeing, honestly. DAX and M code are syntax. The real work has always been understanding what the business needs, how the data connects, and what the user is trying to see. Copilot writes the code faster than I can, and that helps. It gives me more time for the harder parts: the modeling, the design, thinking about who's going to use the report. I don't see it as a threat. It just shifts where the effort goes.