You're definitely onto something with your chart about theme, item, boss, etc, but I think a lot of that is encompassed in "theme". For example, an ice dungeon inherently contains ice, which automatically lends itself to puzzles over combat, so being puzzle-heavy is part of the theme too. In many games, the item also goes with the theme (WW's Deku leaf, the lantern in MC, etc), and then the boss is usually based on the theme (icy) and the item to use for its battle mechanics.
I dunno if you've read this article yet if you're researching dungeon design, but it has a lot of interesting points:
http://www.gamasutra.com/view/feature/134949/One of the biggest things I saw there was the notion of a "critical path" - that is, the simplest and most direct way through a dungeon. If a player follows this path, they will get what they need in the order they need it, and most importantly, this path is basically linear.
That's one way to approach a big component of dungeon design- which is making sure a player doesn't take a lengthy path that they can't finish. If something is a dead-end, even temporarily (ie you can't progress without finding an item elsewhere), then you obviously don't want a player wasting a bunch of time to get to the dead end, when they should have gone down a different path. That's pretty obvious, but the critical path idea from that article is a way of approaching it I hadn't thought of.
Something else that might help you is dusting off your SNES or GBA or emulator and playing through ALTTP and maybe some other 2D Zeldas and literally writing down each puzzle in a dungeon. I did this just for puzzle categories, but later realized I should have gotten more specific with different ways to execute the category.
For example, I played through the oracle games, and ended up with a few pages of these puzzle categories and variation thingies:
Sliding Block puzzle: manipulate blocks to achieve goal
Goals: physically pass through area, trip switch, reach destination within puzzle, alter room conditions
- blocks can only be moved 1 space
- blocks can be moved infinitely
- blocks can only be moved one direction
- only some blocks can be moved
- blocks can only be moved within a certain region
- blocks must depress a switch or multiple switches
- blocks must be manipulated into one configuration, a task done, then manipulated into another configuration
*I also wrote down specific puzzle arrangements and solutions that I liked
Enemy-Key puzzle: fulfill enemy destruction conditions for solution
-kill all enemies
-kill specific enemy
-kill certain type of enemy
opens door, enemy drops key, causes bridge to appear, etc.
Hookshot-key puzzle: Use the hookshot to solve
- Hit something with the hookshot to activate a switch
- Hit inaccessible enemies
- Bring inaccessible enemies to an accessible area
- Move Link to an inaccessible area
- move across falling/damage tiles
- move across lower elevation parts of the room
- etc.
- etc.
What I did then was I could make a layout for the dungeon and just write "x-type" puzzle in this room, "difficulty: Y", and then go through and fill in the specifics later to accommodate things like the dungeon's theme, and adjust the variations of the puzzle to alter the difficulty. That's what really helped me just get started, what not getting caught up in the details of what puzzle went where, but rather getting the overall layout and sense before I filled in blanks with appropriate puzzles and difficulties.
On a side note, I really like that a question like this is coming up for discussion. Considering this forum is about making Zelda games, I've hardly ever seen much about the theory of how to actually make a Zelda game.