For all but the simplest games, data structure is a vital part of design. It may seem like it's more of an engineering topic, but designers should always understand how their data is set up and how to edit it themselves.
For example, as soon as you start designing the player's inventory and items, you should immediately think about how that's structured in data. Those are often two different types of structures.
In most games, item data is rarely changed during a game. A steel shortsword has the same attributes throughout the game... so its database is usually read-only.
The player inventory, on the other hand, is frequently updated, so it needs a storage type that's quick to read and update. But understanding design data structure goes way deeper than that.
As soon as you know your game has items, think about them as a data structure. List out all the attributes an item can have: name, type, stackable, weight (if you care), slots in inventory. Things like icon, sound and visual effects, etc. are also referenced here.
Your player's inventory, then, only has a reference to the item, usually by item ID (which is often generated when it's created in the database). So inventory slot 3 has item 325 at a count of 2: two stacked steel shortswords.
This is also how you can more easily handle localization. Each visible text string in the game is actually just a reference. So when I mouse over item 325 in inventory slot 3, it's pulling from loc_en for item 325's name, and displaying "shortsword."
It's like seeing the matrix, honestly. Once you wrap your head around how it's all connected, you immediately see most games as data structures. It's important for designers because you need to define the parameters and attributes you want to tweak without an engineer's help.
If you're working on solo projects, learning to set up and access a database becomes a core skill. Saving your game becomes as simple as cloning a couple databases. Well, it's a bit more complex than that... but that's the theory. :-)
I use SimpleSQL for Unity, which includes Playmaker actions. That, plus SQLiteManager creates a simple but powerful combo for game creation. There's a learning curve for sure, and you will create and delete and recreate 100 databases... but it's worth it. echo17.com/simplesql.html
Since item data is read-only, it can be in a separate format from player data, if that's easier. For example, your player data could be an Excel spreadsheet you import, while player data is a true DB.
I always have that debate and end up putting the items into the same DB type as the player data. Data entry is more tedious, but usability during code is higher because I'm only making one type of Playmaker action. You can also import Excel into a DB!
