A B2B UX Case Study Example, Torn Down (Freightline)

A b2b ux case study is harder to make readable than a consumer one. The work is dense, the users are specialists, and the impact is rarely a clean conversion number. This teardown walks through Freightline — a fictional B2B logistics platform — to show how an enterprise case study can prove systems thinking and stay honest about a limited result.

Freightline is an operations platform where ops managers track shipments across carriers and lanes. The designer redesigned the operations dashboard, their daily command center. It is an example portfolio built with Folioverse: realistic, but not a real launch.

Recruiter 30-second scan: What operational problem was being solved? What did the designer personally do? Which decisions were shaped by evidence? And what outcome can be stated honestly?

Case context

• Project type: B2B / enterprise redesign
• Role: lead product designer, with a PM, three engineers, and a data analyst
• Duration: 10 weeks

In B2B, ownership is easy to blur because the team is large. The case keeps it clear: the designer led product design, with defined partners in product, engineering, and data.

Weak version:

“We redesigned the logistics dashboard.”

Strong version:

“I led product design on a 10-week redesign of the operations dashboard, working with a PM, three engineers, and a data analyst.”

The problem this case proves

A strong B2B problem statement is framed around a specific operational failure, not a vague “improve usability.”

Weak version:

“The dashboard was cluttered and hard to use.”

Strong version:

“The legacy dashboard showed everything with equal weight — a wall of dense tables — so ops managers couldn’t quickly find the shipments that needed action: delays, exceptions, at-risk SLAs. They were reactive. Customers often called about a late shipment before the team had noticed it.”

That last sentence is the whole case in one line: the cost of the bad design was measurable in real operational pain.

What the designer did — research that fits B2B

The case shows research suited to enterprise work, where you watch the job rather than ask about it.

• contextual inquiry: shadowed four ops managers through real shifts
• task analysis of how they triage shipments
• two stakeholder workshops (ops, support, and carrier-ops each wanted different things)
• a design-system audit, because “status” was shown five inconsistent ways across the product

Naming the stakeholder conflict matters. It signals the designer understood that enterprise UX is partly an organizational problem.

Key decision 1: exception-first, not everything-at-once

Evidence: managers couldn’t separate signal from noise in a flat table.

Alternative considered: keep the comprehensive table, just style it better.

Weak version:

“I cleaned up the dashboard layout.”

Strong version:

“I made the layout exception-first: at-risk and delayed shipments surface above the noise, instead of a flat table of everything. The design answers ‘what needs me now?’ before it shows ‘everything.’”

Key decision 2: one severity system across the product

Evidence: status was shown five inconsistent ways, so it meant nothing.

Alternative considered: fix the status styling on this one screen.

Weak version:

“I standardized the status colors.”

Strong version:

“The core decision wasn’t a screen — it was a system: one shared language for risk (OK / At-risk / Breach) applied consistently everywhere, so status means the same thing across the whole product.”

This is the strongest signal in the case. The designer solved at the system level, knowing it would touch the whole product, not just the dashboard.

Key decision 3: progressive disclosure for density

Evidence: ops managers need depth, but not all at once.

Alternative considered: strip data out to reduce clutter.

Weak version:

“I made the dashboard simpler by removing detail.”

Strong version:

“I used progressive disclosure — a scannable summary that drills into detail — so density serves the user instead of drowning them. In enterprise, removing data isn’t always the answer; organizing it is.”

This shows maturity: the designer resisted the easy “make it minimal” move because the users genuinely need the data.

Outcome and evidence — an honest pilot

B2B results are messy, and this case treats them that way.

Weak version:

“The redesign improved operations across the company.”

Strong version:

“I piloted with one ops team for four weeks. Time to identify an at-risk shipment dropped meaningfully, exception handling got faster, and ‘customer noticed before we did’ incidents fell for that team. I frame it as a pilot signal — one team, four weeks, alongside other changes — not a platform-wide result.”

Naming the limits (one team, four weeks, other changes in play) makes the claim believable instead of inflated.

What makes this teardown worth studying

• The problem is tied to a concrete operational failure, not a usability adjective.
• The headline decision is a system, not a screen — exactly what senior B2B work looks like.
• The designer treats the org as part of the design problem, not a distraction.
• Results are scoped honestly as a pilot, with the caveats stated up front.

For the structure behind a case like this, use the UX case study guide. Browse more UX case study examples, including a 0-to-1 concept teardown. If this is your first portfolio piece, start with how to write a UX case study with no experience.