The Stash That Fights Back

How I diagnosed and rebuilt the Witcher 3 stash: from in-game research to a working prototype in Unreal Engine 5.

June 22, 2026 · 15 min read · UX Case Study, Game UX, Inventory Design

The Hook

I'm a tidy person. The type who, in any game, immediately sorts the inventory into neat little rows: swords by descending damage, armor by my own rules, everything in its place. I open the menu and find what I need in a couple of seconds. Call it pedantry if you want. For me it's about control. I want to see my things the way I find convenient.

In The Witcher 3, my inventory and I had peace and order. Right up until the first accidental reset. I needed to check something by weight, hit sort, and then I couldn't get my hard-won order back. No way. The system just wiped it.

And then I ran out of space. I couldn't bring myself to throw away the "extra" stuff, so off I went to the stash. And in there, chaos. I tried to tidy it up: swords by damage, items by category. And I couldn't. The system won't let you. The cherry on top: you move an item into the stash, it drops to the bottom of an endless list, and to get it "into place" you have to leave and come back in.

That's the moment the designer in me snapped.

The Witcher 3 stash. My favorite sword is in here somewhere. Probably.

The Problem and the Diagnosis

The problem is not about "ugly"

When something about an interface annoys a designer, it's easy to stop at "well, this is just inconvenient." But that's a matter of taste. I tried to articulate what exactly was broken, and dug down to the root.

There's one root cause: the stash gives the player no control over how they see their things.

Everything else is a symptom of that. Let's go through them point by point. I checked every one in the actual game, not just from memory.

1. The system punishes you for organizing

The manual order you build by hand gets erased with a single click on auto-sort. Irreversibly, with no warning and no undo. You spent time organizing, and the system zeroed it out. That violates a basic principle: an interface should respect the user's actions, not fight them.

A hand-arranged inventory, then one tap on auto-sort, and the order collapses. No undo.

2. There's no sorting by what matters to the PLAYER

You can sort by type, price, weight, rarity, but not by damage. And for a weapon, damage is the key parameter when choosing. Want to compare swords by strength? Sort with your eyes, down the whole list. (Spoiler: this is exactly what I'll fix later.)

Sort by Type, Price, Weight, Durability, Rarity, and that's it. No "Damage." The one stat you actually pick a weapon for.

3. A rigid internal order, and an inconsistent one at that

Inside a category, items lie however the game decided, and you can't change that logic. The player doesn't even control what's already been arranged. But the most galling part is this: the game knows how to sort properly. Just not everywhere.

Compare two categories. Armor is sorted flawlessly: jackets, then trousers, then boots, and within each group neatly by rarity (relic, master, magic, common). A clean two-level hierarchy, groups don't mix, everything in its place.

Now look at weapons. The same swords, except axes and maces wedge themselves between the silver and steel ones, breaking the game's core conceptual pairing. I stumbled onto this in my own inventory and couldn't immediately figure out what an axe was even doing among the swords. The explanation, it seems, is that these "secondary" weapon types share an equipment slot with the steel sword, so the system keeps them in the general weapons block. Machine logic ("by slot") beat human logic ("by usefulness"): an axe belongs at the end, yet there it sits, between the two main swords.

I'll be honest: I don't know for sure why it turned out this way. Only the developers know the real reason. Maybe different parts of the system were built with different levels of care, maybe it was a deadline. But as a designer I see the main thing: the issue isn't that the engine can't do it cleanly. Armor proves it can. They just didn't carry the same logic over to weapons. And this isn't only my taste talking. The community had to write a mod that manually hard-codes a sane order, which is the best proof that, in vanilla, this connection is broken.

Left, armor: a clean slot + rarity hierarchy, exactly how it should be. Right, weapons: axes and maces wedged between the silver and steel swords, the pairing broken.

4. Items "get lost" when you move them

You toss something into the stash, and it drops to the end of a long list, outside its own category. To get it into place, you have to exit and re-enter. So the system knows where the item belongs, but only shows it after a re-entry. And on last-gen consoles, every such re-open of an overloaded stash also means 4 to 5 seconds of loading. So the broken sorting literally steals your time on loading screens. Findability breaks down at the exact moment you're actively using the stash.

Drop an item into the stash and it lands at the very bottom, out of its category. Only a full exit and re-enter puts it back in place.

Add up the symptoms and you get the diagnosis: the player is stripped of control. Can't sort the way they need, can't preserve their own order, can't quickly find what they just put away. At 150+ items, this turns from "cutely inconvenient" into real frustration.

The Solutions: Giving Control Back to the Player

When the root cause is one thing (the player doesn't control how they see their things), the temptation is huge. Just pile on features. Search! Filters! Tags! Sorting by twelve axes! But that's heading the wrong way: toward the same overloaded interface, just from another angle.

So I started with two boundaries I won't cross.

Boundary one: I don't touch the atmosphere

I'm not turning Witcher into Diablo. Same grim landscape, same font, same smoke drifting over the castle. The look stays put. What changes is what the player can do with their things. A UX fix shouldn't look like a foreign patch slapped onto someone else's game.

Boundary two: I respect the original's constraints

You can't put potions and bombs into the Witcher stash. That's a deliberate design call: elixirs are tied to alchemy and replenish when you meditate, so they're always on Geralt and refill themselves. There's nothing to store. So a "Potions" category shouldn't exist in my redesign either. Otherwise I'm fixing an imaginary system instead of the real one. Sounds like a small thing, but that's exactly the difference between "I played the game" and "I looked at a couple of screenshots."

Now, the specifics.

Sorting and filtering come first. Search comes second.

This is where I set my priorities right away, and it matters to me. Search by name is the obvious solution, the one your hand reaches for first. But I caught myself almost never searching by name in the actual game. I searched with my eyes: "where are my swords, which one hits harder?" And that's sorting and filtering, not search.

So I didn't make search the headline feature, but I didn't toss it out either. It stays as a safety net: for the rare cases when you know the exact name, and for an inventory that's ballooned into hundreds of items. Its place is in the supporting cast, not center stage. The hierarchy of solutions should mirror the hierarchy of pain. The pain that drove me into the stash was always "I can't arrange and compare these the way I need to," and search alone doesn't solve that. Then again, that's my hunch about how I play, not a fact. So I didn't trust it blindly: later I sat seven real players in front of a packed stash to watch what they'd reach for first. (The answer is in the hallway test, near the end.)

My filtering is category groups: weapons and armor, crafting and alchemy, books, food. Sorting is a switchable axis: by damage, by price, by weight. And here's a curious detail: there's no sorting by damage in the original at all. You can sort by type, price, weight, durability, rarity, but not by the one parameter that matters most for a weapon. So adding it is my own UX contribution, not a copy of someone else's solution.

My UE5 prototype: switch the sort axis (damage, price, weight), and the cards rebuild in real time. Including the "Damage" sort the original never had.

By the way, CDPR moved in this direction themselves, just not for the stash. In patch 1.20, right before Blood and Wine, they reworked the inventory UI: split it into subcategories, added item comparison, redrew the tooltips. So the studio clearly showed they know how to fix interfaces like this, and they wanted to. But the stash, the very chest the game shoves you toward to dump your overflow, stayed a flat list. They made the pocket more comfortable and left the warehouse untouched. That's the gap I'm stepping into.

CDPR's own 1.20 inventory rework, old interface versus new: subcategories, item comparison, redrawn tooltips. They fixed the inventory and left the stash a flat list.

The stat goes on the card, and it's the "average" damage on purpose

The main findability pain: to know a sword's damage you have to hover the cursor and wait for a tooltip. Across 150 items, that kills you.

The solution is simple. I put the key stat right on the card. You see the sword, you see the number. No hovering, no waiting.

Before / after. Left: the original, bare icons, the damage hidden behind a hover. Right: my cards, the number sits right there, sorted high to low.

This is, broadly, an ARPG reflex: show the player the item's key number. But there's no single solution in the genre, and that's interesting in itself. Diablo 4 hides damage ranges by default. You have to turn them on with a separate option in the settings, and even then they only appear in the tooltip on hover. Path of Exile shows the range right on the item, but makes the player calculate the final DPS themselves. I chose my own compromise for the context of a stash: one readable number on the card for quickly scanning the grid, and the range in the tooltip for those who want the details.

Reference. Diablo 4: damage ranges are off by default, switched on in settings, shown only on hover. Left to right: the toggle, ranges in a tooltip, item comparison.

And here's one more decision I'm happy with: the number on the card is the average damage, not the maximum. The max is misleading. Two swords both showing "100" in the corner can hit very differently if one has a wider spread. The average more honestly reflects what to expect from the weapon in a fight. And the full range (min to max) lives in the tooltip, just like in the original. A tiny detail, but it's from details exactly like this that trust in an interface is built. Although "feels right to me" isn't proof. So later I put both versions, average and max, in front of real players, and they didn't behave the way I assumed. (More on that in the hallway test below.)

My prototype: a single average number lives on the card, the full min-to-max range stays in the tooltip on hover. Card = average, tooltip = range.

The Build: A Living Prototype, Not a Mockup

Here's a turn that matters to me. Most UX case studies end with a pretty Figma mockup: here's "before," here's "after," an arrow between them. I went further and built all of this as a working prototype in Unreal Engine 5, the very engine CDPR switched to.

The redesigned stash, alive in Unreal Engine 5: open it, switch categories, change the sort axis, hover for the range, click to select. Unmute for sound.

Why this matters. A Figma mockup looks perfect because nothing has to function. An engine takes that cheat code away: the sorting either sorts, or it doesn't. The build proves the solution holds up under actual use.

Here's what actually works in the prototype:

1. Sorting by a switchable axis. Under the hood: sorting the item array by the chosen parameter (damage / price / weight), switched with a combobox. Unreal has no built-in node for sorting an array of structs, so I had to assemble the algorithm by hand. Not the most elegant way possible, but honest and working. For a prototype, what matters is that it does its job.

2. Sorting by rarity. On top of the damage / price / weight axes, I added sorting by rarity, but with the correct in-game hierarchy, not by the order rarities happen to sit in the data. Relic and witcher items at the top, common ones at the bottom, the way a player expects. Technically it's a separate translator function: it takes the item's rarity and outputs its "value rank," which the sorting then uses.

3. Rarity color-coding. Rarity reads not only through sorting, but at a glance, through color. The card background and the tooltip header are colored by rarity (green for witcher gear, blue for master, yellow for magic, and so on), in the same color logic as the original. The player doesn't need to read closely. They catch the item's value with peripheral vision.

4. Filtering by category groups. The category buttons switch what's visible in the grid. The logic is built on groups: one button can show several item types at once (for example, crafting + alchemy under a single "gear" icon). The active category is highlighted, the inactive ones dimmed. The player always sees where they are.

5. The stat and type icon right on the card. Each card shows its key number and a type icon next to it (damage / defense / quantity), the very solution from the section above, taken all the way down to the pixels.

6. Tooltip on hover. Like in the original: on hover, not on click. It shows the damage range (min to max) and the details, without duplicating what's already on the card. For scrolls, a separate image-tooltip.

7. Search by name. Case-insensitive, as a safety net.

8. Click-to-select. A frame and highlight on the chosen item.

And all of this sits on top of the Witcher atmosphere: the landscape background, the animated smoke, the frames in the game's style. The mechanics are new, but the feeling stays the same.

(A detailed technical breakdown of how this is built in Blueprint gets its own post. The point here is just one: it actually works.)

One More Catch: The Comparison Forgets What's Equipped

I only caught this one because I actually played with the thing. When you compare two weapons inside your inventory, the game politely marks which one is currently equipped, so you always know what you're measuring against. But the moment one of those weapons lives in the stash, that "Equipped" label quietly vanishes. Same comparison, same screen, and suddenly you can't tell which sword is the one already on Geralt's back.

Original: comparing two inventory items, the equipped one is clearly tagged (left). Compare against a stash item and the "Equipped" tag simply disappears (right).

It's the exact same pattern as everything else here: the system knows how to do it right, just not when the stash is involved. So in my version the equipped item is always marked, inventory or stash, no exceptions.

My prototype: the equipped sword stays tagged even in a stash comparison. One rule, no exceptions.

Reflection: What I Deliberately Didn't Do

A good designer differs from a beginner in two things: knowing where to draw the line, and being able to explain why.

The Witcher stash hides a stack of problems, not just one. When I dug in, things surfaced that were far bigger than my fix:

Technical lag. In the late game, when thousands of items pile up in the stash, the interface starts to choke. Opening it takes seconds, and in extreme cases players describe minutes of loading and the framerate dropping to one frame per second. That's an architecture problem: synchronous loading of everything at once, with no lazy loading. It's solved at the engine and code level, not in interface design. I see it, but I deliberately don't touch it. It's not my zone as a UX designer, and it's more honest to admit that than to pretend my redesign also fixes performance.

Craft from stash and economy integration. The modern genre standard is to craft and sell straight from storage, without running back and forth to the chest. Witcher doesn't have this, and mods actively fix it. But that takes us out of the stash screen and into how the stash connects to the game's other systems. A separate, bigger task, well past "fix findability on one screen."

Why didn't I grab everything? Because the case is about focus, not volume. I picked one pain (the player doesn't control how they see their things) and took the solution all the way through: from a diagnosis in the actual game to a working build. Spreading the effort across lag, economy, and crafting would have meant doing nothing properly.

What I'd Do Differently, and What's Next

Looking back, I split my "this could've been better" moments into two kinds: technical and design. And the second kind is, honestly, more interesting.

Where I struggled as a builder. I had to write the sorting by hand, brute-force, because Unreal 5.7 has no ready-made tool for my data type. It works, but I know it would lag on a thousand items; in production I'd rewrite it. What took me longest was aligning the square slots (runes, books) in the same row as the tall weapon cards. I found a workaround, but "perfectly even, like in the original" is still on the list. And part of the decor I deliberately built from static images instead of live logic: weeks of work for something the player won't even notice. Not my kind of trade. "Good enough now" over "perfect a month from now."

Where I doubted as a designer. Now this is the interesting part. Two decisions felt right to me, but right for my user persona, not objectively. I show the average damage, not the maximum, even though players are conditioned toward the big numbers of the max. And the priority "sorting over search" I derived from my own behavior, but I'm a tidy person, and for someone else search might actually come first. These were hypotheses, not truths. So I decided not to guess at my desk, but to go and check.

How I Tested It: A Hallway Test

I didn't have a lab or hundreds of respondents, so I did what a designer should do under constraints: a qualitative hallway test. I jumped on a Discord call with screen-sharing with seven gamer friends, hardcore RPG fans who heroically put up with my experiments. Let me say upfront: this is a directional check rather than rigorous statistics. But even it showed me things I'd never have seen from my desk.

I showed two versions of the same cards: one with the maximum damage, one with the average. Visually, everyone drifted toward the max version first; big numbers pull the eye, that's just how the brain works. Then I set the task: "pick the most reliable sword for a long fight." That's where it flipped. On the average cards, decisions came noticeably faster, with nobody stuck mentally averaging a min-to-max spread in their head. The part I didn't expect: the range still mattered, just not for the decision. Players wanted to glance at the min-to-max in the tooltip to trust the system wasn't hiding anything, then chose on the single average number on the card.

Variant 1: the card shows the maximum damage, the number players instinctively reach for.

Variant 2: the card shows the average instead, which they actually chose better with. The full min-max range stays in the tooltip.

For this one the task was concrete: find "the best steel sword" in a stash crammed with a hundred and fifty items, while I watched where each hand went first. The telling part wasn't that they used the filters, it was when they didn't. The single person who reached for text search only did it after I named an exact sword, "find Aerondight." The moment the goal was "the best one" instead of "this specific one," search stopped being something anyone reached for. The same line I'd drawn at my desk, now with seven pairs of hands behind it instead of just my own.

What's next, logically. Live re-sorting when an item is added, so a thing doesn't "get lost" at the bottom of the list, that very fourth pain. Plus unique icons instead of temporary placeholders, and group headers within categories. But that's already the next iteration. And a case study shows not the finished product, but a way of thinking.

In the end, this case is about how I work. I find problems by actually playing, instead of nitpicking from the sidelines. I design solutions that respect the world they live in. I check my hunches on real people, not on my own taste. And I take an idea all the way to something you can open, click, and touch. The stash is just the excuse to show all of that in action.

Read the full case study in the portfolio →