A clickable inventory can show where an item detail panel opens. It may say little about where controller focus goes, what happens when the selected item disappears or whether opening the menu should pause the game.
View full image
Those questions make a small engine prototype useful for a designer. The value is seeing how an interface behaves while other systems continue to change around it. This article outlines a learning exercise; it does not claim a shipped Unity implementation.
Build a small inventory with an inconvenient case
Start with a few items, a detail panel and a use action. Define what is selected when the inventory opens, how focus moves and where it returns when the panel closes. Then remove the selected item after use.
That last step is deliberately awkward. Does selection move to the next item, stay in the same position or leave the player without a focus target? A static sequence can illustrate the intended answer. A working prototype exposes whether the answer holds when the list changes.
Keep the art simple. Decorative polish would make this exercise slower without answering its main questions.
Connect the UI to state
Test an item that cannot currently be used. The interface needs to communicate the restriction, respond to an attempted action and update when eligibility changes. It also needs to avoid showing stale information after the menu reopens.
These behaviors require a small, explicit model of item availability and selection. They are useful learning targets regardless of which engine is used. Learning every feature of Unity before trying them would be an unnecessary detour.
Observe the handoff between inputs
If both pointer and controller input are supported, check what happens when the player switches between them. A visible highlight should correspond to the action that will actually receive the next input. Having two apparent selections can be more confusing than either input method alone.
Document what the prototype covers, what is simulated and what remains absent. A mock item list is enough to investigate focus behavior. It is not evidence that saving, performance or a production inventory has been solved.
For a portfolio, a short recording of the problematic state and the corrected behavior can say more than another finished menu image. The point is to demonstrate a design decision under implementation constraints, with a scope small enough to understand and complete.