Home About Me Resume
CASE STUDY
EELcase
Multi-app item flows and player-visible states
My role
Product and systems design ยท Behaviour review
When an item becomes owned
Items were not entering inventory when expected, battle results could show a value before the item appeared, and withdrawal needed a clear destination. I used those problems to define ownership timing and the roles of the platform, personal inventory and market.
I directed the concept and behaviour requirements, with AI-assisted development and documentation.
Project: Personal desktop simulation with virtual items and balances
Apps: EELcase, EelMarket and a simulated Steam app
Focus: Inventory rules, item actions and result feedback
Assets: Third-party Counter-Strike item visuals and Steam branding used in an independent prototype. The project is not affiliated with Valve.
What this case covers
I designed item flows and wrote behaviour requirements for a desktop simulation of case opening, personal inventory and market listings.
Separate the platform, inventory and market
An item needed a clear destination after leaving EELcase. I specified separate roles for platform activities, personal inventory and market listings, with different actions in each context.
Historical prototype capture: the simulated Steam inventory, with different actions for cases, terminals and skins.
First view
Second view
In my specification, EELcase handles platform activities and platform inventory. The simulated Steam app holds the personal inventory, while EelMarket provides a place to browse and list items.
I specified separate platform and market balances. I also defined which actions belong to an item while it stays on the platform and which become relevant in personal inventory, including inspection and market listing.
The personal-inventory screen presents those actions by item type. Cases have an Open Case action, and a terminal has Unseal. Skin cards show condition and float values alongside Inspect and Sell on Market.
Container details and item results
The container and result views answer different questions. One shows the case, required key and possible contents; the other presents a specific item with its attributes and an inventory notification.
Container detail
Historical Clutch Case view in the simulated Steam app, showing the owned quantity, required key and preview contents.
Item result
Historical P2000 | Urban Hazard result from a simulated container opening, shown with item attributes and an inventory notification.
The Clutch Case detail places the owned quantity and required key next to the case image. A preview grid lists possible contents above the Open Case action.
The P2000 | Urban Hazard result puts the item name and Factory New condition at the top, with float, seed and displayed price in the same view. Its notification says the item was added to the simulated Steam inventory.
Define ownership and result feedback
I separated the point when an item enters inventory from the way its result is shown. My review notes set out the ownership timing, battle feedback order and destination of a withdrawn item.
Evidence status: action-start ownership and battle reveal order remain documented requirements, not verified behaviours. Historical screens show the personal-inventory destination and item actions; they do not verify the withdrawal sequence. The processing and ready labels are historical structure names whose user-facing behaviour is not established by the evidence shown here.
First view
Second view
Record ownership when the action starts
I asked for the result to be determined and entered into EELcase's platform inventory as soon as a case opening or battle is initiated. Pressing Keep should be a later choice about an item the player already owns. Evidence status: requirement documented; action-start inventory timing has not been verified by the evidence shown here. The personal-inventory screenshot and result notification show a later interface state, not when EELcase first records ownership.
Reveal the item before its value
For battle results, I asked for the item to appear before its monetary result. The player should see what they received before the value is presented. Evidence status: requirement documented; the battle reveal order has not been verified by the evidence shown here. The static P2000 result is a container-opening screen, not a recording of battle timing.
Give withdrawal a destination
I specified that withdrawing an item moves it from platform inventory to the simulated personal inventory. The design gives that item a different set of uses, including inspection and market listing. Evidence status: destination and item-action requirements documented. The historical personal-inventory screen shows Inspect and Sell on Market actions, and the container result shows an added-to-inventory notification. These support the destination interface, but do not demonstrate an EELcase withdrawal completing end to end.
The historical simulated-transfer structure records processing and ready state names. The materials presented here do not establish which item actions are enabled during processing, or whether ready means transfer completed or ready to claim. These labels are not evidence of a verified transfer flow; those user-facing meanings remain unverified.