Turning thousands of
reviews into one decision.
A Power BI dashboard that pulls customer ratings and reviews from across US retailers and answers a single question for product teams: what do we fix next?
Problem
Customer feedback for each product was scattered across a dozen retailers in different formats — impossible for a product team to read as a whole.
Constraint
It had to be built in Power BI, whose default behaviour is a wall of charts. Usability had to be designed into a rigid tool.
Move
Designed a three-level read — portfolio → product → retailer — that ranks complaints by impact, not volume, so teams see what to fix first.
The feedback existed. It just wasn't readable.
A consumer-goods brand sells the same products across many US e-commerce retailers — Amazon, Target, Walmart, and others. Every one collects star ratings and written reviews, in its own format, on its own page. The signal a product team needs is all there. It's just scattered, unstructured, and impossible to read as one picture.
Nobody was going to read ten retailers' worth of reviews by hand. The question wasn't "show the reviews" — it was "what is all this feedback actually telling us to do?"
The data team could aggregate the ratings and scan review text for recurring keywords — pulling out what customers praised and complained about. My job was the layer on top: turning that raw extract into something a busy product manager could read in seconds and act on. A pile of keywords isn't an insight. The design problem was synthesis and hierarchy — deciding what rises to the top, and what a manager does next because of it.
"Which product has a problem, what's driving it, and is it us or the listing?"
I designed around one user and one recurring decision: a brand / product manager who opens the dashboard to find out which products are slipping in customer sentiment, what specifically is dragging them down, and whether the issue is the product or the retailer's listing — then walks away with a prioritized fix. Every layout choice traces back to serving that decision quickly.
Portfolio → product → retailer.
Rather than one dense screen, I structured the dashboard as three altitudes that answer the manager's three questions in order — each one a drill-down from the last.
1 · Portfolio overview — what needs attention
The landing view ranks the whole product line by what's slipping, so the manager's eye lands on the problem before the detail. Aggregate health up top; the watch-list right below it.
Fictional brands ("EverBrew", "NimbusBlend") and invented numbers — illustrative only. The real product category, brand, and data are withheld.
2 · Product detail — why it's slipping
Drilling into one product, the core decision was how to rank complaints. A raw keyword frequency list would put "color" above "leaks" just because more people mentioned it. I designed the pros/cons around impact — pairing how often a theme appears with how negatively it skews the rating — so the issue actually hurting the product sits at the top.
Ranking by impact rather than raw volume is the difference between "customers say a lot of things" and "fix the leaking lid first." That ordering is the actual product insight — the chart is just how it's carried.
3 · Retailer breakdown — us or them?
The same product can score very differently across retailers. If "arrived dented" spikes on one retailer only, that's a logistics or listing problem for that retailer — not a product flaw. Splitting sentiment by retailer tells the manager who owns the fix.
Retailer B's low score is driven by damage-on-arrival, not the product — a packaging / fulfilment fix for that channel, not a redesign.
Designing usability into a tool that resists it.
Power BI isn't a free canvas. You work inside its visual types, its interaction model, its layout grid. Left to its defaults it produces a wall of charts — technically accurate, practically unreadable. The central challenge wasn't inventing visuals; it was restraint: deciding what not to show on each screen, so the one thing that mattered wasn't drowned by the ten things that didn't.
I also owned visual QA — solo.
Designing the screens was half of it. The other half was making sure what the BI team built actually matched the design — spacing, alignment, color, label consistency, the behaviour of every drill-down — across a dashboard with a lot of surface area. I did that QA pass alone. In a cross-functional build where engineering renders your design in a constrained tool, that consistency check is where a design either holds together or quietly falls apart. Owning it end to end is the part I'd point to as senior: not just drawing the screens, but standing behind how they shipped.
What I'd define as success — and what I'd revisit.
Because of the NDA I can't share outcomes, and I wouldn't invent them. So here's how I'd define success honestly: the dashboard worked if a product manager could open it and, within a minute, name the one product to fix and the one thing to fix about it — without reading a single raw review. That's the bar the three-level structure was built to clear.
Impact-ranking needed validation
Ranking complaints by rating-impact rather than volume was my design judgment. I'd want to test it with real managers — does "biggest impact" match what they actually prioritize, or do they weight recency, cost-to-fix, or volume differently?
Power BI's interaction ceiling
Some interactions I'd have wanted (richer hover detail, smoother cross-filtering) were limited by the tool. I'd revisit whether a lighter custom layer on top of the data could lift the experience past Power BI's ceiling.
The "why" behind a theme
The dashboard surfaced that customers complain about leaks — but a manager often wants representative quotes. I'd design a way to drill from a theme into a few real review snippets without dumping the full firehose.
Strategy ownership
Direction was shaped with my design manager. With more experience I'd push to own more of the upstream framing — defining the JTBD and metric logic, not only the screens that express them.
This was a data-density and synthesis problem inside a tool that fights you — the kind of constraint that makes the design judgment matter more, not less. What I'm proud of is the discipline it forced: deciding what to leave out, so the one decision a product team needed was the one thing they couldn't miss.